常見消息隊列ActiveMQ、RabbitMQ、RocketMQ、Kafka優劣勢比較
在高併發業務場景下，典型的天貓雙11購物節等業務場景，消息隊列中間件在流量削峯、解耦上有不可替代的作用。本文簡單介紹一下常見的消息隊列如ActiveMQ、RabbitMQ、RocketMQ、Kafka等優劣比較。
常見的消息隊列
這裏幾乎列舉了當下各種主流的MQ中間件：
- ZeroMQ
- 推特的Distributedlog
- ActiveMQ：Apache旗下的老牌消息引擎
- RabbitMQ、Kafka：AMQP的默認實現。
- RocketMQ
- Artemis：Apache的ActiveMQ下的子項目
- Apollo：同樣爲Apache的ActiveMQ的子項目的號稱下一代消息引擎
- 商業化的消息引擎IronMQ
- 以及實現了JMS(Java Message Service)標準的OpenMQ。
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，最早大家都用ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；
後來大家開始用RabbitMQ，但是確實erlang語言阻止了大量的java工程師去深入研究和掌控他，對公司而言，幾乎處於不可控的狀態，但是確實人是開源的，比較穩定的支持，活躍度也高；
不過現在確實越來越多的公司，會去用RocketMQ，確實很不錯，但是我提醒一下自己想好社區萬一突然黃掉的風險，對自己公司技術實力有絕對自信的，我推薦用RocketMQ，否則回去老老實實用RabbitMQ吧，對應的活躍開源社區，一般不會黃；
所以中小型公司，技術實力較爲一般，技術挑戰不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎架構研發實力較強，用RocketMQ是很好的選擇
如果是大數據領域的實時計算、日誌採集等場景，用Kafka是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規範