Kafka、RabbitMQ、RocketMQ、ActiveMQ消息中間件的對比--多年生產經驗實踐總結

引言

分佈式系統中,咱們普遍運用消息中間件進行系統間的數據交換,便於異步解耦。如今開源的消息中間件有不少,前段時間咱們自家的產品 RocketMQ (MetaQ的內核) 也順利開源,獲得你們的關注。

那麼,消息中間件性能究竟哪家強?

帶着這個疑問,咱們中間件測試組對常見的三類消息產品(Kafka、RabbitMQ、RocketMQ)作了性能比較。

Kafka是LinkedIn開源的分佈式發佈-訂閱消息系統，目前歸屬於Apache定級項目。Kafka主要特色是基於Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用於日誌收集和傳輸。0.8版本開始支持複製，不支持事務，對消息的重複、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務。

RabbitMQ是使用Erlang語言開發的開源消息隊列系統，基於AMQP協議來實現。AMQP的主要特徵是面向消息、隊列、路由（包括點對點和發佈/訂閱）、可靠性、安全。AMQP協議更多用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。

RocketMQ是阿里開源的消息中間件，它是純Java開發，具備高吞吐量、高可用性、適合大規模分佈式系統應用的特色。RocketMQ思路起源於Kafka，但並非Kafka的一個Copy，它對消息的可靠傳輸及事務性作了優化，目前在阿里集團被普遍應用於交易、充值、流計算、消息推送、日誌流式處理、binglog分發等場景。

測試目的

對比Kafka、RabbitMQ、RocketMQ發送小消息(124字節)的性能。此次壓測咱們只關注服務端的性能指標,因此壓測的標準是:

不斷增長髮送端的壓力,直到系統吞吐量再也不上升,而響應時間拉長。這時服務端已出現性能瓶頸,能夠得到相應的系統最佳吞吐量。

測試場景

 

在同步發送場景中，三個消息中間件的表現區分明顯：

Kafka的吞吐量高達17.3w/s，不愧是高吞吐量消息中間件的行業老大。這主要取決於它的隊列模式保證了寫磁盤的過程是線性IO。此時broker磁盤IO已達瓶頸。

RocketMQ也表現不俗，吞吐量在11.6w/s，磁盤IO %util已接近100%。RocketMQ的消息寫入內存後即返回ack，由單獨的線程專門作刷盤的操做，全部的消息均是順序寫文件。

RabbitMQ的吞吐量5.95w/s，CPU資源消耗較高。它支持AMQP協議，實現很是重量級，爲了保證消息的可靠性在吞吐量上作了取捨。咱們還作了RabbitMQ在消息持久化場景下的性能測試，吞吐量在2.6w/s左右。

測試結論

在服務端處理同步發送的性能上，Kafka>RocketMQ>RabbitMQ。

附錄：

測試環境

服務端爲單機部署，機器配置以下：

 

應用版本：

 

測試腳本

 還有一個rocketmq/rabbitmq/kafka的對比，以下：

 除了上述特性外，rabbitmq和activemq都支持mqtt。activemq還支持ws（不過從tomcat 8開始，ws支持已經足夠完善，沒有必要爲了ws使用rabbitmq或activemq）。

實踐總結

這些年來，筆者普遍使用過rabbitmq、rocketmq、kafka，幾年前主推rabbitmq，如今切換到主推kafka。

因此若是不追求極致性能的話，2c activemq仍是比較好的，能夠同時支持app端mqtt和web端ws。中規中矩的話能夠選擇rabbtimq，畢竟最正統（這也是在除了日誌和數據異步同步場景外使用最普遍的MQ）。若是同時涉及到多種場景，例如日誌、同步、異步消息，安裝三方庫依賴等，推薦使用kafka。

雖然上面沒有包含redis，對於一級緩存之間的同步，採用redis消息隊列也是一種可接受的方案，即便它不正統，可是某些狀況下就是不須要MQ，可是又是集羣的時候，redis隊列就能夠做爲退化版MQ使用。

 參考：

kafka學習指南(總結版)

https://www.cnblogs.com/zhjh256/p/6444398.html

activemq支持的各類協議以及性能：http://haoran-10.iteye.com/blog/2259240

異步消息傳遞技術的比較：JMS、AMQP和MQTT http://blog.csdn.net/yongche_shi/article/details/52116755

web鏈接activemq ws：D:/apache-activemq-5.15.0/webapps-demo/demo/mqtt/index.html