RocketMQ、Kafka、RabbitMQ的詳細對比

引言

分佈式系統中,我們廣泛運用消息中間件進行系統間的數據交換,便於異步解耦。現在開源的消息中間件有很多,目前對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
	可用性	非常高 分佈式、主從	非常高 分佈式、主從	高 主從，採用鏡像模式實現，數據量大時可能產生性能瓶頸
	主從切換	自動切換 N個副本，允許N-1個失效；master失效以後自動從isr中選擇一個主；	不支持自動切換 master失效以後不能向master發送信息，consumer大概30s（默認）可以感知此事件，此後從slave消費；如果master無法恢復，異步複製時可能出現部分信息丟失	自動切換 最早加入集羣的slave會成爲master；因爲新加入的slave不同步master之前的數據，所以可能會出現部分數據丟失
	數據可靠性	很好 支持producer單條發送、同步刷盤、同步複製、異步。	很好 producer單條發送，broker端支持同步刷盤、異步刷盤，同步雙寫，異步複製。	好 producer支持同步／異步ack。支持隊列數據持久化，鏡像模式中支持主從同步
	消息寫入性能	非常好 每條10個字節測試：百萬條/s	很好 每條10個字節測試：單機單broker約7w/s，單機3個broker約12w/s	RAM約爲RocketMQ的1/2， Disk的性能約爲RAM性能的1/3
	性能的穩定性	隊列/分區多時性能不穩定，明顯下降。 消息堆積時性能穩定	隊列較多、消息堆積時性能穩定	消息堆積時，性能不穩定、明顯下降
	單機支持的隊列數	單機超過64個隊列/分區，Load會發生明顯的飆高現象，隊列越多，load越高，發送消息響應時間變長	單機支持最高5萬個隊列，Load不會發生明顯變化	依賴於內存
	堆積能力	非常好 消息存儲在log中，每個分區由一個或多個segment  log文件	非常好 所有消息存儲在同一個commit log中	一般 生產者、消費者正常時，性能表現穩定；消費者不消費時，性能不穩定
	複製備份	消息先寫入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 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
總結	優點	1、在高吞吐、低延遲、高可用、集羣熱擴展、集羣容錯上有非常好的表現； 2、producer端提供緩存、壓縮功能，可節省性能，提高效率。 3、提供順序消費能力 4、提供多種客戶端語言 5、生態完善，在大數據處理方面有大量配套的設施。	1、在高吞吐、低延遲、高可用上有非常好的表現；消息堆積時，性能也很好。 2、api、系統設計都更加適在業務處理的場景。 3、支持多種消費方式。 4、支持broker消息過濾。 5、支持事務。 6、提供消息順序消費能力；consumer可以水平擴展，消費能力很強。 7、集羣規模在50臺左右，單日處理消息上百億；經歷過大數據量的考驗，比較穩定可靠。	1、在高吞吐量、高可用上較前兩者有所不如。 2、支持多種客戶端語言；支持amqp協議。 3、由於erlang語言的特性，性能也比較好; 使用RAM模式時，性能很好。 4、管理界面較豐富，在互聯網公司也有較大規模的應用;
	缺點	1、消費集羣數目受到分區數目的限制。 2、單機topic多時，性能會明顯降低。 3、不支持事務	1、相比於kafka，使用者較少，生態不夠完善。消息堆積、吞吐率上也有所不如。 2、不支持主從自動切換，master失效後，消費者需要一定的時間才能感知。 3、客戶端只支持Java	1、erlang 語言難度較大。集羣不支持動態擴展。 2、不支持事務、消息吞吐能力有限 3、消息堆積時，性能會明顯降低