本文素材來源於 RabbitMQ Summit 2019 會議上 Erlang Solutions 工程師 Grigory Starinkin 的發言內容。原內容主要對 MQTT 訊息伺服器 EMQ X 與 RabbitMQ 進行了介紹及壓力測試對比。在此基礎上，我們對其進行了補充，深入分析了 EMQ X 以及 RabbitMQ 在核心架構上的側重，並據此分析了它們為 MQTT 叢集模式表現帶來的不同影響。

MQTT 協議 - 訂閱和釋出

MQTT 是一個非常輕量級的訂閱和釋出協議，現在已經是物聯網領域廣泛使用的傳輸協議。

MQTT 協議每個訊息最少僅需 2 個位元組 （其中報頭僅需 1 個位元組，其餘位元組可以全部作為訊息載荷）就可以完成通訊，專為那些資源和空間有限、功耗敏感的硬體所打造。

其主要模式是 Pub/Sub（釋出/訂閱），客戶端可以扮演兩個角色，一個角色是釋出者，其在連線到伺服器之後將針對某個特定主題傳送訊息給伺服器；另一個角色是訂閱者，可以訂閱感興趣的主題來接收其中的訊息。訂閱者也可以使用萬用字元訂閱主題，這樣就可以一次訂閱多個不同的主題，還可以使用共享訂閱進行負載均衡分發。

以下圖片揭示了 MQTT 協議是如何運作的：

目前市場上有很多 MQTT 客戶端 SDK，也有很多 MQTT Broker。EMQ X 和 RabbitMQ 是 Erlang 家族中具有代表性的兩大開源訊息伺服器，我們接下來將針對 MQTT 場景對其進行深入對比。

EMQ X 與 RabbitMQ

EMQ X 是基於高併發的 Erlang/OTP 語言平臺開發，支援百萬級連線、分散式叢集架構、釋出訂閱模式的開源 MQTT 訊息伺服器。開源至今，EMQ X 在全球物聯網市場得到了廣泛應用。在開源版基礎上，還陸續發展了商業版和提供雲版本（cloud-hosting）。EMQ X 支援很多外掛，具有強大拓展能力，使用者依靠外掛可以實現更多的功能。

RabbitMQ 是實現了高階訊息佇列協議（AMQP）的開源訊息代理軟體（亦稱面向訊息的中介軟體）。RabbitMQ 伺服器也是基於 Erlang 語言開發的，現在可以透過外掛配置的形式，使其支援 MQTT 協議。

不難發現，他們都選用了 Erlang 作為開發語言，並且他們都使用了 Erlang 語言攜帶的分散式資料庫管理系統 —— Mnesia。Mnesia 適用於交換路由拓撲和在叢集之內的節點之間交換資訊。

壓力測試

MQTT 伺服器在實際使用中的效能通常被使用者作為判斷一個伺服器好壞的標準，因此本次評測也將重點關注這兩個伺服器在壓力測試下的效能測試結果。

測試工具

本次壓力測試的工具選用了 MZBench。MZBench 是一個使用 Erlang 語言寫的測試工具。它具有以下三個型別的節點：

MZSever：可以用來建立場景（scenarios），例如建立一個釋出者和多個訂閱者。這些資訊會作為伺服器傳送至 MZBench；

MZController：從伺服器產生的資訊會進一步被傳送到這裡；

MZNodes：它們會作為 MQTT 客戶端來連入你的叢集，如下圖所示。

這次評測使用了一個雲主機 M5 large 的例項，每個 MQTT 訊息伺服器叢集由 3 個節點組成，每個節點的配置是雙核，8GB 記憶體。需要強調的是，我們對於 EMQ X 和 RabbitMQ 的測試使用了完全一致的硬體資源以消除變數。所有這些都配備了 Prometheus 節點匯出器用於將指標推送到 Prometheus，並由 Grafana 進行最後的資料收集。

測試場景

壓力測試將會有兩個場景，「多對一」 和 「一對多」。

多對

一

許多裝置作為釋出者，如溫度感測器或者是壓力感測器，傳送資料給一個伺服器。伺服器再將這些資料傳送給一個控制器（即訂閱者）處理這些資料。

一對

多

一個控制器作為釋出者將訊息傳送給伺服器，再由伺服器將這些訊息傳送給多個作為訂閱者的裝置。

在每個場景裡，「多」的那一方的數量將會從 2000 個逐漸上升到 10000 個。每個場景裡，每一秒會發送一條載荷為 256 位元組的訊息。這樣的釋出並不會造成過大的吞吐量。僅僅使用 256 位元組載荷是為了展示出這兩個伺服器的工作原理，以及他們的叢集模式如何對這些場景

做出反應

的。

測試結果

左側 Y 軸是指 CPU 佔用，底部 X 軸是指「多」側的客戶端數量變化。

多對

一

從 「多對一」 的結果可以看出，EMQ X 和 RabbitMQ 相比並沒有太大差別。

一對

多

但是從「一對多」的結果來看，RabbitMQ 相比於 EMQ X 確實有很明顯的差距。

造成這種差距的原因到底是什麼呢？

我們將在下篇內容中為詳細解析具體的原因，敬請關注。