分佈式系統中,咱們普遍運用消息中間件進行系統間的數據交換,便於異步解耦。如今開源的消息中間件有不少,前段時間咱們自家的產品 RocketMQ (MetaQ的內核) 也順利開源,獲得你們的關注。 java
那麼,消息中間件性能究竟哪家強? 安全
帶着這個疑問,咱們中間件測試組對常見的三類消息產品(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字節)的性能。此次壓測咱們只關注服務端的性能指標,因此壓測的標準是: 測試
不斷增長髮送端的壓力,直到系統吞吐量再也不上升,而響應時間拉長。這時服務端已出現性能瓶頸,能夠得到相應的系統最佳吞吐量。 優化
在同步發送場景中,三個消息中間件的表現區分明顯: spa
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。
服務端爲單機部署,機器配置以下:
CPU | 24核 |
內存 | 94G |
硬盤 | Seagate Constellation ES (SATA 6Gb/s) 2,000,398,934,016 bytes [2.00 TB] 7202 rpm |
網卡 | 1000Mb/s |
應用版本:
消息中間件 | 版本 |
Kafka | 0.8.2 |
RabbitMQ | 3.5.4 |
RocketMQ | 3.4.6 |
壓力端 | Jmeter的java客戶端 |
消息大小 | 128字節 |
併發數 | 能達到服務端最大TPS的最優併發 |
Topic分區數量 | 8 |
刷盤策略 | Kafka和RocketMQ爲異步落盤,RabbitMQ的Queue不開啓durable持久化 |
前面咱們對比了最簡單的小消息發送場景,Kafka暫時勝出。可是,做爲經受過歷次雙十一洗禮的RocketMQ,在互聯網應用場景中更有它優越的一面。
接下來咱們會圍繞分區數量、消息大小、消費形式等不一樣的影響因子,對三類消息中間件作對比。敬請期待後續報告!