Kafka、RabbitMQ、RocketMQ消息中間件的對比

引言

分佈式系統中,咱們普遍運用消息中間件進行系統間的數據交換,便於異步解耦。如今開源的消息中間件有不少,目前對Kafka、RabbitMQ、RocketMQ這三個消息中間件作下對比分析。

 

-	-	kafka	RocketMQ	RabbitMQ	數據來源	相關文章
定位	設計定位	系統間的數據流管道，實時數據處理。 例如：常規的消息系統、網站活性跟蹤，監控數據，日誌收集、處理等	非日誌的可靠消息傳輸。 例如：訂單，交易，充值，流計算，消息推送，日誌流式處理，binglog分發等	可靠消息傳輸。和RocketMQ相似。
基礎對比	成熟度	日誌領域成熟	成熟	成熟
	所屬社區／公司	Apache	Alibaba開發，已加入到Apache下	Mozilla Public License
	社區活躍度	高	中	高	來源於網絡
	API完備性	高	高	高
	文檔完備性	高	高	高	來源於網絡
	開發語言	Scala	Java	Erlang
	支持協議	一套自行設計的基於TCP的二進制協議	本身定義的一套 (社區提供JMS--不成熟)	AMQP
	客戶端語言	C/C++、Python、Go、Erlang、.NET、Ruby、Node.js、PHP等	Java	Java、C、 C++、 Python、 PHP、Perl 等
	持久化方式	磁盤文件	磁盤文件	內存、文件
可用性、可靠性比較	部署方式	單機／集羣	單機／集羣	單機／集羣
	集羣管理	zookeeper	name server
	選主方式	從ISR中自動選舉一個leader	不支持自動選主。經過設定brokername、brokerId實現，brokername相同，brokerid=0時爲maser，其餘爲slave	最先加入集羣的broker
	可用性	很是高 分佈式、主從	很是高 分佈式、主從	高 主從，採用鏡像模式實現，數據量大時可能產生性能瓶頸	rabbitMQ集羣部署 http://www.cnblogs.com/knowledgesea/p/6535766.html RabbitMQ可用性、可靠性分析 http://blog.csdn.net/cadem/article/details/53422912?utm_source=itdadao&utm_medium=referral
	主從切換	自動切換 N個副本，容許N-1個失效；master失效之後自動從isr中選擇一個主；	不支持自動切換 master失效之後不能向master發送信息，consumer大概30s（默認）能夠感知此事件，此後從slave消費；若是master沒法恢復，異步複製時可能出現部分信息丟失	自動切換 最先加入集羣的slave會成爲master；由於新加入的slave不一樣步master以前的數據，因此可能會出現部分數據丟失
	數據可靠性	很好 支持producer單條發送、同步刷盤、同步複製、異步。	很好 producer單條發送，broker端支持同步刷盤、異步刷盤，同步雙寫，異步複製。	好 producer支持同步／異步ack。支持隊列數據持久化，鏡像模式中支持主從同步	kafka也同步刷盤，可是效率較低 http://jm.taobao.org/2016/04/28/kafka-vs-rocktemq-4/
	消息寫入性能	很是好 每條10個字節測試：百萬條/s	很好 每條10個字節測試：單機單broker約7w/s，單機3個broker約12w/s	RAM約爲RocketMQ的1/2， Disk的性能約爲RAM性能的1/3	數據來源於網絡 單條消息的數據量越小，性能對比時kafka表現越好	kafka vs RocktMQ： https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines kafka vs RocktMQ VS RabbitMQ  http://www.cnblogs.com/felixzh/p/6198070.html http://ju.outofmemory.cn/entry/177937
	性能的穩定性	隊列/分區多時性能不穩定，明顯降低。 消息堆積時性能穩定	隊列較多、消息堆積時性能穩定	消息堆積時，性能不穩定、明顯降低
	單機支持的隊列數	單機超過64個隊列/分區，Load會發生明顯的飆高現象，隊列越多，load越高，發送消息響應時間變長	單機支持最高5萬個隊列，Load不會發生明顯變化	依賴於內存	數據來源於網絡測評 kafka新能下降是由於topic增多時，順序寫變成了隨機寫	Kafka vs RocketMQ: Topic數量對單機性能的影響 http://jm.taobao.org/2016/04/07/kafka-vs-rocketmq-topic-amout/?utm_source=tuicool&utm_medium=referral
	堆積能力	很是好 消息存儲在log中，每一個分區由一個或多個segment  log文件	很是好 全部消息存儲在同一個commit log中	通常 生產者、消費者正常時，性能表現穩定；消費者不消費時，性能不穩定	http://www.cnblogs.com/purpleraintear/p/6033136.html
	複製備份	消息先寫入leader的log，followers從leader中pull數據，pull到數據之後先ack leader，而後寫入log中。 ISR中維護與leader同步的列表，落後太多的follwer會被刪除掉	同步雙寫 異步複製：slave啓動線程從master中拉數據	普通模式下不復制； 鏡像模式下：消息先到mster，而後寫到slave上。加入集羣以前的消息不會被複制到新的slave上。
	消息投遞實時性	毫秒級 具體由consumer輪詢間隔時間決定	毫秒級 支持pull、push兩種模式，延時一般在毫秒級	毫秒級
功能對比	順序消費	支持順序消費 可是一臺Broker宕機後，就會產生消息亂序(來自網上，還沒有找到緣由）	支持順序消費 在順序消息場景下，消費失敗時消費隊列將會暫停	支持順序消費
	定時消息	不支持	開源版本僅支持定時Level	不支持
	事務消息	不支持	支持	不支持
	Broker端消息過濾	不支持	支持 經過tag過濾，相似於子topic	不支持
	消息查詢	不支持	支持 根據MessageId查詢 支持根據MessageKey查詢消息	不支持
	消費失敗重試	不支持失敗重試 offset存儲在consumer中，沒法保證。 0.8.2版本後支持將offset存儲在zk中	支持失敗重試 offset存儲在broker中	支持失敗重試
	消息從新消費	支持經過修改offset來從新消費	支持按照時間來從新消息
	發送端負載均衡	可自由指定	可自由指定	須要單獨loadbalancer支持
	消費並行度	消費並行度和分區數一致	順序消費：消費並行度和分區數一致 亂序消費：消費服務器的消費線程數之和	可一次抓取多條一塊兒消費。 鏡像模式下其實也是從master消費
	消費方式	consumer pull	consumer pull ／broker push	broker push
	批量發送	支持 默認producer緩存、壓縮，而後批量發送	不支持	不支持
	消息清理	指定文件保存時間，過時刪除	指定文件保存時間，過時刪除	Consumer ack之後，消息將被標記爲刪除 可用內存少於40%（默認），觸發gc，gc時找到相鄰的兩個文件，合併right文件到left。
運維	系統維護	Scala語言開發，維護成本高	java語言開發，維護成本低	Erlang語言開發，維護成本高
	部署依賴	zookeeper	nameserver	Erlang環境
	管理後臺	官網不提供，第三方開源管理工具可供使用；不用從新開發	官方提供，rocketmq-console	官方提供rabbitmqadmin	kafka管理後臺比較；http://top.jobbole.com/31084/
	管理後臺功能	Kafka Web Conslole Brokers列表；Kafka 集羣中 Topic列表，及對應的Partition、LogSize等信息；Topic對應的Consumer Groups、Offset、Lag等信息； 生產和消費流量圖、消息預覽 KafkaOffsetMonitor： Kafka集羣狀態；Topic、Consumer Group列表；圖形化展現topic和consumer之間的關係；圖形化展現consumer的Offset、Lag等信息 Kafka Manager 管理幾個不一樣的集羣；監控集羣的狀態(topics, brokers, 副本分佈, 分區分佈)；產生分區分配(Generate partition assignments)基於集羣的當前狀態；從新分配分區	Cluster、Topic、Connection、NameServ、Message、Broker、Offset、Consumer	overview、connections、channels、exchanges、queues、admin
總結	優勢	一、在高吞吐、低延遲、高可用、集羣熱擴展、集羣容錯上有很是好的表現； 二、producer端提供緩存、壓縮功能，可節省性能，提升效率。 三、提供順序消費能力 四、提供多種客戶端語言 五、生態完善，在大數據處理方面有大量配套的設施。	一、在高吞吐、低延遲、高可用上有很是好的表現；消息堆積時，性能也很好。 二、api、系統設計都更加適在業務處理的場景。 三、支持多種消費方式。 四、支持broker消息過濾。 五、支持事務。 六、提供消息順序消費能力；consumer能夠水平擴展，消費能力很強。 七、集羣規模在50臺左右，單日處理消息上百億；經歷過大數據量的考驗，比較穩定可靠。	一、在高吞吐量、高可用上較前二者有所不如。 二、支持多種客戶端語言；支持amqp協議。 三、因爲erlang語言的特性，性能也比較好; 使用RAM模式時，性能很好。 四、管理界面較豐富，在互聯網公司也有較大規模的應用;	數據來自網絡
	缺點	一、消費集羣數目受到分區數目的限制。 二、單機topic多時，性能會明顯下降。 三、不支持事務	一、相比於kafka，使用者較少，生態不夠完善。消息堆積、吞吐率上也有所不如。 二、不支持主從自動切換，master失效後，消費者須要必定的時間才能感知。 三、客戶端只支持Java	一、erlang 語言難度較大。集羣不支持動態擴展。 二、不支持事務、消息吞吐能力有限 三、消息堆積時，性能會明顯下降

 

摘自:https://blog.csdn.net/wuzhengfei1112/article/details/78069645