## 引言： 單叢集 1 億 MQTT 連線達成

不久前，大規模分散式物聯網 MQTT 訊息伺服器 [EMQX 釋出了 5.0 版本](https://www.emqx.com/zh/blog/emqx-v-5-0-released)。這一最新的里程碑版本採用新的後端儲存架構 Mria 資料庫，並重構了資料複製邏輯，因此 EMQX 5.0 水平擴充套件能力得到了指數級提升，能夠更可靠地承載更大規模的物聯網裝置連線量。

在 EMQX 5.0 正式釋出前的效能測試中，我們透過一個 23 節點的 EMQX 叢集，全球首個達成了 1 億 MQTT 連線+每秒 100 萬訊息吞吐，這也使得 EMQX 5.0 成為目前為止全球最具擴充套件性的 MQTT Broker。

本文將對使 EMQX 水平擴充套件能力得到指數級提升的全新底層架構進行詳細解析，幫助大家理解 EMQX 5.0 叢集擴充套件的技術原理，以及在不同的實際應用場景中如何選擇合適的部署架構，實現更加可靠的裝置接入與訊息傳輸。

[![100 millions MQTT connections testing result](http://img.blog.itpub.net/blog/2022/07/21/9ceb30139de4ff85.png?x-oss-process=style/bb "100 millions MQTT connections testing result")](https://www.emqx.com/zh/blog/how-emqx-5-0-achieves-100-million-mqtt-connections "100 millions MQTT connections testing result")

> 測試詳情可參考：https://www.emqx.com/zh/blog/reaching-100m-mqtt-connections-with-emqx-5-0

## 4.x 時代：使用 Mnesia 構建 EMQX 叢集

### Mnesia 介紹

EMQX 4.x 版本儲存採用的是 Erlang/OTP 自帶的分散式資料庫 [Mnesia](https://www.erlang.org/doc/man/mnesia.html) ，它具備以下優點：

- **Embedded：** 和 MySQL、PostgeresSQL 等資料庫不同，Mnesia 和 EMQX 是執行在同一個作業系統程式的（類似於 SQLite）。因此 EMQX 可以以非常快的速度讀取路由、會話等相關資訊。
- **Transactional：** Mnesia 支援事務且具有 ACID 保證。而且這些保證是針對整個叢集所有節點生效的。EMQX 在資料一致性很重要的地方使用 Mnesia 事務，例如更新路由表、建立規則引擎規則等。
- **Distributed：** Mnesia 表會複製到所有 EMQX 節點。這能提高 EMQX 的分散式的容錯能力，只要保證一個節點存活資料就是安全的。
- **NoSQL：** 傳統的關係型資料庫使用SQL與資料庫進行互動。而 Mnesia 直接使用 Erlang 表示式和內建的資料型別進行讀寫，這使得與業務邏輯的整合非常順利，並消除了資料編解碼的開銷。

在 Mnesia 叢集中，所有節點都是平等的。它們中的每一個節點都可以儲存一份資料副本，也可以啟動事務或執行讀寫操作。

Mnesia 叢集使用全網狀拓撲結構：即每個節點都會與叢集中其它所有的節點建立連線，每個事務都被會複製到叢集中的所有節點。如下圖所示：

[![Mnesia 網狀拓撲](http://img.blog.itpub.net/blog/2022/07/21/9550bc4301c01024.png?x-oss-process=style/bb "Mnesia 網狀拓撲")](https://www.emqx.com/zh/blog/how-emqx-5-0-achieves-100-million-mqtt-connections "Mnesia 網狀拓撲")

### Mnesia 的問題

正如我們上面所討論的，Mnesia 資料庫有很多非常顯著的優點，EMQX 也從中獲得了非常大的收益。但其全連線的特性，**限制了其叢集的水平擴充套件能力，因為節點之間的連結數量隨著節點數量的平方而增長，保持所有節點完全同步的成本越來越高，事務執行的效能也會急劇下降**。

這意味著 EMQX 的叢集功能有以下限制:

- **水平擴充套件能力不足。** 在 4.x 我們不建議在叢集節點過多，因為網狀拓撲中的事務複製的開銷會越來越大；我們一般建議是使用節點數保持在 3 ~ 7 個，並儘量提供單節點的效能。
- **節點數增多會增大叢集腦裂的可能性**。節點數越多、節點間的連結數也會急劇增多，對節點間的網路穩定性的要求更高。當產生腦裂後，節點自愈會導致節點重啟並有資料丟失的風險。

儘管如此，EMQX 憑藉獨特的架構設計和 Erlang/OTP 強大的功能特性，實現了單個叢集 1000 萬 MQTT 連線的目標。同時，EMQX 能夠以叢集橋接的方式，透過多個叢集承載更大規模的物聯網應用。但隨著市場的發展，單個物聯網應用需要承載越來越多的裝置和使用者，EMQX 需要具備更強大的擴充套件性和接入能力，以支援超大規模物聯網應用。

## 5.x 時代：使用 Mria 構建大規模叢集

[Mria](https://github.com/emqx/mria) 是 Mnesia 的一個開源擴充套件，為叢集增加了最終的一致性。前文所述的大多數特性仍然適用於它，區別在於資料如何在節點間進行復制。 Mria 從**全網狀**拓撲結構轉向**網狀+星型狀**拓撲結構。每個節點承擔兩個角色中的一個：**核心節點（Core）**或**複製者節點（Replicant）**。

[![Mria 核心-複製節點拓撲](http://img.blog.itpub.net/blog/2022/07/21/18a550549fa5dedf.png?x-oss-process=style/bb "Mria 核心-複製節點拓撲")](https://www.emqx.com/zh/blog/how-emqx-5-0-achieves-100-million-mqtt-connections "Mria 核心-複製節點拓撲")

### Core 和 Replicant 節點行為

**Core 節點**的行為與 4.x 中的 Mnesia 節點一致：Core 節點使用全連線的方式組成叢集，每個節點都可以發起事務、持有鎖等。因此，EMQX 5.0 仍然要求 Core 節點在部署上要儘量的可靠。

**Replicant 節點**不再直接參與事務的處理。但它們會連線到 Core 節點，並被動地複製來自 Core 節點的資料更新。Replicant 節點不允許執行任何的寫操作。而是將其轉交給 Core 節點代為執行。另外，由於 Replicant 會複製來自 Core 節點的資料，所以它們有一份完整的本地資料副本，以達到最高的讀操作的效率，這樣有助於降低 EMQX 路由的時延。

我們可以將這種資料複製模型當做**無主複製和主從複製**的一種混合。這種叢集拓撲結構解決了兩個問題：

- 水平可擴充套件性（如前文提到，我們已經測試了有 23 個節點的 EMQX 叢集）
- 更容易的叢集自動擴充套件，並無資料丟失的風險。

由於 Replicant 節點不參與寫操作，當更多的 Replicant 節點加入叢集時，寫操作的延遲不會受到影響。這允許建立更大的 EMQX 叢集。

另外，Replicant 節點被設計成是無狀態的。新增或刪除它們不會導致叢集資料的丟失、也不會影響其他節點的服務狀態，所以 Replicant 節點可以被放在一個自動擴充套件組中，從而實現更好的 DevOps 實踐。

出於效能方面的考慮，不相干資料的複製可以被分成獨立的資料流，即多個相關的資料表可以被分配到同一個 RLOG Shard（複製日誌分片），順序地把事務從 Core 節點複製到 Replicant 節點。但不同的 RLOG Shard 之間是非同步的。

## EMQX 5.0 叢集部署實踐

### 叢集架構選擇

在 EMQX 5.0 中，所以如果不做任何調整的話所有節點都預設為 Core 節點，預設行為和 4.x 版本是一致的。

可以透過設定 `emqx.conf` 中的 `node.db_role` 引數或 `EMQX_NODE__DB_ROLE` 環境變數，把節點上設定為 Replicant 節點。

> 請注意，叢集中至少要有一個核心節點，我們建議以 3 個 Core + N 個 Replicant 的設定作為開始

Core 節點可以接受 MQTT 的業務流量，也可以純粹作為叢集的資料庫來使用。我們建議：

- 在小叢集中（3 個節點或更少），沒有必要使用 Core + Replicant 複製模式，可以讓 Core 節點承擔所有的流量，避免增加上手和使用的難度。
- 在超大的叢集中（10 個節點或更多），建議把 MQTT 流量從 Core 節點移走，這樣更加穩定性和水平擴充套件性更好。
- 在中型叢集中，取決於許多因素，需要根據使用者實際的場景測試才能知道哪個更優。

**異常處理**

Core 節點對於 Replicant 節點是無感的，當某一 Core 節點當機時，Replicant 節點會自動連線到新的 Core 節點，此過程中客戶端不會掉線，但可能導致路由更新延遲；當 Replicant 節點當機時，所有連線到該節點的客戶端會被斷開，但由於 Replicant 是無狀態的，所以不會影響到其他節點的穩定性，此時客戶端需要設定重連機制，連線至另一個 Replicant 節點。

### 硬體配置要求

**網路**

Core 節點之間的網路延遲建議 10ms 以下，實測高於 100ms 將不可用，請將 Core 節點部署在同一個私有網路下；Replicant 與 Core 節點之間同樣建議部署在同一個私有網路下，但網路質量要求可以比 Core 節點間略低。

**CPU 與記憶體**

Core 節點需要較大的記憶體，在不承接連線的情況下，CPU 消耗較低；Replicant 節點硬體配置與 4.x 一致，可按連線和吞吐配置估算其記憶體要求。

### 監控和除錯

對 Mria 的效能監控可以使用 Prometheus 或使用 EMQX 控制檯檢視。 Replicant 節點在啟動過程中會經歷以下狀態：

- **bootstrap**：當 Replicant 節點啟動後，需要從 Core 節點同步最新資料表的過程
- **local_replay**：當節點完成 bootstrap 時，它必須重放這個過程中產生的的寫事務
- **normal**：當快取的事務被完全執行後，節點即進入到正常執行的狀態。後續的寫事務被實時地應用到當前節點。大多數情況下，Replicant 節點都會保持在這個狀態。

#### Prometheus 監控

**Core 節點**

- `emqx_mria_last_intercepted_trans`: 自節點啟動以來，分片區收到的交易數量。請注意，這個值在不同的核心節點上可能是不同的。
- `emqx_mria_weight`: 一個用於負載平衡的值。它的變化取決於核心節點的瞬間負載。
- `emqx_mria_replicants`：連線到核心節點的複製器的數量，為給定的分片複製資料。
- `emqx_mria_server_mql`: 未處理的交易數量，等待傳送至複製者。越少越好。如果這個指標有增長的趨勢，需要更多的核心節點。

**Replicant 節點**

- `emqx_mria_lag`：複製體滯後，表示複製體滯後上游核心節點的程度。越少越好。
- `emqx_mria_bootstrap_time`：複製體啟動過程中花費的時間。這個值在複製體的正常執行過程中不會改變。
- `emqx_mria_bootstrap_num_keys`：在引導期間從核心節點複製的資料庫記錄的數量。這個值在複製體的正常執行中不會改變。
- `emqx_mria_message_queue_len`：複製程式的訊息佇列長度。應該一直保持在0左右。
- `emqx_mria_replayq_len`: 複製體的內部重放佇列的長度。越少越好。

#### 控制檯命令

`./bin/emqx eval mria_rlog:status().` 可以獲取關於 Mria 資料庫執行狀態的更多資訊。

> 注：它可以顯示一些 shard 為 `down` 狀態，這表明這些分片沒有被任何業務應用使用。

## 結語

全新的底層架構使 EMQX 5.0 具備了更強的水平擴充套件能力，在構建滿足使用者業務需求的更大規模叢集的同時，可以降低大規模部署下的腦裂風險以及腦裂後的影響，有效減少叢集維護開銷，為使用者提供更加穩定可靠的物聯網資料接入服務。

> **參考資料：**
>
> - [Challenges and Solutions of EMQX horizontal scalability - MQTT broker clustering part 3](https://www.emqx.com/en/blog/mqtt-broker-clustering-part-3-challenges-and-solutions-of-emqx-horizontal-scalability)
> - [高度可擴充套件，EMQX 5.0 達成 1 億 MQTT 連線](https://www.emqx.com/zh/blog/reaching-100m-mqtt-connections-with-emqx-5-0)

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

Mria + RLOG 新架構下的 EMQX 5.0 如何實現 1 億 MQTT 連線

相關文章