## 摘要

物聯網裝置連線和部署規模的不斷擴大，對物聯網訊息平臺的可擴充套件性和健壯性提出了更高的要求。為了確認雲原生分散式 [MQTT 訊息伺服器 EMQX](https://www.emqx.com/zh/products/emqx) 的效能表現可以充分滿足當今物聯網連線規模的需求，我們在 23 個節點的 EMQX 叢集上建立了 1 億個 MQTT 連線，對 EMQX 的可擴充套件性進行了壓力測試。

在本測試中，每個 MQTT 客戶端訂閱了一個唯一的萬用字元主題，這比直接主題需要更多的 CPU 資源。訊息釋出時，我們選擇了一對一的釋出者-訂閱者拓撲模型，每秒處理訊息可達 100 萬條。此外，我們還比較了在使用兩個不同的資料庫後端——RLOG DB 和 Mnesia 時，最大訂閱率如何隨著叢集大小的增加而變化。本文將詳細介紹測試情況以及在此過程中面臨的一些挑戰。

## 背景介紹

[EMQX](https://github.com/emqx/emqx/) 是一個高度可擴充套件的分散式開源 MQTT 訊息伺服器，基於 Erlang/OTP 平臺開發，可支援數百萬併發客戶端。因此，EMQX 需要在叢集節點之間持久化和複製各種資料，如 MQTT 主題及其訂閱者、路由資訊、ACL 規則、各種配置等等。為滿足此類需求，從釋出起，EMQX 就一直採用 Mnesia 作為資料庫後端。

Mnesia 是基於 Erlang/OTP 的嵌入式 ACID 分散式資料庫，使用全網狀點對點 Erlang 分發來進行事務協調和複製。這一特性使其在水平擴充套件方面存在困難：節點越多，複製的資料就越多，寫入任務協調的開銷就越大，出現腦裂場景的風險也越大。

在 EMQX 5.0 中，我們嘗試透過一個新的資料庫後端型別——RLOG（Replication Log）來緩解此問題，其採用 [Mria](https://github.com/emqx/mria) 實現。作為 Mnesia 資料庫的擴充套件，Mria 定義了兩種型別的節點來幫助其進行水平擴充套件：一種是核心節點，其行為與普通的 Mnesia 節點一樣，參與寫入事務；另一種是複製節點，不參與事務處理，將事務處理委託給核心節點，同時在本地保留資料的只讀副本。因為參與其中的節點較少，這使得腦裂風險大大降低，並且減少了事務處理所需的協調。同時，由於所有節點都可以本地讀取資料，可以實現只讀資料的快速訪問。

為了能夠預設使用這個新的資料庫後端，我們需要對其進行壓力測試，驗證其確實能夠很好地進行水平擴充套件。我們建立了一個 23 節點的 EMQX 叢集，保持 1 億個併發連線，在釋出者和訂閱者之間平分，並以一對一的方式釋出訊息。此外，我們還將 RLOG DB 後端與傳統的 Mnesia 後端進行了比較，並確認了 RLOG 的到達率的確比 Mnesia 更高。

## 測試方法

我們使用了 [AWS CDK](https://aws.amazon.com/cdk/) 來進行叢集測試的部署和執行，其可以測試不同型別和數量的例項，還可以嘗試使用 EMQX 的不同開發分支。感興趣的讀者可以在這個 [Github 倉庫](https://github.com/emqx/cdk-emqx-cluster)中檢視我們的指令碼。我們在負載生成器節點（簡稱“loadgens”）中使用了我們的 [emqtt-bench](https://github.com/emqx/emqtt-bench/) 工具生成具有各種選項的連線/釋出/訂閱流量，並使用 EMQX 的 Dashboard 和 [Prometheus](https://prometheus.io/) 來監控測試的進度和例項的健康狀況。

我們用不同例項型別和數量進行了逐一測試。在最後幾次測試中，我們決定對 EMQX 節點和 loadgen 使用 c6g.metal 例項，對叢集使用”3+20”拓撲，即 3 個參與寫入事務的核心節點，以及 20 個為只讀副本並將寫入委託給核心節點的複製節點。至於 loadgen，我們觀察到釋出者客戶端需要的資源要遠多於訂閱者。如果僅連線和訂閱 1 億個連線，只需要 13 個 loadgen 例項；如果還需要進行釋出，則需要 17 個。

[![測試架構](http://img.blog.itpub.net/blog/2022/06/20/505c117f755798e4.png?x-oss-process=style/bb "測試架構")](https://www.emqx.com/zh/blog/reaching-100m-mqtt-connections-with-emqx-5-0 "測試架構")

在這些測試中未使用任何負載均衡器，loadgen 直接連線到每個節點。為了讓核心節點專門用於管理資料庫事務，我們沒有建立到這些核心節點的連線，每個 loadgen 客戶端都以均勻分佈的方式直接連線到每個節點，因此所有節點的連線數和資源使用情況大致相同。每個訂閱者都訂閱了 QoS 為 1 的 bench/%i/# 形式的萬用字元主題，其中 %i 代表每個訂閱者的唯一編號。每個釋出者都以 QoS 1 釋出了 bench/%i/test 形式的主題，其中 %i 與訂閱者的 %i 相同。這確保了每個釋出者都只有一個訂閱者。訊息中的有效負載大小始終為 256 位元組。

在測試中，我們首先連線了所有訂閱者客戶端，然後才開始連線釋出者。只有在所有釋出者都連線後，它們才開始每 90 秒進行一次訊息釋出。在本文報告的 1 億連線測試中，訂閱者和釋出者連線到 broker 的速率為 16000 連線/秒，不過我們相信叢集可以保持更高的連線速率。

## 測試中遇到的挑戰

在對如此量級的連線和吞吐量進行試驗的過程中，我們遇到了一些挑戰並據此進行了相關調查，使效能瓶頸得到了改善。system_monitor 為我們跟蹤 Erlang 程式中的記憶體和 CPU 使用情況提供了很大幫助，它可以稱得上是“BEAM 程式的 htop”，讓我們能夠找到具有長訊息佇列、高記憶體和/或 CPU 使用率的程式。在叢集測試期間觀察到情況之後，我們利用它在 Mria 中進行了一些效能調優[1] [2] [3]。

在使用 Mria 進行的初始測試中，簡單地說，複製機制基本上是要將所有事務記錄到由複製節點訂閱的一個隱藏的表中。這實際上在核心節點之間產生了一些網路開銷，因為每個事務本質上都是“複製的”。在我們 fork 的 Erlang/OTP 程式碼中，我們新增了一個新的 Mnesia 模組，使我們能夠更輕鬆地捕獲所有提交的事務日誌，不需要“複製”寫入，大大減少了網路使用，讓叢集保持更高的連線和事務處理速率。在進行了這些最佳化後，我們進一步對叢集進行了壓力測試，並發現了新的瓶頸，需要進一步的效能調優[4] [5] [6]。

即使是我們的招牌測試工具也需要進行一些調整才能處理如此大量的連線和連線速率。為此我們進行了一些質量改進[7] [8] [9] [10]和效能最佳化[11] [12]。在我們的釋出-訂閱測試中，甚至專門建立了一個分支（不在當前的主幹分支中），以便進一步降低記憶體的使用。

## 測試結果

[![1 億 MQTT 連線測試結果](http://img.blog.itpub.net/blog/2022/06/20/e6dc2786fccff872.png?x-oss-process=style/bb "1 億 MQTT 連線測試結果")](https://www.emqx.com/zh/blog/reaching-100m-mqtt-connections-with-emqx-5-0 "1 億 MQTT 連線測試結果")

上圖展示了一對一發布-訂閱測試的最終結果。我們建立了 1 億個連線，其中 5000 萬是訂閱者，另外 5000 萬是釋出者。透過每 90 秒釋出一次訊息，我們可以看到平均入站和出站速率達到了每秒 100 萬條以上。在釋出高峰期，20 個複製節點（這些節點是連線的節點）中的每一個節點在釋出過程中平均用到90% 的記憶體（約 113GiB）和約 97% 的 CPU（64 個 arm64 核心）。處理事務的 3 個核心節點使用 CPU 較少（使用率不到 1%），並且只使用了 28% 的記憶體（約 36GiB）。256 位元組有效負載的釋出過程中需要的網路流量在 240MB/s 到 290 MB/s 之間。在釋出高峰期，loadgen 需要幾乎全部記憶體（約 120GiB）和整個 CPU。

> 注意：在這個測試中，所有配對的釋出者和訂閱者碰巧都在同一個 broker 中，這並不是一個十分接近現實用例的理想場景。目前 EMQX 團隊正在進行更多的測試，並將持續更新進展。

[![Grafana MQTT](http://img.blog.itpub.net/blog/2022/06/20/6f9ab1ef460e3ac4.png?x-oss-process=style/bb "Grafana MQTT")](https://www.emqx.com/zh/blog/reaching-100m-mqtt-connections-with-emqx-5-0 "Grafana MQTT")

為了將 RLOG 叢集與等效的 Mnesia 叢集進行比較，我們使用了另一種總連線數較少的拓撲：RLOG 使用 3 個核心節點+7 個複製節點，Mnesia 叢集使用 10 個節點，其中 7 個節點進入連線。我們以不同速率進行連線和訂閱，不進行釋出。

下圖展示了我們的測試結果。對於 Mnesia，連線和訂閱節點的速度越快，觀察到的“扁平化”行為就越多，即叢集無法達到目標最大連線數，在這些測試中，目標最大連線數為 5000 萬。而對於 RLOG，我們可以看到它能夠達到更高的連線速率，而叢集不會表現出這種扁平化行為。由此我們可以得出結論，使用 RLOG 的 Mria 在連線速率較高的情況下比我們過去採用的 Mnesia 後端效能表現更好。

[![Mnesia VS RLOG](http://img.blog.itpub.net/blog/2022/06/20/437f20b3b19db1fa.png?x-oss-process=style/bb "Mnesia VS RLOG")](https://www.emqx.com/zh/blog/reaching-100m-mqtt-connections-with-emqx-5-0 "Mnesia VS RLOG")

## 結語

經過一系列測試並獲得這些令人滿意的結果之後，我們認為 Mria 提供的 RLOG 資料庫後端可在 EMQX 5.0 中投入使用。它已經成為當前主分支中的預設資料庫後端。

## References

[1] - [fix(performance): Move message queues to off_heap by k32 · Pull Request #43 · emqx/mria](https://github.com/emqx/mria/pull/43)

[2] - [perf(replicant): Improve performance of the agent and the replicant by k32 · Pull Request #44 · emqx/mria](https://github.com/emqx/mria/pull/44)

[3] - [fix(mria_status): Remove mria_status process by k32 · Pull Request #48 · emqx/mria](https://github.com/emqx/mria/pull/48)

[4] - [Store transactions in replayq in normal mode by k32 · Pull Request #65 · emqx/mria](https://github.com/emqx/mria/pull/65)

[5] - [feat: Remove redundand data from the mnesia ops by k32 · Pull Request #67 · emqx/mria](https://github.com/emqx/mria/pull/67)

[6] - [feat: Batch transaction imports by k32 · Pull Request #70 · emqx/mria](https://github.com/emqx/mria/pull/70)

[7] - [feat: add new waiting options for publishing by thalesmg · Pull Request #160 · emqx/emqtt-bench](https://github.com/emqx/emqtt-bench/pull/160)

[8] - [feat: add option to retry connections by thalesmg · Pull Request #161 · emqx/emqtt-bench](https://github.com/emqx/emqtt-bench/pull/161)

[9] - [Add support for rate control for 1000+ conns/s by qzhuyan · Pull Request #167 · emqx/emqtt-bench](https://github.com/emqx/emqtt-bench/pull/167)

[10] - [support multi target hosts by qzhuyan · Pull Request #168 · emqx/emqtt-bench](https://github.com/emqx/emqtt-bench/pull/168)

[11] - [feat: bump max procs to 16M by qzhuyan · Pull Request #138 · emqx/emqtt-bench](https://github.com/emqx/emqtt-bench/pull/138)

[12] - [feat: tune gc for publishing by thalesmg · Pull Request #164 · emqx/emqtt-bench](https://github.com/emqx/emqtt-bench/pull/164)

> 版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
> 原文連結：[https://www.emqx.com/zh/blog/reaching-100m-mqtt-connections-with-emqx-5-0](https://www.emqx.com/zh/blog/reaching-100m-mqtt-connections-with-emqx-5-0)

高度可擴充套件，EMQX 5.0 達成 1 億 MQTT 連線

相關文章