【消息隊列】從各方面比較下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丟失

 

六、功能支持

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唯一的一點劣勢是有可能消息重復消費,那么對數據准確性會造成極其輕微的影響,在大數據領域中以及日志采集中,這點輕微影響可以忽略這個特性天然適合大數據實時計算以及日志收集。

 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM