訊息佇列（Message Queue）是一種使用高效可靠的資料傳輸機制來進行平臺無關的資料通訊的技術。訊息佇列擁有訊息傳遞、訊息生產、訊息消費、優先順序訊息等功能，為我們的分散式系統提供了資料通訊、功能解耦、彈性伸縮、資料冗餘、限流削峰、非同步訊息等豐富能力，是分散式系統的一個重要元件。

當前開源的訊息佇列的元件種類繁多，在Github上搜索Message Queue，就有4K+的資源。如此眾多的訊息佇列的開源專案中，我們耳熟能詳的有 RabbitMQ、Kafka、RocketMQ、ActiveMQ、Pulsar等等，很多公司也根據業務需求，定製了自己的訊息佇列中介軟體，比如騰訊的CMQ等。這些訊息佇列元件各自都有各自的特性與側重點，適合自己的才是最好的。

那麼如何選擇一款最合適的訊息佇列元件呢？本文選擇了RabbitMQ以及Kafka這兩款最為廣泛使用的訊息中間，來探討一下如何綜合考慮各種因素，比如消費模式、效能、語言支援、社群生態等來選擇一款稱手的訊息佇列元件。

概述

一、RabbitMQ****

RabbitMQ是一個歷史比較悠久的訊息佇列中介軟體，最早可以追溯到2007年，它是使用Erlang語言開發的一個AMQP（Advanced Message Queue Protocol 高階訊息佇列協議）實現。AMQP是一個應用層協議的開放標準，為面向訊息的中介軟體設計，基於此協議的客戶端與訊息中介軟體可傳遞訊息，並不受產品、開發語言等條件的限制。RabbitMQ最初起源於金融系統，它在可靠性、可用性、擴充套件性、訊息持久化、高併發等方面的有著卓越的表現。

二、Kafka

Kafka最早由LinkedIn公司開發，它是一個使用Scala語言開發的支援多分割槽，多副本並且基於Zookeeper協調的分散式訊息系統。它是一種高吞吐、低延遲、可容錯的分散式釋出訂閱訊息系統，憑藉其可水平擴充套件的高吞吐率而被廣泛使用。在大資料以及流式資料處理方面，Kafka的周邊生態也是其一大優勢，越來越多的開源分散式處理系統如 Cloudera、Apache Storm、Spark、Flink等都支援與 Kafka 整合。

對比

一、消費模式

消費模式是指訊息佇列消費訊息是時候的策略，分為兩種，一種是Push模式，一種是Pull模式。

Push模式是指訊息佇列的伺服器端收到新的訊息時主動將訊息推送(Push)到消費端，這種消費模式相比如Pull模式會有更好的實時性，但是當伺服器端訊息較多時，可能出現消費端來不及消費訊息從而壓垮消費端的情況，需要一定的策略來避免這種情況的發生。

Pull模式是指訊息佇列的伺服器不主動將訊息推送給消費端，而是有消費端主動地去從伺服器拉取(Pull)訊息，一般都是定時拉取或者定量拉取的方式。Pull模式相比與Push模式實時性會差一些，其優勢在於消費端可以根據自身消費訊息的能力去拉取訊息，不會出現訊息消費不過來的情況。

RabbitMQ既支援Push模式同時也支援Pull模式，而Kafka僅支援Pull模式。

二、訊息持久化

訊息持久化是指將訊息佇列中的訊息儲存至磁碟中，以防止在發生異常或者伺服器宕機等突發情況時發生資料丟失的情況。訊息持久化是保證訊息佇列訊息可靠性的關鍵技術之一。

RabbitMQ在預設情況下是不開啟持久化操作，exchange、queue、message等資料都是儲存在記憶體中的，這意味著如果 RabbitMQ 重啟、關閉、宕機時所有的資訊都將丟失。我們可以在使用RabbitMQ的時候顯式地將exchange、queue、message 等這些資料物件宣告為持久化，這樣一來，即便伺服器宕機或者故障了，我們也可以將這些資料從硬碟中進行恢復。不過需要注意的是，如果RabbitMQ將所有的這些物件都進行持久化操作，會嚴重地影響RabbitMQ的效能，因為同步寫入磁碟的速度會比寫記憶體慢很多，因此需要在可靠性與效能之間進行權衡。

相比與RabbitMQ需要顯式地指定資料型別的持久化，Kafka在設計之初就是依賴磁碟上的檔案系統來進行訊息的儲存。從傳統的觀念來講，磁碟的讀寫速度總是比記憶體慢很多，但是實際上磁碟讀寫速度的快慢取決於我們的使用方式：

“一塊SATA RAID-5陣列磁碟的線性寫速度可以達到幾百M_s，而隨機寫的速度只能是100多KB_s，線性寫的速度是隨機寫的上千倍”

Kafka的資料儲存設計是建立在對磁碟檔案進行追加寫的基礎上實現的，資料讀取也是順序訪問，這樣的資料儲存設計帶來了非常大的優勢：

1. 讀操作不會阻塞寫操作與其他操作，並且資料大小不會對效能產生影響；

2. 磁碟的容量相比與記憶體來說會大很多，訊息佇列的容量大，並且可以儲存任意時間，不用擔心故障導致資料丟失；

綜上所述，RabbitMQ和Kafka均支援訊息持久化，但是RabbitMQ需要顯式地開啟持久化，並且開啟持久化可能影響訊息佇列效能。而Kafka從設計之初便支援訊息持久化，並且通過優秀的設計保證了高效的訊息讀寫從而保證了較高的吞吐量。

三、效能

效能是我們進行技術選型的一個重要的參考維度，對於訊息佇列來講，我們最為關注的一個性能指標是其吞吐量。在吞吐量這個效能指標上，Kafka基於其優秀的儲存以及讀寫設計，相比於RabbitMQ擁有更高的效能。一般來說RabbitMQ的單機QPS在萬這個級別左右，而Kafka的單機QPS可以達到十萬級甚至百萬級。

這裡我沒有進行單機的吞吐量效能測試，援引網上的其他團隊進行的一次訊息佇列單機吞吐量效能測試，讓大家感受一下RabbitMQ與Kafka在吞吐量效能上的差距到底有多少。這次測試對比的是服務端傳送小訊息(124Byte)的效能，測試的策略是不斷增加發送端的壓力，直到系統的吞吐量不再上升，並且系統響應時間增長，這時候伺服器端可判斷已出現效能瓶頸，這時候的吞吐量即為系統的最高吞吐量。

測試的結果如下:

1. Kafka的單機吞吐量為17.3w/s，達到這個吞吐量時其Broker磁碟IO已經達到了瓶頸，Kafka能達到如此之高的單機吞吐量主要還是得益於其優秀的設計。

2. RabbitMQ的單機吞吐量為5.95w/s，並且CPU資源消耗較高，主要原因是其支援AMQP協議，實現地非常重量級，在訊息的可靠性與吞吐量上做了取捨。

由此可見，在吞吐量這個效能指標上，Kafka相比與RabbitMQ是具有明顯的優勢的。

說完了吞吐量，讓我們來討論一下另一個性能指標：時延。其實在使用訊息佇列的場景下討論時延是有些矛盾的，因為使用訊息佇列就代表了可以允許較高的時延，因為使用訊息佇列就可能產生訊息的堆積，並且訊息堆積的越多，從訊息生產到訊息消費的時延就越高，在對時延要求比較高的場景下使用訊息佇列是不合適的，我們應該使用時延更低的解決方案比如RPC遠端過程呼叫。

四、可靠性

訊息佇列訊息的可靠性也是我們進行技術選型的關鍵考慮因素之一，尤其涉及到金融、支付、安全等領域，訊息的可靠性就顯得尤為重要。保證訊息可靠性的關鍵技術之一訊息持久化，上文已經討論過，RabbitMQ以及Kafka均支援，我們這裡不做贅述。這裡我們來討論一下訊息佇列可靠性的另一個方面，訊息投遞（消費）的三種不同的保證：

1. 至多一次投遞：訊息最多會被投遞一次，但是可能丟失

2. 至少一次投遞：訊息至少會被投遞一次，但是可能重複消費

3. 精確一次投遞：保證只會被投遞一次，有且僅有一次

RabbitMQ以及Kafka都支援至多一次投遞以及至少一次投遞的保證，同時Kafka在0.11.0.0版本之後，通過事務機制支援了精確一次投遞的這種保證。

五、可用性

可靠性是保證訊息不會丟失或者重複消費，而這裡的可用性則是指系統正常執行時間佔總執行時間的百分比，高可用性也就對應著低故障率，那麼RabbitMQ與Kafka分別有什麼機制來保證系統的高可用呢？

RabbitMQ採用映象叢集的策略來保證系統的高可用性，在映象叢集模式下，無論是訊息佇列還是訊息都會儲存在叢集中的多個例項上。也就是說，對於叢集中的每個queue來說，叢集中的每個節點都有這個queue的完整映象，這樣一來，即使某個節點宕機了，也不會影響整個叢集的功能。並且即使是某個主節點宕機了，RabbitMQ叢集也可以通過選主演算法選舉新的主節點從而恢復正常服務。

Kafka的高可用性主要源自於其健壯的副本（Replication）策略。其採用的是類似 PacificA 的一致性協議，通過 ISR（In-Sync-Replica）來保證多副本之間的同步，並且支援強一致性語義（通過 acks 實現）。

六、社群生態及語言支援

從長遠的角度來講，社群生態是我們選擇解決方案考慮的關鍵因素之一，一個開源元件，使用的人越多，社群越活躍，則說明別人踩過的坑也就越多，在我們開發過程中遇到問題時就更加容易找到解決方案。同時，如果一個開源元件更新迭代很快，那麼它就可以迅速修復以前舊版本的問題，同時快速地迭代開發新功能。

在社群生態這方面，總體來說，Kafka的生態以及周邊環境相比於RabbitMQ更加的成熟和豐富，Kafka擁有更多的開源的客戶端、負載均衡元件，同時像Kubernetes、Spark等知名的開源專案也對Kafka有較好的支援。這可能也是得益於在大資料處理方面，Kafka的流式資料的概念和大資料處理更為的契合。

相比於Kafka，RabbitMQ的社群規模可能會較小一些，但是畢竟也是一個久經考驗的開源訊息佇列元件，總的來說我們在使用過程中一般也不會遇到社群解決不了的疑難問題。

在語言支援方面，RabbitMQ和Kafka支援的語言都非常的多，Kafka支援大約17種語言，RabbitMQ支援大約22中語言，主流的變成語言如Java、PHP、C++等等兩者均支援，相信在使用的程式語言方面不會有太大的問題。

結語

本文就兩種主流的訊息佇列元件RabbitMQ和Kafka進行了對比和探討，希望給大家在訊息佇列技術選型方面提供一定的思路。大家在選擇的時候要注意結合自己的業務需求，團隊的技術棧體系選擇最為合適的訊息佇列元件！

本文由部落格一文多發平臺 釋出！