怎么進行Kafka、RabbitMQ、RocketMQ等消息中間件的介紹和對比

怎么進行Kafka、RabbitMQ、RocketMQ等消息中間件的介紹和對比，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

前言

在分布式系統中,我們廣泛運用消息中間件進行系統間的數據交換,便于異步解耦?，F在開源的消息中間件有很多,前段時間產品 RocketMQ (MetaQ的內核) 也順利開源,得到大家的關注。

概念

MQ簡介

MQ,Message queue,消息隊列，就是指保存消息的一個容器。具體的定義這里就不類似于數據庫、緩存等，用來保存數據的。當然，與數據庫、緩存等產品比較，也有自己一些特點，具體的特點后文會做詳細的介紹。

現在常用的MQ組件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ、MetaMQ，當然近年來火熱的kafka,從某些場景來說，也是MQ，當然kafka的功能更加強大，雖然不同的MQ都有自己的特點和優勢，但是，不管是哪種MQ，都有MQ本身自帶的一些特點，下面，介紹MQ的特點。

MQ特點

1、先進先出

不能先進先出，都不能說是隊列了。消息隊列的順序在入隊的時候就基本已經確定了，一般是不需人工干預的。而且，最重要的是，數據是只有一條數據在使用中。這也是MQ在諸多場景被使用的原因。

2、發布訂閱

發布訂閱是一種很高效的處理方式，如果不發生阻塞，基本可以當做是同步操作。這種處理方式能非常有效的提升服務器利用率，這樣的應用場景非常廣泛。

3、持久化

持久化確保MQ的使用不只是一個部分場景的輔助工具，而是讓MQ能像數據庫一樣存儲核心的數據。

4、分布式

在現在大流量、大數據的使用場景下，只支持單體應用的服務器軟件基本是無法使用的，支持分布式的部署，才能被廣泛使用。而且，MQ的定位就是一個高性能的中間件。

應用場景

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

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

Kafka

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

RabbitMQ

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

RocketMQ

RocketMQ是阿里開源的消息中間件，它是純Java開發，具有高吞吐量、高可用性、適合大規模分布式系統應用的特點。RocketMQ思路起源于Kafka，但并不是Kafka的一個Copy，它對消息的可靠傳輸及事務性做了優化，目前在阿里集團被廣泛應用于交易、充值、流計算、消息推送、日志流式處理、binglog分發等場景。

測試目的

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

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

測試場景

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

Kafka

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

RocketMQ

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

RabbitMQ

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 ActiveMQ 是最受歡迎且功能最強大的開源消息傳遞和Integration Patterns服務器。

Apache ActiveMQ速度快，支持許多跨語言客戶端和協議，帶有易于使用的企業集成模式和許多高級功能，同時完全支持JMS 1.1和J2EE 1.4。Apache ActiveMQ是在Apache 2.0許可下發布

特征

支持Java消息服務(JMS) 1.1 版本

Spring Framework

集群 (Clustering)

支持的編程語言包括：C、C++、C#、Delphi、Erlang、Adobe Flash、Haskell、Java、JavaScript、Perl、PHP、Pike、Python和Ruby

協議支持包括：OpenWire、REST、STOMP、WS-Notification、MQTT、XMPP以及AMQP [1]

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作者做內存數據庫基礎上增加了消息pub/sub。mq一般都采用訂閱～發布模型，如果你考慮性能，主要關注點就放在消費模型是pull還是push。影響最大的，應該是存儲結構。kafka的性能要在topic數量小于64的時候，才能發揮威力。partition決定的。極限情況下丟消息，例如：主寫入消息后，主機器宕機，并硬盤損壞。review代碼的時候發現的。rabbit不知道，但是rocket的性能是（萬條每秒），并且能夠橫向無限擴展，單機topic數量在256時，性能損失較小。rocket可以說是kafka的變種，是阿里在充分reviewkafka代碼后，開發的metaQ。在不斷更新，修補以后，阿里把metaQ3.0更名為rocket，并且rocket是java寫的易于維護。另外就是rocket和kafka有類似無限堆積的能力。想想，斷電不丟消息，積壓兩億條消息毫無壓力，niubility kafka和rocket mq性能根本不需要考慮的問題。

1）在應用場景方面，

RabbitMQ

RabbitMQ遵循AMQP協議，由內在高并發的erlanng語言開發，用在實時的對可靠性要求比較高的消息傳遞上，適合企業級的消息發送訂閱，也是比較受到大家歡迎的。

kafka

kafka是Linkedin于2010年12月份開源的消息發布訂閱系統,它主要用于處理活躍的流式數據,大數據量的數據處理上。常用日志采集，數據采集上。

ActiveMQ

異步調用

一對多通信

做多個系統的集成，同構、異構

作為RPC的替代

多個應用相互解耦

作為事件驅動架構的幕后支撐

為了提高系統的可伸縮性

2）在架構模型方面，

RabbitMQ

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

kafka

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

3）在吞吐量，

kafka

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

rabbitMQ

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

4）在可用性方面，

rabbitMQ

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

kafka

kafka的broker支持主備模式。

5）在集群負載均衡方面，

kafka

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

rabbitMQ

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

6）其他

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（以日志為中心的方法）?！睂鹘y數據庫分為兩個獨立的系統，即日志系統和索引系統?！俺志没退饕珠_，日志盡可能快的落地，索引按照自己的速度追趕?！痹跀祿煽啃栽诘玫終afka這種快速的，類似磁帶順序記錄方式保障的大前提下。數據的呈現，使用方式變得非常靈活，可以根據需要將數據流同時送入搜索系統，RDBMS系統，數據倉庫系統， 圖數據庫系統，日志分析等這些各種不同的數據庫系統。這些不同的系統只不過是一種對Kafka磁帶數據的一種詮釋，一個側面，一個索引，一個快照。數據丟了，沒關系，重放一遍磁帶即可，更多的時候，對這些各式數據庫系統的維護只是需要定期做一個快照，并拷貝到一個安全的對象存儲(如S3) 而已。一句話：“日志都是相同的日志，索引各有各的不同?！?/p>

關于流計算：在以流為基本抽象的存儲模型下，數據流和數據流之間，可以多流混合處理，或者流和狀態，狀態和狀態的JOIN處理，這就是Kafka Stream提供的功能。一個簡單的例子是，在用戶觸發了某個事件后，和用戶表混合處理，產生數據增補（Augment)，再進入數據倉庫進行相關性分析，一些簡單的窗口統計和實時分析也很容易就能滿足，比如 在收到用戶登錄消息的時候，在線人數+1， 離線的時候-1，反應出當前系統的在線用戶總數。

關于怎么進行Kafka、RabbitMQ、RocketMQ等消息中間件的介紹和對比問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。