RabbitMQ 和 Kafka 的顯著差異

 

RabbitMQ 是一個消息代理，但是 Apache Kafka 是一個分布式流式系統。好像從語義上就可以看出差異，但是它們內部的一些特性會影響到我們是否能夠很好的設計各種用例。

 

例如，Kafka 最適用于數據的流式處理，但是 RabbitMQ 對流式中的消息就很難保持它們的順序。

 

另一方面，RabbitMQ 內置重試邏輯和死信（dead-letter）交換器，但是 Kafka 只是把這些實現邏輯交給用戶來處理。

 

這部分主要強調在不同系統之間它們的主要差異。

 

消息順序

 

對于發送到隊列或者交換器上的消息，RabbitMQ 不保證它們的順序。盡管消費者按照順序處理生產者發來的消息看上去很符合邏輯，但是這有很大誤導性。

RabbitMQ 文檔中有關于消息順序保證的說明：

“發布到一個通道（channel）上的消息，用一個交換器和一個隊列以及一個出口通道來傳遞，那么最終會按照它們發送的順序接收到。” 

 

——RabbitMQ 代理語義（Broker Semantics）

 

換話句話說，只要我們是單個消費者，那么接收到的消息就是有序的。然而，一旦有多個消費者從同一個隊列中讀取消息，那么消息的處理順序就沒法保證了。

 

由于消費者讀取消息之后可能會把消息放回（或者重傳）到隊列中（例如，處理失敗的情況），這樣就會導致消息的順序無法保證。

 

一旦一個消息被重新放回隊列，另一個消費者可以繼續處理它，即使這個消費者已經處理到了放回消息之后的消息。

 

因此，消費者組處理消息是無序的，如下表所示：

使用 RabbitMQ 丟失消息順序的例子

 

當然，我們可以通過限制消費者的并發數等于 1 來保證 RabbitMQ 中的消息有序性。

 

更準確點說，限制單個消費者中的線程數為 1，因為任何的并行消息處理都會導致無序問題。

 

不過，隨著系統規模增長，單線程消費者模式會嚴重影響消息處理能力。所以，我們不要輕易的選擇這種方案。

 

另一方面，對于 Kafka 來說，它在消息處理方面提供了可靠的順序保證。Kafka 能夠保證發送到相同主題分區的所有消息都能夠按照順序處理。

 

回顧第一篇文章介紹，默認情況下，Kafka 會使用循環分區器（round-robin partitioner）把消息放到相應的分區上。

 

不過，生產者可以給每個消息設置分區鍵（key）來創建數據邏輯流（比如來自同一個設備的消息，或者屬于同一租戶的消息）。

 

所有來自相同流的消息都會被放到相同的分區中，這樣消費者組就可以按照順序處理它們。

 

但是，我們也應該注意到，在同一個消費者組中，每個分區都是由一個消費者的一個線程來處理。結果就是我們沒法伸縮（scale）單個分區的處理能力。

 

不過，在 Kafka 中，我們可以伸縮一個主題中的分區數量，這樣可以讓每個分區分擔更少的消息，然后增加更多的消費者來處理額外的分區。

 

獲勝者：顯而易見，Kafka 是獲勝者，因為它可以保證按順序處理消息。RabbitMQ 在這塊就相對比較弱。

 

消息路由

 

RabbitMQ 可以基于定義的訂閱者路由規則路由消息給一個消息交換器上的訂閱者。一個主題交換器可以通過一個叫做 routing_key 的特定頭來路由消息。

 

或者，一個頭部（headers）交換器可以基于任意的消息頭來路由消息。這兩種交換器都能夠有效地讓消費者設置他們感興趣的消息類型，因此可以給解決方案架構師提供很好的靈活性。

 

另一方面，Kafka 在處理消息之前是不允許消費者過濾一個主題中的消息。一個訂閱的消費者在沒有異常情況下會接受一個分區中的所有消息。

 

作為一個開發者，你可能使用 Kafka 流式作業（job），它會從主題中讀取消息，然后過濾，最后再把過濾的消息推送到另一個消費者可以訂閱的主題。但是，這需要更多的工作量和維護，并且還涉及到更多的移動操作。

 

獲勝者：在消息路由和過濾方面，RabbitMQ 提供了更好的支持。

 

消息時序（timing）

 

在測定發送到一個隊列的消息時間方面，RabbitMQ 提供了多種能力：

 

①消息存活時間（TTL）

 

發送到 RabbitMQ 的每條消息都可以關聯一個 TTL 屬性。發布者可以直接設置 TTL 或者根據隊列的策略來設置。

 

系統可以根據設置的 TTL 來限制消息的有效期。如果消費者在預期時間內沒有處理該消息，那么這條消息會自動的從隊列上被移除（并且會被移到死信交換器上，同時在這之后的消息都會這樣處理）。

 

TTL 對于那些有時效性的命令特別有用，因為一段時間內沒有處理的話，這些命令就沒有什么意義了。

 

②延遲/預定的消息

 

RabbitMQ 可以通過插件的方式來支持延遲或者預定的消息。當這個插件在消息交換器上啟用的時候，生產者可以發送消息到 RabbitMQ 上，然后這個生產者可以延遲 RabbitMQ 路由這個消息到消費者隊列的時間。

 

這個功能允許開發者調度將來（future）的命令，也就是在那之前不應該被處理的命令。

 

例如，當生產者遇到限流規則時，我們可能會把這些特定的命令延遲到之后的一個時間執行。

 

Kafka 沒有提供這些功能。它在消息到達的時候就把它們寫入分區中，這樣消費者就可以立即獲取到消息去處理。

 

Kafka 也沒用為消息提供 TTL 的機制，不過我們可以在應用層實現。

 

不過，我們必須要記住的一點是 Kafka 分區是一種追加模式的事務日志。所以，它是不能處理消息時間（或者分區中的位置）。

 

獲勝者：毫無疑問，RabbitMQ 是獲勝者，因為這種實現天然的就限制 Kafka。

 

消息留存（retention）

 

當消費者成功消費消息之后，RabbitMQ 就會把對應的消息從存儲中刪除。這種行為沒法修改。它幾乎是所有消息代理設計的必備部分。

 

相反，Kafka 會給每個主題配置超時時間，只要沒有達到超時時間的消息都會保留下來。

 

在消息留存方面，Kafka 僅僅把它當做消息日志來看待，并不關心消費者的消費狀態。

 

消費者可以不限次數的消費每條消息，并且他們可以操作分區偏移來“及時”往返的處理這些消息。

 

Kafka 會周期的檢查分區中消息的留存時間，一旦消息超過設定保留的時長，就會被刪除。

 

Kafka 的性能不依賴于存儲大小。所以，理論上，它存儲消息幾乎不會影響性能（只要你的節點有足夠多的空間保存這些分區）。

 

獲勝者：Kafka 設計之初就是保存消息的，但是 RabbitMQ 并不是。所以這塊沒有可比性，Kafka 是獲勝者。

 

容錯處理

 

當處理消息，隊列和事件時，開發者常常認為消息處理總是成功的。畢竟，生產者把每條消息放入隊列或者主題后，即使消費者處理消息失敗了，它僅僅需要做的就是重新嘗試，直到成功為止。

 

盡管表面上看這種方法是沒錯的，但是我們應該對這種處理方式多思考一下。首先我們應該承認，在某些場景下，消息處理會失敗。

 

所以，即使在解決方案部分需要人為干預的情況下，我們也要妥善地處理這些情況。

 

消息處理存在兩種可能的故障：

• 瞬時故障：故障產生是由于臨時問題導致，比如網絡連接，CPU 負載，或者服務崩潰。我們可以通過一遍又一遍的嘗試來減輕這種故障。

• 持久故障：故障產生是由于永久的問題導致的，并且這種問題不能通過額外的重試來解決。比如常見的原因有軟件 Bug 或者無效的消息格式（例如，損壞（poison）的消息）

 

作為架構師和開發者，我們應該問問自己：“對于消息處理故障，我們應該重試多少次？每一次重試之間我們應該等多久？我們怎樣區分瞬時和持久故障？”

 

最重要的是：“所有重試都失敗后或者遇到一個持久的故障，我們要做什么？”

 

當然，不同業務領域有不同的回答，消息系統一般會給我們提供工具讓我們自己實現解決方案。
RabbitMQ 會給我們提供諸如交付重試和死信交換器（DLX）來處理消息處理故障。

 

DLX 的主要思路是根據合適的配置信息自動地把路由失敗的消息發送到 DLX，并且在交換器上根據規則來進一步的處理，比如異常重試，重試計數以及發送到“人為干預”的隊列。

 

查看這篇文章[1]，它在 RabbitMQ 處理重試上提供了額外的可能模式視角。

 

在 RabbitMQ 中我們需要記住最重要的事情是當一個消費者正在處理或者重試某個消息時（即使是在把它返回隊列之前），其他消費者都可以并發的處理這個消息之后的其他消息。

 

當某個消費者在重試處理某條消息時，作為一個整體的消息處理邏輯不會被阻塞。

 

所以，一個消費者可以同步地去重試處理一條消息，不管花費多長時間都不會影響整個系統的運行。

消費者 1 持續的在重試處理消息 1，同時其他消費者可以繼續處理其他消息

 

和 RabbitMQ 相反，Kafka 沒有提供這種開箱即用的機制。在 Kafka 中，需要我們自己在應用層提供和實現消息重試機制。

 

另外，我們需要注意的是當一個消費者正在同步地處理一個特定的消息時，那么同在這個分區上的其他消息是沒法被處理的。

 

由于消費者不能改變消息的順序，所以我們不能夠拒絕和重試一個特定的消息以及提交一個在這個消息之后的消息。你只要記住，分區僅僅是一個追加模式的日志。

 

一個應用層解決方案可以把失敗的消息提交到一個“重試主題”，并且從那個主題中處理重試；但是這樣的話我們就會丟失消息的順序。

 

我們可以在 Uber.com 上找到 Uber 工程師實現的一個例子。如果消息處理的時延不是關注點，那么對錯誤有足夠監控的 Kafka 方案可能就足夠了。

 

如果消費者阻塞在重試一個消息上，那么底部分區的消息就不會被處理。

 

獲勝者：RabbitMQ 是獲勝者，因為它提供了一個解決這個問題的開箱即用的機制。

伸縮

有多個基準測試，用于檢查 RabbitMQ 和 Kafka 的性能。

 

盡管通用的基準測試對一些特定的情況會有限制，但是 Kafka 通常被認為比 RabbitMQ 有更優越的性能。
Kafka 使用順序磁盤 I/O 來提高性能。從 Kafka 使用分區的架構上看，它在橫向擴展上會優于 RabbitMQ，當然 RabbitMQ 在縱向擴展上會有更多的優勢。

 

Kafka 的大規模部署通常每秒可以處理數十萬條消息，甚至每秒百萬級別的消息。

 

過去，Pivotal 記錄了一個 Kafka 集群每秒處理一百萬條消息[2]的例子；但是，它是在一個有著 30 個節點集群上做的，并且這些消息負載被優化分散到多個隊列和交換器上。

 

典型的 RabbitMQ 部署包含 3 到 7 個節點的集群，并且這些集群也不需要把負載分散到不同的隊列上。這些典型的集群通常可以預期每秒處理幾萬條消息。

 

獲勝者：盡管這兩個消息平臺都可以處理大規模負載，但是 Kafka 在伸縮方面更優并且能夠獲得比 RabbitMQ 更高的吞吐量，因此這局 Kafka 獲勝。
但是，值得注意的是大部分系統都還沒有達到這些極限！所以，除非你正在構建下一個非常受歡迎的百萬級用戶軟件系統，否則你不需要太關心伸縮性問題，畢竟這兩個消息平臺都可以工作的很好。

消費者復雜度

RabbitMQ 使用的是智能代理和傻瓜式消費者模式。消費者注冊到消費者隊列，然后 RabbitMQ 把傳進來的消息推送給消費者。RabbitMQ 也有拉取（pull）API；不過，一般很少被使用。

 

RabbitMQ 管理消息的分發以及隊列上消息的移除（也可能轉移到 DLX）。消費者不需要考慮這塊。

 

根據 RabbitMQ 結構的設計，當負載增加的時候，一個隊列上的消費者組可以有效的從僅僅一個消費者擴展到多個消費者，并且不需要對系統做任何的改變。

RabbitMQ 高效的伸縮

 

相反，Kafka 使用的是傻瓜式代理和智能消費者模式。消費者組中的消費者需要協調他們之間的主題分區租約（以便一個具體的分區只由消費者組中一個消費者監聽）。
消費者也需要去管理和存儲他們分區偏移索引。幸運的是 Kafka SDK 已經為我們封裝了，所以我們不需要自己管理。

 

另外，當我們有一個低負載時，單個消費者需要處理并且并行的管理多個分區，這在消費者端會消耗更多的資源。

 

當然，隨著負載增加，我們只需要伸縮消費者組使其消費者的數量等于主題中分區的數量。這就需要我們配置 Kafka 增加額外的分區。

 

但是，隨著負載再次降低，我們不能移除我們之前增加的分區，這需要給消費者增加更多的工作量。

 

盡管這樣，但是正如我們上面提到過，Kafka SDK 已經幫我們做了這個額外的工作。

Kafka 分區沒法移除，向下伸縮后消費者會做更多的工作

 

獲勝者：根據設計，RabbitMQ 就是為了傻瓜式消費者而構建的。所以這輪 RabbitMQ 獲勝。

如何選擇？

 

現在我們就如面對百萬美元問題一樣：“什么時候使用 RabbitMQ 以及什么時候使用 Kafka？”概括上面的差異，我們不難得出以下結論：

 

優先選擇 RabbitMQ 的條件：

• 高級靈活的路由規則

• 消息時序控制（控制消息過期或者消息延遲）

• 高級的容錯處理能力，在消費者更有可能處理消息不成功的情景中（瞬時或者持久）

• 更簡單的消費者實現

 

優先選擇 Kafka 的條件：

• 嚴格的消息順序

• 延長消息留存時間，包括過去消息重放的可能

• 傳統解決方案無法滿足的高伸縮能力

 

大部分情況下這兩個消息平臺都可以滿足我們的要求。但是，它取決于我們的架構師，他們會選擇最合適的工具。

 

當做決策的時候，我們需要考慮上面著重強調的功能性差異和非功能性限制。

 

這些限制如下：

• 當前開發者對這兩個消息平臺的了解

• 托管云解決方案的可用性（如果適用）

• 每種解決方案的運營成本

• 適用于我們目標棧的 SDK 的可用性

 

當開發復雜的軟件系統時，我們可能被誘導使用同一個消息平臺去實現所有必須的消息用例。

 

但是，從我的經驗看，通常同時使用這兩個消息平臺能夠帶來更多的好處。
例如，在一個事件驅動的架構系統中，我們可以使用 RabbitMQ 在服務之間發送命令，并且使用 Kafka 實現業務事件通知。

 

原因是事件通知常常用于事件溯源，批量操作（ETL 風格），或者審計目的，因此 Kafka 的消息留存能力就顯得很有價值。

 

相反，命令一般需要在消費者端做額外處理，并且處理可以失敗，所以需要高級的容錯處理能力。

 

這里，RabbitMQ 在功能上有很多閃光點。以后我可能會寫一篇詳細的文章來介紹，但是你必須記住：你的里程（mileage）可能會變化，因為適合性取決于你的特定需求。