在這篇文章中，我們將介紹 MQTT Broker 叢集在可擴充套件性方面的一些改進。 我們將主要關注 EMQ X 內部使用的資料庫引擎，以及它在 EMQ X 5.0 版本中是如何改進的。

在開始本文之前，我們需要了解 EMQ X 叢集中是資料是如何複製的：[EMQ X broker](https://www.emqx.io/zh) 將主題和客戶端的執行時資訊儲存在 [Mnesia](http://erlang.org/doc/man/mnesia.html) 資料庫中，有助於跨叢集複製資料。

## Mnesia 簡介

Mnesia 是一個開源資料庫管理系統，由愛立信公司開發作為[開放電信平臺（ Open Telecom Platform ）](https://en.wikipedia.org/wiki/Open_Telecom_Platform)的一部分，最初是用來處理 ISP 級電信交換機中的配置和執行時資料。EMQ X 4.3 之前的版本使用其來儲存各種執行時資料，例如主題、路由、ACL 規則、告警等等。

MySQL、Postgres、MongoDB 等資料庫以及 Redis 和 memcached 等記憶體儲存大家應該都非常熟悉，對 Mnesia 則可能不甚瞭解。但它確實有其獨特的優勢，可將上述產品的許多功能整合到一個簡潔的應用程式中。

Mnesia 有一個相當學術的定義：一個嵌入式、分散式、事務型的 noSQL（非關係型）資料庫。聽起來有些複雜，我們接下來將逐一為大家解釋。

### 嵌入式

MySQL 和 Postgres 等最廣泛使用的資料庫普遍採用客戶端—伺服器模式：資料庫在單獨的程式中執行（通常在專用伺服器上），業務應用程式透過網路或 UNIX 域套接字傳送請求並等待答覆，透過這種方式來與資料庫互動。這種模式在很多方面都很方便，因為它允許將業務邏輯與儲存分開並單獨管理。 但同時也有一些缺點：與遠端程式互動不可避免地會增加每個請求的延遲。

相反，嵌入式資料庫與業務應用程式則在相同的程式中執行。sqlite 是一個典型的嵌入式資料庫的例子。Mnesia 也屬於這一類：它與其他 EMQ X 應用程式在同一程式中執行。 從 Mnesia 表中讀取資料可以像讀取區域性變數一樣快，因此我們可以在熱點中讀取資料庫資料而不會影響效能。

### 分散式

我們之前提到過 Mnesia 是一個分散式資料庫，這意味著資料表被網路複製到不同的物理位置。對於分散式資料庫，如果節點之間不共享任何物理資源（如 RAM 或磁碟），而是在應用程式級別進行協調，這種型別稱為無共享架構 (SN)。 這種型別通常是首選，因為它不需要任何專門的硬體，並且可以水平擴充套件。

Mnesia 應用程式與 EMQ X 一起執行，有助於透過 Erlang 分發協議跨叢集中的所有節點複製表更新。 這意味著業務應用程式可以在本地讀取更新的資料。它還有助於提升容錯效能：只要叢集中有一個節點處於活動狀態，資料就是安全的。EMQ X 依靠此功能實現跨叢集複製路由資訊。

### 事務型

Mnesia 支援 [ACID](https://en.wikipedia.org/wiki/ACID) 事務，這是嵌入式資料庫的一個非常獨特的功能。這意味著可以將多個讀取和更新操作組合在一起。一個 Mnesia 事務具有原子性（必須完整或無任何效力）、一致性（儘管保證比 Postgres 更寬鬆）、隔離性（不影響其他事務）和永續性。所有這些保證都在整個叢集中保留。

在資料一致性關鍵場景中，EMQ X 採用 Mnesia 事務。

### NoSQL

傳統的關係型資料庫使用一種稱為 SQL 的特殊查詢語言與資料庫進行互動，這種資料庫通常使用 [ORM（物件關係對映）](https://en.wikipedia.org/wiki/Object–relational_mapping) 來加快開發速度。 另一方面，Mnesia 沒有專門的查詢語言：它使用 Erlang（或 Elixir）作為查詢語言，因此不需要 ORM。 它直接使用 Erlang 術語進行查詢操作，與業務邏輯的整合非常順暢。

### 架構

在 Mnesia 叢集中，所有節點都是平等的。 每個節點都可以儲存任何表的副本、啟動事務並訪問這些表。 Mnesia 叢集使用全網狀拓撲：每個節點都與叢集中的所有其他節點對話。 每個事務都被複制到叢集中的所有節點，如下圖所示：

![Mnesia 叢集](http://img.blog.itpub.net/blog/2021/11/01/bfb440c5f45a094d.png?x-oss-process=style/bb "Mnesia 叢集")

針對 [CAP 原則](https://en.wikipedia.org/wiki/CAP_theorem)（在一致性、可用性、分割槽容錯性三個要素中選擇兩個），Mnesia 預設為 AP（可用性、分割槽容錯性）。

## 挑戰

綜上所述，Mnesia 資料庫有一系列獨特的功能，並都在 EMQ X 中得到了使用。現在，我們要談談它的缺點以及我們改進它的原因。

儘管 Mnesia 與硬體無關，但它最初的開發考慮了特定的叢集架構：一組伺服器，透過快速、低延遲的區域網實現互連。

在理想條件下，網狀拓撲結構可以減少事務複製延遲：節點之間的所有通訊都可以並行完成，無需任何中介。 然而，它限制了叢集的水平可擴充套件性，因為節點之間的連結數量和節點數量之間是平方關係。隨著節點數量的增加，保持所有節點完全同步的成本越來越高，事務的效能也會下降。

節點的同等性質和傳統的叢集正規化疊加後，使得更換單個節點變得容易，但是可以同時加入叢集的節點數量受到限制。

於是我們就面臨這樣一個局面：叢集部署在地理冗餘的雲環境中，一切都是動態的和暫時的，節點在自動擴充套件組中執行，我們希望它們一直在波動狀態。

為了應對這些挑戰，我們對 Mnesia 進行了擴充套件，稱之為 Mria。

## 對策：Mria 的引入

[Mria](https://github.com/emqx/mria) 是 Mnesia 的開源擴充套件版本，它為 Mnesia 帶來了最終一致性。

Mria 從全網狀拓撲架構轉變為網狀+星型拓撲架構。 每個節點承擔兩個角色其中之一：核心（core）或複製者（replicant）。

核心（core）節點的行為很像常規的 Mnesia 節點：它們以全網狀連線，每個節點都可以發起寫事務、持有鎖等。核心節點很大程度上都是靜態和持久的。

另一方面，複製（replicant）節點不參與事務。它們連線到某一個核心節點，並被動地從中複製事務。這意味著不允許複製節點自行執行任何寫操作。相反，它們要求核心節點代表它們更新資料。同時，它們擁有資料的完整本地副本，因此讀取訪問速度也同樣快。

![Mria 叢集](http://img.blog.itpub.net/blog/2021/11/01/15512e2307ee4314.png?x-oss-process=style/bb "Mria 叢集")

可以將 Mria 看作是客戶端-伺服器和嵌入式資料庫的組合：透過伺服器寫入，但在本地讀取。

這種叢集拓撲架構解決了兩個問題：

- 水平可擴充套件性
- 支援叢集自動擴充套件

由於複製節點不參與寫入，因此當向叢集新增更多複製節點時，事務延遲不會受到影響，從而允許建立更大的 EMQ X 叢集。

此外，複製節點被設計為暫時的。 新增或刪除它們不會改變資料冗餘，因此可以將它們放在自動擴充套件組中，從而實現更好的 DevOps 實踐。

在下一篇文章中，我們將更詳細地討論如何配置 EMQ X 來充分 Mria 的優勢。

## 本系列中的其它文章

- [MQTT Broker 叢集詳解（一）：負載均衡](http://blog.itpub.net/69958136/viewspace-2787449/)

- [MQTT Broker 叢集詳解（二）：粘性會話負載均衡](http://blog.itpub.net/69958136/viewspace-2793466/)

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

有關 EMQ X 水平可擴充套件性的挑戰與對策 - MQTT Broker 叢集詳解（三）

相關文章