原文鏈接：Kafka、RabbitMQ、RocketMQ等消息中間件的對比

消息中間件現(xiàn)在有不少，網(wǎng)上很多文章都對其做過對比，在這我對其做進一步總結(jié)與整理。

RocketMQ

淘寶內(nèi)部的交易系統(tǒng)使用了淘寶自主研發(fā)的Notify消息中間件，使用Mysql作為消息存儲媒介，可完全水平擴容，為了進一步降低成本，我們認為存儲部分可以進一步優(yōu)化，2011年初，Linkin開源了Kafka這個優(yōu)秀的消息中間件，淘寶中間件團隊在對Kafka做過充分Review之后，Kafka無限消息堆積，高效的持久化速度吸引了我們，但是同時發(fā)現(xiàn)這個消息系統(tǒng)主要定位于日志傳輸，對于使用在淘寶交易、訂單、充值等場景下還有諸多特性不滿足，為此我們重新用Java語言編寫了RocketMQ，定位于非日志的可靠消息傳輸（日志場景也OK），目前RocketMQ在阿里集團被廣泛應(yīng)用在訂單，交易，充值，流計算，消息推送，日志流式處理，binglog分發(fā)等場景。

Kafka

Kafka是LinkedIn開源的分布式發(fā)布-訂閱消息系統(tǒng)，目前歸屬于Apache定級項目。Kafka主要特點是基于Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用于日志收集和傳輸。0.8版本開始支持復(fù)制，不支持事務(wù)，對消息的重復(fù)、丟失、錯誤沒有嚴格要求，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。

RabbitMQ

RabbitMQ是使用Erlang語言開發(fā)的開源消息隊列系統(tǒng)，基于AMQP協(xié)議來實現(xiàn)。AMQP的主要特征是面向消息、隊列、路由（包括點對點和發(fā)布/訂閱）、可靠性、安全。AMQP協(xié)議更多用在企業(yè)系統(tǒng)內(nèi)，對數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。

有關(guān)測試結(jié)論

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

RocketMQ也表現(xiàn)不俗，吞吐量在11.6w/s，磁盤IO %util已接近100%。RocketMQ的消息寫入內(nèi)存后即返回ack，由單獨的線程專門做刷盤的操作，所有的消息均是順序?qū)懳募?/p>

RabbitMQ的吞吐量5.95w/s，CPU資源消耗較高。它支持AMQP協(xié)議，實現(xiàn)非常重量級，為了保證消息的可靠性在吞吐量上做了取舍。我們還做了RabbitMQ在消息持久化場景下的性能測試，吞吐量在2.6w/s左右。

在服務(wù)端處理同步發(fā)送的性能上，Kafka>RocketMQ>RabbitMQ。

對比了最簡單的小消息發(fā)送場景,Kafka暫時勝出。但是,作為經(jīng)受過歷次雙十一洗禮的RocketMQ,在互聯(lián)網(wǎng)應(yīng)用場景中更有它優(yōu)越的一面。

阿里官網(wǎng)對比

功能消息隊列 RocketMQApache RocketMQ

（開源）消息隊列 KafkaApache Kafka

（開源）RabbitMQ

（開源）安全防護支持不支持支持不支持支持主子賬號支持支持不支持支持不支持不支持可靠性- 同步刷盤

- 同步雙寫

- 超3份數(shù)據(jù)副本

- 99.99999999%- 同步刷盤

- 異步刷盤- 同步刷盤

- 同步雙寫

- 超3份數(shù)據(jù)副本

- 99.99999999%異步刷盤，丟數(shù)據(jù)概率高同步刷盤可用性- 非常好，99.95%

- Always Writable好- 非常好，99.95%

- Always Writable好好橫向擴展能力- 支持平滑擴展

- 支持百萬級 QPS支持- 支持平滑擴展

- 支持百萬級 QPS支持- 集群擴容依賴前端

- LVS 負載均衡調(diào)度Low Latency支持不支持支持不支持不支持消費模型Push / PullPush / PullPush / PullPullPush / Pull定時消息支持（可精確到秒級）支持（只支持18個固定 Level）暫不支持不支持支持事務(wù)消息支持不支持不支持不支持不支持順序消息支持支持暫不支持支持不支持全鏈路消息軌跡支持不支持暫不支持不支持不支持消息堆積能力百億級別

不影響性能百億級別

影響性能百億級別

不影響性能影響性能影響性能消息堆積查詢支持支持支持不支持不支持消息回溯支持支持支持不支持不支持消息重試支持支持暫不支持不支持支持死信隊列支持支持不支持不支持支持性能（常規(guī)）非常好

百萬級 QPS非常好

十萬級 QPS非常好

百萬級 QPS非常好

百萬級 QPS一般

萬級 QPS性能（萬級 Topic 場景）非常好

百萬級 QPS非常好

十萬級 QPS非常好

百萬級 QPS低低性能（海量消息堆積場景）非常好

百萬級 QPS非常好

十萬級 QPS非常好

百萬級 QPS低低

對比

ActiveMQRabbitMQRocketMqZeroMQKafka關(guān)注度高高中中高

成 熟度

成熟成熟比較成熟不成熟成熟

所屬社區(qū)/公司

ApacheMozilla

Public

License

Alibaba

Apache

社區(qū)活躍度高高中低高文檔多多中中多特點功能齊全，被大量開源項目使用由于Erlang 語言的并發(fā)能力，性能很好 各個環(huán)節(jié)分布式擴展設(shè)計，主從 HA；支持上萬個隊列；多種消費模式；性能很好低延時，高性能，最高 43萬條消息每秒

授權(quán)方式開源開源開源開源開源開發(fā)語言JavaErlangJavaC

支持的協(xié)議OpenWire、

STOMP、

REST、XMPP、

AMQPAMQP自己定義的一

套(社區(qū)提供

JMS--不成熟)TCP、UDP

客戶端支持語言Java、C、

C++、

Python、

PHP、

Perl、.net 等 Java、C、

C++、

Python、

PHP、

Perl、.net 等Java

C++（不成熟）python、 java、 php、.net 等

持久化內(nèi)存、文件、數(shù)據(jù)庫內(nèi)存、文件磁盤文件在消息發(fā)送端保存

事務(wù)支持不支持支持不支持

集群支持支持支持不支持

負載均衡支持支持支持不支持

管理界面一般好無社區(qū)有 web

console 實現(xiàn)無

部署方式獨立、嵌入獨立獨立獨立

順序無法保證嚴格的順序

保證嚴格的消費順序

評價優(yōu)點：

成熟的產(chǎn)品，已經(jīng)在很多公司得到應(yīng)用（非大規(guī)模場景）。有較多的文檔。各種協(xié)議支持較好，有多重語言的成熟的客戶端；

缺點：

根據(jù)其他用戶反饋，會出莫名其妙的問題，切會丟失消息。 其重心放到activemq6.0 產(chǎn)品—apollo 上去了，目前社區(qū)不活躍，且對 5.x 維護較少；

Activemq 不適合用于上千個隊列的應(yīng)用場景優(yōu)點： 由于erlang語言的特性，mq 性能較好；管理界面較豐富，在互聯(lián)網(wǎng)公司也有較大規(guī)模的應(yīng)用；支持amqp系誒，有多中語言且支持 amqp 的客戶端可用

缺點：

erlang語言難度較

大。集群不支持動態(tài)擴展。優(yōu)點：

模型簡單，接口易用（JMS 的接口很多場合并不太實用）。在阿里大規(guī)模應(yīng)用。目前支付寶中的余額寶等新興產(chǎn)

品均使用rocketmq。集群規(guī)模大概在50 臺左右，單日處理消息上百億；性能非常好，可以大量堆

積消息在broker 中；支持多種消費，包括集群消費、廣播消費等。開發(fā)度較活躍，版本更新很快。

缺點：

沒有在 mq 核心中去實現(xiàn)JMS 等接口，

RabbitMQ

是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合于企業(yè)級的開發(fā)。同時實現(xiàn)了一個經(jīng)紀人(Broker)構(gòu)架，這意味著消息在發(fā)送給客戶端時先在中心隊列排隊。對路由(Routing)，負載均衡(Load balance)或者數(shù)據(jù)持久化都有很好的支持。

Redis

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

ZeroMQ

號稱最快的消息隊列系統(tǒng)，尤其針對大吞吐量的需求場景。ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長的高級/復(fù)雜的隊列，但是開發(fā)人員需要自己組合多種技術(shù)框架，技術(shù)上的復(fù)雜度是對這MQ能夠應(yīng)用成功的挑戰(zhàn)。ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個消息服務(wù)器或中間件，因為你的應(yīng)用程序?qū)缪萘诉@個服務(wù)角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然后你就可以愉快的在應(yīng)用程序之間發(fā)送消息了。但是ZeroMQ僅提供非持久性的隊列，也就是說如果down機，數(shù)據(jù)將會丟失。其中，Twitter的Storm中使用ZeroMQ作為數(shù)據(jù)流的傳輸。

ActiveMQ

是Apache下的一個子項目。 類似于ZeroMQ，它能夠以代理人和點對點的技術(shù)實現(xiàn)隊列。同時類似于RabbitMQ，它少量代碼就可以高效地實現(xiàn)高級應(yīng)用場景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。

Jafka/Kafka

Kafka是Apache下的一個子項目，是一個高性能跨語言分布式Publish/Subscribe消息隊列系統(tǒng)，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統(tǒng)開銷下進行消息持久化；高吞吐，在一臺普通的服務(wù)器上既可以達到10W/s的吞吐速率；完全的分布式系統(tǒng)，Broker、Producer、Consumer都原生自動支持分布式，自動實現(xiàn)復(fù)雜均衡；支持Hadoop數(shù)據(jù)并行加載，對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的并行加載機制來統(tǒng)一了在線和離線的消息處理，這一點也是本課題所研究系統(tǒng)所看重的。Apache Kafka相對于ActiveMQ是一個非常輕量級的消息系統(tǒng)，除了性能非常好之外，還是一個工作良好的分布式系統(tǒng)。

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

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

redis 消息推送（基于分布式 pub/sub）多用于實時性較高的消息推送，并不保證可靠。

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

redis是內(nèi)存數(shù)據(jù)庫！redis他爹做了disque，你要不要試試。mq一般都采用訂閱～發(fā)布模型，如果你考慮性能，主要關(guān)注點就放在消費模型是pull還是push。影響最大的，應(yīng)該是存儲結(jié)構(gòu)。kafka的性能要在topic數(shù)量小于64的時候，才能發(fā)揮威力。partition決定的。極限情況下丟消息，例如：主寫入消息后，主機器宕機，并硬盤損壞。review代碼的時候發(fā)現(xiàn)的。rabbit不知道，但是rocket的性能是（萬條每秒），并且能夠橫向無限擴展，單機topic數(shù)量在256時，性能損失較小。rocket可以說是kafka的變種，是阿里在充分reviewkafka代碼后，開發(fā)的metaQ。在不斷更新，修補以后，阿里把metaQ3.0更名為rocket，并且rocket是java寫的易于維護。另外就是rocket和kafka有類似無限堆積的能力。想想，斷電不丟消息，積壓兩億條消息毫無壓力，niubilitykafka和rocket性能根本不是你需要考慮的問題。

在應(yīng)用場景方面，

RabbitMQ,遵循AMQP協(xié)議，由內(nèi)在高并發(fā)的erlanng語言開發(fā)，用在實時的對可靠性要求比較高的消息傳遞上。

kafka是Linkedin于2010年12月份開源的消息發(fā)布訂閱系統(tǒng),它主要用于處理活躍的流式數(shù)據(jù),大數(shù)據(jù)量的數(shù)據(jù)處理上。

在架構(gòu)模型方面，

RabbitMQ遵循AMQP協(xié)議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer通過連接channel和server進行通信，Consumer從queue獲取消息進行消費（長連接，queue有消息會推送到consumer端，consumer循環(huán)從輸入流讀取數(shù)據(jù)）。rabbitMQ以broker為中心；有消息的確認機制。

kafka遵從一般的MQ結(jié)構(gòu)，producer，broker，consumer，以consumer為中心，消息的消費信息保存的客戶端consumer上，consumer根據(jù)消費的點，從broker上批量pull數(shù)據(jù)；無消息確認機制。

在吞吐量，

kafka具有高的吞吐量，內(nèi)部采用消息的批量處理，zero-copy機制，數(shù)據(jù)的存儲和獲取是本地磁盤順序批量操作，具有O(1)的復(fù)雜度，消息處理的效率很高。

rabbitMQ在吞吐量方面稍遜于kafka，他們的出發(fā)點不一樣，rabbitMQ支持對消息的可靠的傳遞，支持事務(wù)，不支持批量的操作；基于存儲的可靠性的要求存儲可以采用內(nèi)存或者硬盤。

在可用性方面，

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

kafka的broker支持主備模式。

在集群負載均衡方面，

kafka采用zookeeper對集群中的broker、consumer進行管理，可以注冊topic到zookeeper上；通過zookeeper的協(xié)調(diào)機制，producer保存對應(yīng)topic的broker信息，可以隨機或者輪詢發(fā)送到broker上；并且producer可以基于語義指定分片，消息發(fā)送到broker的某分片上。

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

Kafka是可靠的分布式日志存儲服務(wù)。用簡單的話來說，你可以把Kafka當(dāng)作可順序?qū)懭氲囊淮缶泶艓?#xff0c; 可以隨時倒帶，快進到某個時間點重放。先說下日志的定義：日志是數(shù)據(jù)庫的核心，是對數(shù)據(jù)庫的所有變更的嚴格有序記錄，“表”是變更的結(jié)果。日志的其他名字有： 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))，充分利用了磁盤的物理特性，即，隨機寫入慢（磁頭沖停），順序?qū)懭肟?#xff08;磁頭懸浮）。高可靠性： 通過zookeeper做分布式一致性，同步到任意多塊磁盤上，故障自動切換選主，自愈。高容量：通過橫向擴展，LinkedIn每日通過Kafka存儲的新增數(shù)據(jù)高達175TB，8000億條消息，可無限擴容，類似把兩條磁帶粘到一起。傳統(tǒng)業(yè)務(wù)數(shù)據(jù)庫的根本缺陷在于：1. 太慢，讀寫太昂貴，無法避免的隨機尋址。（磁盤最快5ms尋址，固態(tài)又太昂貴。）2. 根本無法適應(yīng)持續(xù)產(chǎn)生的數(shù)據(jù)流，越用越慢。（索引效率問題）3. 無法水平scale。（多半是讀寫分離，一主多備。另: NewSQL通過一致性算法，有多主。）針對這些問題，Kafka提出了一種方法: “l(fā)og-centric approach（以日志為中心的方法）?！睂鹘y(tǒng)數(shù)據(jù)庫分為兩個獨立的系統(tǒng)，即日志系統(tǒng)和索引系統(tǒng)?！俺志没退饕珠_，日志盡可能快的落地，索引按照自己的速度追趕?！痹跀?shù)據(jù)可靠性在得到Kafka這種快速的，類似磁帶順序記錄方式保障的大前提下。數(shù)據(jù)的呈現(xiàn)，使用方式變得非常靈活，可以根據(jù)需要將數(shù)據(jù)流同時送入搜索系統(tǒng)，RDBMS系統(tǒng)，數(shù)據(jù)倉庫系統(tǒng)， 圖數(shù)據(jù)庫系統(tǒng)，日志分析等這些各種不同的數(shù)據(jù)庫系統(tǒng)。 這些不同的系統(tǒng)只不過是一種對Kafka磁帶數(shù)據(jù)的一種詮釋，一個側(cè)面，一個索引，一個快照。數(shù)據(jù)丟了，沒關(guān)系，重放一遍磁帶即可，更多的時候，對這些各式數(shù)據(jù)庫系統(tǒng)的維護只是需要定期做一個快照，并拷貝到一個安全的對象存儲(如S3) 而已。 一句話：“日志都是相同的日志，索引各有各的不同?！标P(guān)于流計算：在以流為基本抽象的存儲模型下，數(shù)據(jù)流和數(shù)據(jù)流之間，可以多流混合處理，或者流和狀態(tài)，狀態(tài)和狀態(tài)的JOIN處理，這就是Kafka Stream提供的功能。 一個簡單的例子是，在用戶觸發(fā)了某個事件后，和用戶表混合處理，產(chǎn)生數(shù)據(jù)增補（Augment)，再進入數(shù)據(jù)倉庫進行相關(guān)性分析，一些簡單的窗口統(tǒng)計和實時分析也很容易就能滿足，比如 在收到用戶登錄消息的時候，在線人數(shù)+1， 離線的時候-1，反應(yīng)出當(dāng)前系統(tǒng)的在線用戶總數(shù)。這方面可以參考PipelineDB https://www.pipelinedb.com/Kafka會讓你重新思考系統(tǒng)的構(gòu)建方式，使以前不可能的事變?yōu)榭赡?#xff0c;是一個系統(tǒng)中最重要的最核心的部分，不夸張的說，系統(tǒng)設(shè)計都需要圍繞Kafka做。

深入探討可以加筆者QQ：1120855315

點擊獲取免費Java免費視頻

添加QQ群837949026可以領(lǐng)取更多學(xué)習(xí)資料

總結(jié)

以上是生活随笔為你收集整理的kafka rabbitmq优劣对比_Kafka、RabbitMQ、RocketMQ等消息中间件的对比的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。