消息隊列那些事——MQ的選擇

在說如何選擇消息隊列之前？首先要明白一個問題，那就是爲什麼要使用消息隊列？可不可以將消息隊列用其他的技術代替？

• 爲什麼使用消息隊列？

對於爲什麼使用消息隊列可以從三個方面來看，也就是從消息隊列的三個核心特點來看：解耦、削峯、異步。

解耦

對於耦合性，可以先來看這麼一例子：現在有A、B、C、D四個系統，其中A系統要分別向BCD三個系統發送消息，進行相應的操作。剛一開始這樣的場景是OK的，但是系統運行了一段時間後，又加入了一個新的系統E，E系統也需要A系統發送數據，並條用E的接口，此時A系統不得不修改代碼，在代碼裏面專門處理給E系統發送數據。但是過了一段時間後系統D告訴系統A，不需要A給它發送消息了，A系統又屁顛屁顛的去把代碼裏面給D發送數據的部分給註釋或者刪除調。對於A系統可能剛開始的時候，一兩個改動很簡單，但是如果越來越多的要求，那麼此時修改起來就很麻煩，A系統就很嚴重的各種亂七八糟的系統耦合起來。另外A系統還要考慮它說關聯的系統如果掛了怎麼辦？訪問系統D超時怎麼辦？需不需要做重試的機制？等等問題。讓系統A耦合較高，處理也比較繁瑣。

此時如果引入MQ之後，情況就會大大的不一樣了，同樣是上面的場景，新系統E需要系統A的消息，只需要去MQ中讀取，並不需要告知系統A，讓其進行相應的修改；系統D不需要A的消息了，只需要衝MQ中取消對於系統A發送消息的訂閱即可。現在整個流程就成了：

1.系統A產生一條數據，發送到MQ裏面。

2.哪個系統需要數據自己去MQ裏面消費。

3.如果新系統需要數據自己直接從MQ裏面消費。

4.如果某個系統不需要這條數據就取消對MQ消息的消費即可。

有了MQ以後，系統A根本就不需要去考慮給誰發數據，也不需要去維護代碼，不需要考慮調用者是否調用成功、失敗超時等問題。總之，通過一個MQ,發佈和訂閱消息的這麼一個模型,系統A就跟其他系統徹底解耦了。

流量削峯

流量削峯顧名思義，就是協調處理流量洪峯，讓流量分批次處理，從而減輕服務器的壓力，很形象的一個比喻就是消息隊列就像“水庫”一樣，攔蓄上游的洪水，削減進入下游河道的洪峯流量，從而達到減免洪水災害的目的。對於春節火車票搶購，大量的用戶同一時間去搶購，又比如大家熟知的阿里雙11秒殺，短時間內上億的用戶涌入，瞬間流量巨大。

就用Mysql的請求數來解釋流量削峯的好處。Mysql的請求數量是有一定限制的，根據服務器的不同各有不同，就像我的服務器，默認的爲151個請求。如果某一時刻，有兩百個用戶同時的對我的網站進行大量的操作，大量的請求就會涌入我的系統中，高峯期也有可能達到三四百個請求，系統是基於Mysql，所以此時對於Mysql執行的SQL操作也就有三四百條，此時很明顯我的Mysql支持不了這麼多操作，Mysql就無法正常運行，然後用戶就不能對我的網站進行操作。但是平時又不可能會有這麼大的併發量，對於系統的運行幾乎沒有任何壓力。當然此處只是做個例子，線上的Mysql的最大請求數不可能會這麼低，但是也會存在這麼一個問題。

加入了MQ之後的情況又是怎麼樣呢？當大量的操作和請求涌入服務器，假設每秒有500個請求，將這500個請求寫入MQ中，系統因爲Mysql的最大併發數量爲151，所以每買哦中只能處理151個請求。系統從MQ中慢慢拉取請求，每秒鐘就取151個請求就可以了，此時哪怕最高峯值的時候，系統也不會掛掉，因爲所有的請求都存在MQ中，Mysql也每秒處理着最大併發數量的請求。雖然對於MQ來說每秒進入500個請求，151請求出去，在高峯期的時間內，可能會積壓幾千的請求，但是這些都是沒有問題的，因爲等高峯期過後，Mysql還是會按照每秒151個請求處理，因此，只要高峯期已過，系統就會快速的將積壓的信息給解決掉。

異步處理

所謂異步就是一個請求操作的內容分爲幾個步驟，這幾個步驟並不需要是同步的，比如顧客下單創建了一個訂單，下了訂單還需要去更新庫存系統、用戶積分系統中的顧客積分等等。如果這些操作都是同步的，那麼顧客請求一次，就會產生大量的等待時間，這樣對於用戶是無法接受的。後面的這些操作可以存入MQ裏面，然後去異步操作，這樣可以加快系統的訪問速度，提供更好的客戶體驗。

• 消息隊列有什麼優缺點

消息隊列的優點也是上面所說的三個核心特點。對應的缺點也因爲優點所引起。

系統可用性降低： 系統引入外部依賴越多，越容易掛掉，之前就是一個A系統調用BCD三個系統的接口就好了，現在加了一個MQ,如果MQ系統掛掉，那麼整套系統就會崩潰。

系統複雜性提高：加入了MQ系統進來，不能保證消息有沒有重複消費，消息丟失的情況該如何處理，怎麼保證消息傳遞的順序等等問題也隨之而來。

一致性問題：A系統處理完成之後就返回成功，你以爲這個請求成功。但問題是，如果BCD三個系統如果有一個系統的操作失敗，那麼數據就不會一致。

• 選擇消息隊列

現在經常的MQ有ActiveMQ、RabbitMQ、RocketMQ和Kafka。這四個MQ各有各自的優缺點。

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
單機吞吐量	萬級，吞吐量比RocketMQ和Kafka要低了一個數量級	萬級，吞吐量比RocketMQ和Kafka要低了一個數量級	10萬級，RocketMQ也是可以支撐高吞吐的一種MQ	10萬級別，這是kafka最大的優點，就是吞吐量高。   一般配合大數據類的系統來進行實時數據計算、日誌採集等場景
topic數量對吞吐量的影響			topic可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降   這是RocketMQ的一大優勢，在同等機器下，可以支撐大量的topic	topic從幾十個到幾百個的時候，吞吐量會大幅度下降   所以在同等機器下，kafka儘量保證topic數量不要過多。如果要支撐大規模topic，需要增加更多的機器資源
時效性	ms級	微秒級，這是rabbitmq的一大特點，延遲是最低的	ms級	延遲在ms級以內
可用性	高，基於主從架構實現高可用性	高，基於主從架構實現高可用性	非常高，分佈式架構	非常高，kafka是分佈式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用
消息可靠性	有較低的概率丟失數據		經過參數優化配置，可以做到0丟失	經過參數優化配置，消息可以做到0丟失
功能支持	MQ領域的功能極其完備	基於erlang開發，所以併發能力很強，性能極其好，延時很低	MQ功能較爲完善，還是分佈式的，擴展性好	功能較爲簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日誌採集被大規模使用，是事實上的標準
優劣勢總結	非常成熟，功能強大，在業內大量的公司以及項目中都有應用   偶爾會有較低概率丟失消息   而且現在社區以及國內應用都越來越少，官方社區現在對ActiveMQ 5.x維護越來越少，幾個月才發佈一個版本   而且確實主要是基於解耦和異步來用的，較少在大規模吞吐的場景中使用	erlang語言開發，性能極其好，延時很低；   吞吐量到萬級，MQ功能比較完備   而且開源提供的管理界面非常棒，用起來很好用   社區相對比較活躍，幾乎每個月都發布幾個版本分   在國內一些互聯網公司近幾年用rabbitmq也比較多一些   但是問題也是顯而易見的，RabbitMQ確實吞吐量會低一些，這是因爲他做的實現機制比較重。   而且erlang開發，國內有幾個公司有實力做erlang源碼級別的研究和定製？如果說你沒這個實力的話，確實偶爾會有一些問題，你很難去看懂源碼，你公司對這個東西的掌控很弱，基本職能依賴於開源社區的快速維護和修復bug。   而且rabbitmq集羣動態擴展會很麻煩，不過這個我覺得還好。其實主要是erlang語言本身帶來的問題。很難讀源碼，很難定製和掌控。	接口簡單易用，而且畢竟在阿里大規模應用過，有阿里品牌保障   日處理消息上百億之多，可以做到大規模吞吐，性能也非常好，分佈式擴展也很方便，社區維護還可以，可靠性和可用性都是ok的，還可以支撐大規模的topic數量，支持複雜MQ業務場景   而且一個很大的優勢在於，阿里出品都是java系的，我們可以自己閱讀源碼，定製自己公司的MQ，可以掌控   社區活躍度相對較爲一般，不過也還可以，文檔相對來說簡單一些，然後接口這塊不是按照標準JMS規範走的有些系統要遷移需要修改大量代碼   還有就是阿里出臺的技術，你得做好這個技術萬一被拋棄，社區黃掉的風險，那如果你們公司有技術實力我覺得用RocketMQ挺好的	kafka的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，而且分佈式可以任意擴展   同時kafka最好是支撐較少的topic數量即可，保證其超高吞吐量   而且kafka唯一的一點劣勢是有可能消息重複消費，那麼對數據準確性會造成極其輕微的影響，在大數據領域中以及日誌採集中，這點輕微影響可以忽略   這個特性天然適合大數據實時計算以及日誌收集

因此一般的業務系統要引入MQ,最早的時候都用AactiveMQ。但是現在用的不多，沒有經過大規模吞吐量場景的驗證，社區也不是很活躍。後來開始使用RabbitMQ,但是由於RabbitMQ是由erlang語言阻止了大梁Java工程師的研究，對公司而言，幾乎處於不可控的狀態，但是確實是開源的，比較穩定的支持，活躍度也高。另外現在也有越來越多的公司會去使用RocketMQ，但是社區萬一突然黃掉的風險，所以自己公司沒有實力，就還是使用RabbitMQ。如果是大數據領域的實時計算、日誌採集等場景，用Kafka是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃。