在[上篇文章](https://www.emqx.com/zh/blog/emqx-or-rabbitmq-part-1)中，我們採用相同的硬體資源分別對 [MQTT 訊息伺服器 EMQ X](https://www.emqx.io/zh) 和 [RabbitMQ](https://www.rabbitmq.com) 進行了壓力測試。結果表明：在「多對一」 場景中，EMQ X 和 RabbitMQ 相比並沒有太大差別；而在「一對多」場景中，RabbitMQ 則較 EMQ X 產生了較為明顯的差距。

本期文章中我們將對這一結果進行進一步的解析。

造成差距的原因主要有三個：節點間通訊的方式、訊息流架構的方式、佇列的使用。

## 節點間的通訊

### RabbitMQ - 委託架構

RabbitMQ 使用了 Erlang 語言的分散式連線，即每個節點之間兩兩互相連線，每個節點用一個單一的連結連線著另一個節點。在圖中的情況下，三個節點依次連線；當節點之間需要通訊時，一條訊息需要透過這個單一連結從一個節點傳送到另一節點。

![RabbitMQ連線.png](https://static.emqx.net/images/77d2292e39b54f54985bcba287647754.png)

在扇出（fan-out）的例子中，正常來講你需要將訊息推送到所有節點的佇列上。RabbitMQ 使用的最佳化方式則是：你的訊息只需要傳送一次，之後其內建的代理委託框架會將這一條訊息派送並且發到其他節點的佇列上。這個過程中，訊息是有序傳送的，所以保證了訊息在不同佇列裡都是相同的順序。

![RabbitMQdelegate1.png](https://static.emqx.net/images/6b7b0e22e32e14c876164a894f9f3505.png)

但是這個方案也不是十全十美的，因為你會將所有的訊息只傳送一次，在分發工作都依靠同一個委託程式。而且 RabbitMQ 選擇這個代理程式的策略是根據釋出者的雜湊演算法。所以，當如果你只有一個釋出者，所有的訊息都會被一直推送到單個的委託代理程式。

![RabbitMQdelegate2.png](https://static.emqx.net/images/3701be881446123170efa08751cd5c2f.png)

### EMQ X - Gen_RPC

在 EMQ X 中有個精妙的設計：其不僅存在著分散式連線，還存在著 Gen_RPC。分佈連線和 Gen_RPC 各司其職，前者用於交換 Mnesia 的資料資訊，後者則只適用於訊息的轉發。每當你需要從一個節點向另一個節點釋出一個訊息的時候，EMQ X 不是重新自動生成新的節點間連結（預設 1 個連線），再透過這些新的連線去處理把一個訊息從一個節點推送到另一個節點的工作。而是依靠針對此場景特地設計的，專有的 Gen_RPC 連線來處理這個訊息推送的工作。所以在扇出（一對多）的例子中，這些連結會被完全有效地利用。

![EMQx連線.png](https://static.emqx.net/images/85793cea9e516f5981fba9299240fe6f.png)
![EMQxgen_rpc.png](https://static.emqx.net/images/fee9e2f293c7e5b5ca7fc585ccc433dd.png)

但這種設計在網路分割槽環境中其效能有可能受到影響，RabbitMQ 節點之間只有一個分散式連線，所以當連線斷開造成腦裂時，癒合修復的工作將會更簡單。

## 訊息流

### MQTT 外掛

RabbitMQ 在使用 MQTT 外掛後會監聽使用 [MQTT 協議](https://www.emqx.com/zh/mqtt)釋出的訊息。得到訊息之後，訊息被解析，之後再透過 AMQP 協議進行轉化，最後才會被髮送到 RabbitMQ 上。

![MQTT外掛.png](https://static.emqx.net/images/1197c10dd374beb30c9c14d8631801b6.png)

如果要傳送一條訊息，需要經過套接字後進入 mqtt_reader，接下來再進入下圖所示的所有過程。然而如果要在同一條通道里同時接收剛剛傳送的這條訊息，所有上圖所示的過程則需要反著重新進行一次，包括 mqtt_reader。其中，mqtt_reader 不僅負責了讀，也負責了寫。

![RabbitMQ流量控制.png](https://static.emqx.net/images/f911ce3b56e625fefaf3dcaa9862eaf3.png)

### AMQP

AMQP 場景則不同，每條訊息都被一個 reader 讀取，一個 writer 寫入。這兩條通道讀寫獨立，reader 只負責讀內容，而 writer 只負責寫內容，它們各司其職、相互獨立。而唯一的通道 channel 則是一個主 Erlang 程式，其負責著訊息的交換。

![AMQP.png](https://static.emqx.net/images/17717215892fdfd1f1b7a5b47b327d9b.png)

可見 RabbitMQ 在 MQTT 場景中存在的明顯的設計問題會導致效能下降，那麼如果引入 AMQP 模式的 RabbitMQ 測試用例將會如何呢？將 RabbitMQ 調製成使用 MQTT 外掛的和使用單一 AMQP 的模式使用，再對比 EMQ X 在壓力測試下的情況，可以看出 EMQ X 在所有測試中仍是更勝一籌，但總體來說使用 AMQP 模式的 RabbitMQ 要比自己原有的成績更好。

#### 多對一

![多對一測試結果.png](https://static.emqx.net/images/4ffa40292efbbe92616e2c78d88547c6.png)

此場景中 RabbitMQ 與 EMQ X 已經有了接近的效能表現。

#### 一對多

![一對多測試結果.png](https://static.emqx.net/images/2e39662f8ccb2cc9dab490197e0a2e22.png)

但如果在 fan-out（一對多)場景裡，EMQ X 仍然具有顯著優勢，但 RabbitMQ（AMQP）的差距已經明顯縮小。

## 佇列

以上的測試均使用了 QoS 1 的訊息。當傳送 QoS 1 的訊息時，這些訊息每次都要作為可持久化的備份儲存在硬碟上。所以佇列空間的使用也尤為重要。

### RabbitMQ

RabbitMQ 成熟地使用了一個預設的佇列空間執行方式（可以被替換成其他佇列使用）。這個可變佇列在訊息的持久度和給客戶端傳送訊息的時延裡做了均衡。但是在最壞的情況下，一個訊息可能會被存入記憶體。不過這也幫助了 RabbitMQ 在崩潰重啟之後可以讓伺服器再上線，並且所有的客戶端還可重連且收到原來持久化的訊息。

![RabbitMQQueue.png](https://static.emqx.net/images/66284df763ff39f0b5fe45b52ba823e2.png)

### EMQ X

EMQ X 對佇列的實現方式非常簡單，即在記憶體中使用了優先佇列。如果發來的訊息無法推入接收者的佇列，則這個訊息會被丟掉。在 EMQ X 中，只有用一些其他持久化的外掛才能使訊息持久化儲存，這些功能在商業版中提供。

![EMQxQueue.png](https://static.emqx.net/images/7eda1f96d217ecf4119212cf6bbdea44.png)

EMQ X 的設計初衷是將接入層獨立，所以將訊息持久化的問題留給了後端完成。這一問題在未來具有永續性會話的版本中會解決（persistence session）。

## 節流

### RabbitMQ - 控流

RabbitMQ 採用了一種比較有名的控流機制，它給每一個流程了一個信用值，如下圖所示。假設說我們的服務端接收到了一個訊息並由 reader 進行了讀取後，這條訊息被送到 channel。這個過程將會消費掉 reader 和 channel 的相應的信用值。這樣一來，就可以透過使兩方信用值保持匹配同步的方法實現不超額的傳送了。

![RabbitMQ流量控制.png](https://static.emqx.net/images/372175d7554a2961d4c7d6b6dd1795ef.png)

這其實是一個不錯的解決方案。設想我們有許多的使用者，即有許多的佇列，每傳送一條訊息就意味著將要將這條訊息分發給許多的佇列，這會嚴重影響 RabbitMQ 例項。然而，這一套流程會阻止 RabbitMQ 再繼續讀區接收緩衝區的訊息——因為傳送緩衝區已經快滿了！

### EMQ X - 限流

![EMQxRateLimit.png](https://static.emqx.net/images/cca55a9d048c822eff3cd9c248990b20.png)

EMQ X 的節流主要是靠限制讀取一方的流量去實現的。首先，根據預設，將會一次從套接字內讀取 200 條訊息。當這些訊息被完全收到了之後才會逐個將他們處理。一旦套接字報告它已經到達了讀取一方的最大限額，它將會檢查有釋出者的數量和已經被閱讀的位元組數量，並根據這個數值去休眠一段時間。接收緩衝區最終會被填滿，釋出者根據 TCP 協議中飛行視窗的要求也將不會再發布任何內容。

## 總結

以上就是這個橫向評測的結果和分析。最終的贏家很難斷言，但是如果就伺服器的效能上來講，EMQ X 肯定是略勝一籌的。不過 RabbitMQ 也有它獨特的優勢。

### EMQ X 的設計原則

EMQ X 在設計上，首先分離了前端協議 (FrontEnd) 與後端整合 (Backend)，其次分離了訊息路由平面 (Flow Plane) 與監控管理平面 (Monitor/Control Plane)：

![EMQ X 的設計原則.png](https://static.emqx.net/images/81898acde206deb5c88bc237bcac7c7a.png)

1. EMQ X 核心解決的問題：處理海量的併發 MQTT 連線與路由訊息。
2. 充分利用 Erlang/OTP 平臺軟實時、低延時、高併發、分佈容錯的優勢。
3. 連線 (Connection)、會話 (Session)、路由 (Router)、叢集 (Cluster) 分層。
4. 訊息路由平面 (Flow Plane) 與控制管理平面 (Control Plane) 分離。
5. 支援後端資料庫或 NoSQL 實現資料持久化、容災備份與應用整合。

### EMQ X 的系統分層

1. 連線層 (Connection Layer)：負責 TCP 連線處理、 MQTT 協議編解碼。
2. 會話層 (Session Layer)：處理 MQTT 協議釋出訂閱訊息互動流程。
3. 路由層 (Route Layer)：節點內路由派發 MQTT 訊息。
4. 分佈層 (Distributed Layer)：分佈節點間路由 MQTT 訊息。
5. 認證與訪問控制 (ACL)：連線層支援可擴充套件的認證與訪問控制模組。
6. 鉤子 (Hooks) 與外掛 (Plugins)：系統每層提供可擴充套件的鉤子，支援外掛方式擴充套件伺服器。

而 RabbitMQ 則更類似於 Kafka 的訊息佇列快取設計。建議在 IoT 專案中將兩者結合使用。

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/emqx-or-rabbitmq-part-2](https://www.emqx.com/zh/blog/emqx-or-rabbitmq-part-2)
>
>技術支援：如對本文或 EMQ 相關產品有疑問，可訪問 EMQ 問答社群 [https://askemq.com](https://askemq.com) 提問，我們將會及時回覆支援。
>
>更多技術乾貨，歡迎關注我們公眾號【EMQ 中文社群】。

EMQ X 與 RabbitMQ 訊息伺服器 MQTT 效能對比（下）

相關文章