消息中間件的對比

-	-	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
總結	優點	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、消息堆積時，性能會明顯降低