分散式系統中,我們廣泛運用訊息中介軟體進行系統間的資料交換,便於非同步解耦。現在開源的訊息中介軟體有很多,前段時間我們自家的產品 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。

附錄：

測試環境

服務端為單機部署，機器配置如下：

應用版本：

測試指令碼

前面我們對比了最簡單的小訊息傳送場景,Kafka暫時勝出。但是,作為經受過歷次雙十一洗禮的RocketMQ,在網際網路應用場景中更有它優越的一面。

RabbitMQ

是使用Erlang編寫的一個開源的訊息佇列，本身支援很多的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。同時實現了一個經紀人(Broker)構架，這意味著訊息在傳送給客戶端時先在中心佇列排隊。對路由(Routing)，負載均衡(Load balance)或者資料持久化都有很好的支援。

Redis

是一個Key-Value的NoSQL資料庫，開發維護很活躍，雖然它是一個Key-Value資料庫儲存系統，但它本身支援MQ功能，所以完全可以當做一個輕量級的佇列服務來使用。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試資料分為128Bytes、512Bytes、1K和10K四個不同大小的資料。實驗表明：入隊時，當資料比較小時Redis的效能要高於RabbitMQ，而如果資料大小超過了10K，Redis則慢的無法忍受；出隊時，無論資料大小，Redis都表現出非常好的效能，而RabbitMQ的出隊效能則遠低於Redis。

ZeroMQ

號稱最快的訊息佇列系統，尤其針對大吞吐量的需求場景。ZMQ能夠實現RabbitMQ不擅長的高階/複雜的佇列，但是開發人員需要自己組合多種技術框架，技術上的複雜度是對這MQ能夠應用成功的挑戰。ZeroMQ具有一個獨特的非中介軟體的模式，你不需要安裝和執行一個訊息伺服器或中介軟體，因為你的應用程式將扮演了這個服務角色。你只需要簡單的引用ZeroMQ程式庫，可以使用NuGet安裝，然後你就可以愉快的在應用程式之間傳送訊息了。但是ZeroMQ僅提供非永續性的佇列，也就是說如果down機，資料將會丟失。其中，Twitter的Storm中使用ZeroMQ作為資料流的傳輸。

ActiveMQ

是Apache下的一個子專案。 類似於ZeroMQ，它能夠以代理人和點對點的技術實現佇列。同時類似於RabbitMQ，它少量程式碼就可以高效地實現高階應用場景。RabbitMQ、ZeroMQ、ActiveMQ均支援常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。

Jafka/Kafka

Kafka是Apache下的一個子專案，是一個高效能跨語言分散式Publish/Subscribe訊息佇列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行訊息持久化；高吞吐，在一臺普通的伺服器上既可以達到10W/s的吞吐速率；完全的分散式系統，Broker、Producer、Consumer都原生自動支援分散式，自動實現複雜均衡；支援Hadoop資料並行載入，對於像Hadoop的一樣的日誌資料和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的並行載入機制來統一了線上和離線的訊息處理，這一點也是本課題所研究系統所看重的。Apache Kafka相對於ActiveMQ是一個非常輕量級的訊息系統，除了效能非常好之外，還是一個工作良好的分散式系統。

rabbitmq比kafka可靠，kafka更適合IO高吞吐的處理，比如ELK日誌收集**

Kafka和RabbitMq一樣是通用意圖訊息代理，他們都是以分散式部署為目的。但是他們對訊息語義模型的定義的假設是非常不同的。我對”AMQP 更成熟”這個論點是持懷疑態度的。讓我們用事實說話來看看用什麼解決方案來解決你的問題。
　　a) 以下場景你比較適合使用Kafka。你有大量的事件(10萬以上/秒)、你需要以分割槽的，順序的，至少傳遞成功一次到混雜了線上和打包消費的消費者、你希望能重讀訊息、你能接受目前是有限的節點級別高可用或則說你並不介意通過論壇/IRC工具得到還在幼兒階段的軟體的支援。
　　b) 以下場景你比較適合使用RabbitMQ。你有較少的事件（2萬以上/秒）並且需要通過複雜的路由邏輯去找到消費者、你希望訊息傳遞是可靠的、你並不關心訊息傳遞的順序、你需要現在就支援叢集-節點級別的高可用或則說你需要7*24小時的付費支援（當然也可以通過論壇/IRC工具）。

redis 訊息推送（基於分散式 pub/sub）多用於實時性較高的訊息推送，並不保證可靠。

redis 訊息推送（基於分散式 pub/sub）多用於實時性較高的訊息推送，並不保證可靠。其他的mq和kafka保證可靠但有一些延遲（非實時系統沒有保證延遲）。redis-pub/sub斷電就清空，而使用redis-list作為訊息推送雖然有持久化，但是又太弱智，也並非完全可靠不會丟。另外一點，redis 釋出訂閱除了表示不同的 topic 外，並不支援分組，比如kafka中釋出一個東西，多個訂閱者可以分組，同一個組裡只有一個訂閱者會收到該訊息，這樣可以用作負載均衡。比如，kafka 中釋出：topic = “釋出帖子” data=”文章1” 這個訊息，後面有一百臺伺服器每臺伺服器都是一個訂閱者，都訂閱了這個 topic，但是他們可能分為三組，A組50臺，用來真的做釋出文章，A組50臺裡所有 subscriber 都訂閱了這個topic。由於在同一組，這條訊息 （topic=”釋出帖子”, data=”文章1”）只會被A組裡面一臺當前空閒的機器收到。而B組25臺伺服器用於統計，C組25臺伺服器用於存檔備份，每組只有一臺會收到。用不同的組來決定每條訊息要抄送出多少分去，用同組內哪些訂閱者忙，哪些訂閱者空閒來決定訊息會被分到哪臺伺服器去處理，生產者消費者模型嘛。redis完全沒有這類機制，這兩點是最大的區別。

redis是記憶體資料庫！redis他爹做了disque，你要不要試試。mq一般都採用訂閱～釋出模型，如果你考慮效能，主要關注點就放在消費模型是pull還是push。影響最大的，應該是儲存結構。kafka的效能要在topic數量小於64的時候，才能發揮威力。partition決定的。極限情況下丟訊息，例如：主寫入訊息後，主機器宕機，並硬碟損壞。review程式碼的時候發現的。rabbit不知道，但是rocket的效能是（萬條每秒），並且能夠橫向無限擴充套件，單機topic數量在256時，效能損失較小。rocket可以說是kafka的變種，是阿里在充分reviewkafka程式碼後，開發的metaQ。在不斷更新，修補以後，阿里把metaQ3.0更名為rocket，並且rocket是java寫的易於維護。另外就是rocket和kafka有類似無限堆積的能力。想想，斷電不丟訊息，積壓兩億條訊息毫無壓力，niubilitykafka和rocket效能根本不是你需要考慮的問題。

在應用場景方面，

RabbitMQ,遵循AMQP協議，由內在高併發的erlanng語言開發，用在實時的對可靠性要求比較高的訊息傳遞上。

kafka是Linkedin於2010年12月份開源的訊息釋出訂閱系統,它主要用於處理活躍的流式資料,大資料量的資料處理上。

在架構模型方面，

RabbitMQ遵循AMQP協議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了訊息的路由鍵；客戶端Producer通過連線channel和server進行通訊，Consumer從queue獲取訊息進行消費（長連線，queue有訊息會推送到consumer端，consumer迴圈從輸入流讀取資料）。rabbitMQ以broker為中心；有訊息的確認機制。

kafka遵從一般的MQ結構，producer，broker，consumer，以consumer為中心，訊息的消費資訊儲存的客戶端consumer上，consumer根據消費的點，從broker上批量pull資料；無訊息確認機制。

在吞吐量，

kafka具有高的吞吐量，內部採用訊息的批量處理，zero-copy機制，資料的儲存和獲取是本地磁碟順序批量操作，具有O(1)的複雜度，訊息處理的效率很高。

rabbitMQ在吞吐量方面稍遜於kafka，他們的出發點不一樣，rabbitMQ支援對訊息的可靠的傳遞，支援事務，不支援批量的操作；基於儲存的可靠性的要求儲存可以採用記憶體或者硬碟。

在可用性方面，

rabbitMQ支援miror的queue，主queue失效，miror queue接管。

kafka的broker支援主備模式。

在叢集負載均衡方面，

kafka採用zookeeper對叢集中的broker、consumer進行管理，可以註冊topic到zookeeper上；通過zookeeper的協調機制，producer儲存對應topic的broker資訊，可以隨機或者輪詢傳送到broker上；並且producer可以基於語義指定分片，訊息傳送到broker的某分片上。

rabbitMQ的負載均衡需要單獨的loadbalancer進行支援。

Kafka是可靠的分散式日誌儲存服務。用簡單的話來說，你可以把Kafka當作可順序寫入的一大卷磁帶， 可以隨時倒帶，快進到某個時間點重放。先說下日誌的定義：日誌是資料庫的核心，是對資料庫的所有變更的嚴格有序記錄，“表”是變更的結果。日誌的其他名字有： Changelog, Write Ahead Log, Commit Log, Redo Log, Journaling.Kafka的特徵如下：高寫入速度：Kafka能以超過1Gbps NIC的速度寫這盤磁帶（實際可以到SATA 3速度，參考Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines))，充分利用了磁碟的物理特性，即，隨機寫入慢（磁頭衝停），順序寫入快（磁頭懸浮）。高可靠性： 通過zookeeper做分散式一致性，同步到任意多塊磁碟上，故障自動切換選主，自愈。高容量：通過橫向擴充套件，LinkedIn每日通過Kafka儲存的新增資料高達175TB，8000億條訊息，可無限擴容，類似把兩條磁帶粘到一起。傳統業務資料庫的根本缺陷在於：1. 太慢，讀寫太昂貴，無法避免的隨機定址。（磁碟最快5ms定址，固態又太昂貴。）2. 根本無法適應持續產生的資料流，越用越慢。（索引效率問題）3. 無法水平scale。（多半是讀寫分離，一主多備。另: NewSQL通過一致性演算法，有多主。）針對這些問題，Kafka提出了一種方法: “log-centric approach（以日誌為中心的方法）。”將傳統資料庫分為兩個獨立的系統，即日誌系統和索引系統。“持久化和索引分開，日誌儘可能快的落地，索引按照自己的速度追趕。”在資料可靠性在得到Kafka這種快速的，類似磁帶順序記錄方式保障的大前提下。資料的呈現，使用方式變得非常靈活，可以根據需要將資料流同時送入搜尋系統，RDBMS系統，資料倉庫系統， 圖資料庫系統，日誌分析等這些各種不同的資料庫系統。 這些不同的系統只不過是一種對Kafka磁帶資料的一種詮釋，一個側面，一個索引，一個快照。資料丟了，沒關係，重放一遍磁帶即可，更多的時候，對這些各式資料庫系統的維護只是需要定期做一個快照，並拷貝到一個安全的物件儲存(如S3) 而已。 一句話：“日誌都是相同的日誌，索引各有各的不同。”關於流計算：在以流為基本抽象的儲存模型下，資料流和資料流之間，可以多流混合處理，或者流和狀態，狀態和狀態的JOIN處理，這就是Kafka Stream提供的功能。 一個簡單的例子是，在使用者觸發了某個事件後，和使用者表混合處理，產生資料增補（Augment)，再進入資料倉庫進行相關性分析，一些簡單的視窗統計和實時分析也很容易就能滿足，比如 在收到使用者登入訊息的時候，線上人數+1， 離線的時候-1，反應出當前系統的線上使用者總數。這方面可以參考PipelineDB https://www.pipelinedb.com/Kafka會讓你重新思考系統的構建方式，使以前不可能的事變為可能，是一個系統中最重要的最核心的部分，不誇張的說，系統設計都需要圍繞Kafka做。

--------------------- 本文來自 混沌風YF 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/yunfeng482/article/details/72856762?utm_source=copy