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

?文章來源地址http://www.zghlxwxcb.cn/news/detail-745121.html

?

RocketMQ

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

?

Kafka

Kafka是LinkedIn開源的分布式發(fā)布-訂閱消息系統(tǒng)，目前歸屬于Apache定級項目。Kafka主要特點是基于Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用于日志收集和傳輸。0.8版本開始支持復(fù)制，不支持事務(wù)，對消息的重復(fù)、丟失、錯誤沒有嚴(yán)格要求，適合產(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的吞吐量高達(dá)17.3w/s，不愧是高吞吐量消息中間件的行業(yè)老大。這主要取決于它的隊列模式保證了寫磁盤的過程是線性IO。此時broker磁盤IO已達(dá)瓶頸。

?

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)對比

功能 消息隊列 RocketMQ Apache RocketMQ

（開源） 消息隊列 Kafka Apache Kafka

（開源） RabbitMQ

（開源）

安全防護(hù) 支持 不支持 支持 不支持 支持

主子賬號支持 支持 不支持 支持 不支持 不支持

可靠性 - 同步刷盤

- 同步雙寫

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

- 99.99999999% - 同步刷盤

- 異步刷盤 - 同步刷盤

- 同步雙寫

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

- 99.99999999% 異步刷盤，丟數(shù)據(jù)概率高 同步刷盤

可用性 - 非常好，99.95%

- Always Writable 好 - 非常好，99.95%

- Always Writable 好 好

橫向擴(kuò)展能力 - 支持平滑擴(kuò)展

- 支持百萬級 QPS 支持 - 支持平滑擴(kuò)展

- 支持百萬級 QPS 支持 - 集群擴(kuò)容依賴前端

- LVS 負(fù)載均衡調(diào)度

Low Latency 支持 不支持 支持 不支持 不支持

消費模型 Push / Pull Push / Pull Push / Pull Pull Push / Pull

定時消息 支持（可精確到秒級） 支持（只支持18個固定 Level） 暫不支持 不支持 支持

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

順序消息 支持 支持 暫不支持 支持 不支持

全鏈路消息軌跡 支持 不支持 暫不支持 不支持 不支持

消息堆積能力 百億級別

不影響性能 百億級別

影響性能 百億級別

不影響性能 影響性能 影響性能

消息堆積查詢 支持 支持 支持 不支持 不支持

消息回溯 支持 支持 支持 不支持 不支持

消息重試 支持 支持 暫不支持 不支持 支持

死信隊列 支持 支持 不支持 不支持 支持

性能（常規(guī)） 非常好

百萬級 QPS 非常好

十萬級 QPS 非常好

百萬級 QPS 非常好

百萬級 QPS 一般

萬級 QPS

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

百萬級 QPS 非常好

十萬級 QPS 非常好

百萬級 QPS 低 低

性能（海量消息堆積場景） 非常好

百萬級 QPS 非常好

十萬級 QPS 非常好

百萬級 QPS 低 低

?

?

對比

? ActiveMQ RabbitMQ RocketMq ZeroMQ Kafka

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

成 熟度

?

? ? ? ? ? ? ? ??

?

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

所屬社區(qū)/公司

?

? ? ? ? ? ? ? ? ? ? ? ?

?

Apache Mozilla

Public

License?

Alibaba

?

Apache

?

? ?

社區(qū)活躍度 高 高 中 低 高

文檔 多 多 中 中 多

特點 功能齊全，被大量開源項目使用 由于Erlang 語言的并發(fā)能力，性能很好?

各個環(huán)節(jié)分布式擴(kuò)展設(shè)計，主從 HA；支持上萬個隊列；多種消費模式；性能很好 低延時，高性能，最高 43萬條消息每秒??

授權(quán)方式 開源 開源 開源 開源 開源

開發(fā)語言 Java Erlang Java C??

支持的協(xié)議 OpenWire、

STOMP、

REST、XMPP、

AMQP AMQP

自己定義的一

套(社區(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ù) 支持 不支持 支持 不支持??

集群 支持 支持 支持 不支持??

負(fù)載均衡 支持 支持 支持 不支持??

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

console 實現(xiàn) 無??

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

順序 無法保證嚴(yán)格的順序 保證嚴(yán)格的消費順序? ??

評價 優(yōu)點：

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

缺點：

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

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

?

缺點：

? erlang語言難度較

大。集群不支持動態(tài)擴(kuò)展。 優(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)紀(jì)人(Broker)構(gòu)架，這意味著消息在發(fā)送給客戶端時先在中心隊列排隊。對路由(Routing)，負(fù)載均衡(Load balance)或者數(shù)據(jù)持久化都有很好的支持。

?

Redis

是一個Key-Value的NoSQL數(shù)據(jù)庫，開發(fā)維護(hù)很活躍，雖然它是一個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的出隊性能則遠(yuǎn)低于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機(jī)，數(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)開銷下進(jìn)行消息持久化；高吞吐，在一臺普通的服務(wù)器上既可以達(dá)到10W/s的吞吐速率；完全的分布式系統(tǒng)，Broker、Producer、Consumer都原生自動支持分布式，自動實現(xiàn)復(fù)雜均衡；支持Hadoop數(shù)據(jù)并行加載，對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的并行加載機(jī)制來統(tǒng)一了在線和離線的消息處理，這一點也是本課題所研究系統(tǒng)所看重的。Apache Kafka相對于ActiveMQ是一個非常輕量級的消息系統(tǒng)，除了性能非常好之外，還是一個工作良好的分布式系統(tǒng)。

?

到了這里，關(guān)于Kafka、RabbitMQ、RocketMQ中間件的對比的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！