【消息隊列】從各方面比較下kafka、activemq、rabbitmq、rocketmq之間的區別

一.單機吞吐量
ActiveMQ：萬級，吞吐量比RocketMQ和Kafka要低了一個數量級
RabbitMQ：萬級，吞吐量比RocketMQ和Kafka要低了一個數量級
RocketMQ：10萬級，RocketMQ也是能夠支撐高吞吐的一種MQ
Kafka：10萬級別，這是kafka最大的優勢，就是吞吐量高。通常配合大數據類的系統來進行實時數據計算、日誌採集等場景

二.topic數量對吞吐量的影響
RocketMQ：topic能夠達到幾百，幾千個的級別，吞吐量會有較小幅度的降低，這是RocketMQ的一大優點，在同等機器下，能夠支撐大量的topic
Kafka：topic從幾十個到幾百個的時候，吞吐量會大幅度降低，因此在同等機器下，kafka儘可能保證topic數量不要過多。若是要支撐大規模topic，須要增長更多的機器資源

三.時效性
ActiveMQ：ms級
RabbitMQ：微秒級，這是rabbitmq的一大特色，延遲是最低的
RocketMQ：ms級
Kafka：延遲在ms級之內

四.可用性
ActiveMQ：高，基於主從架構實現高可用性
RabbitMQ：高，基於主從架構實現高可用性
RocketMQ：很是高，分佈式架構
Kafka：很是高，kafka是分佈式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會致使不可用

 

五.消息可靠性

ActiveMQ：有較低的機率丟失數據
RocketMQ：通過參數優化配置，能夠作到0丟失
Kafka：通過參數優化配置，消息能夠作到0丟失

 

6、功能支持

ActiveMQ：MQ領域的功能極其完備
RabbitMQ：基於erlang開發，因此併發能力很強，性能極其好，延時很低
RocketMQ：MQ功能較爲完善，仍是分佈式的，擴展性好
Kafka：功能較爲簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日誌採集被大規模使用，是事實上的標準

七.優劣勢總結

ActiveMQ：很是成熟，功能強大，在業內大量的公司以及項目中都有應用，偶爾會有較低機率丟失消息，並且如今社區以及國內應用都愈來愈少，官方社區如今對ActiveMQ 5.x維護愈來愈少，幾個月才發佈一個版本，並且確實主要是基於解耦和異步來用的，較少在大規模吞吐的場景中使用

RabbitMQ：erlang語言開發，性能極其好，延時很低；吞吐量到萬級，MQ功能比較完備，並且開源提供的管理界面很是棒，用起來很好用，社區相對比較活躍，幾乎每月都發布幾個版本分在國內一些互聯網公司近幾年用rabbitmq也比較多一些，可是問題也是顯而易見的，RabbitMQ確實吞吐量會低一些，這是由於他作的實現機制比較重。並且erlang開發，國內有幾個公司有實力作erlang源碼級別的研究和定製？若是說你沒這個實力的話，確實偶爾會有一些問題，你很難去看懂源碼，你公司對這個東西的掌控很弱，基本職能依賴於開源社區的快速維護和修復bug。並且rabbitmq集羣動態擴展會很麻煩，不過這個我以爲還好。其實主要是erlang語言自己帶來的問題。很難讀源碼，很難定製和掌控。

RocketMQ：接口簡單易用，並且畢竟在阿里大規模應用過，有阿里品牌保障，日處理消息上百億之多，能夠作到大規模吞吐，性能也很是好，分佈式擴展也很方便，社區維護還能夠，可靠性和可用性都是ok的，還能夠支撐大規模的topic數量，支持複雜MQ業務場景，並且一個很大的優點在於，阿里出品都是java系的，咱們能夠本身閱讀源碼，定製本身公司的MQ，能夠掌控，社區活躍度相對較爲通常，不過也還能夠，文檔相對來講簡單一些，而後接口這塊不是按照標準JMS規範走的有些系統要遷移須要修改大量代碼，還有就是阿里出臺的技術，你得作好這個技術萬一被拋棄，社區黃掉的風險，那若是大家公司有技術實力我以爲用RocketMQ挺好的

Kafka：kafka的特色其實很明顯，就是僅僅提供較少的核心功能，可是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，並且分佈式能夠任意擴展，同時kafka最好是支撐較少的topic數量便可，保證其超高吞吐量並且kafka惟一的一點劣勢是有可能消息重複消費，那麼對數據準確性會形成極其輕微的影響，在大數據領域中以及日誌採集中，這點輕微影響能夠忽略這個特性自然適合大數據實時計算以及日誌收集。