在這篇文章中，我們將介紹 MQTT Broker 集群在可擴展性方面的一些改進。 我們將主要關注 EMQX 內部使用的數(shù)據(jù)庫引擎，以及它在 EMQX 5.0 版本中是如何改進的。

在開始本文之前，我們需要了解 EMQX 集群中是數(shù)據(jù)是如何復制的：EMQX broker 將主題和客戶端的運行時信息存儲在 Mnesia 數(shù)據(jù)庫中，有助于跨集群復制數(shù)據(jù)。

Mnesia 是一個開源數(shù)據(jù)庫管理系統(tǒng)，由愛立信公司開發(fā)作為開放電信平臺（ Open Telecom Platform ）的一部分，最初是用來處理 ISP 級電信交換機中的配置和運行時數(shù)據(jù)。EMQX 4.3 之前的版本使用其來存儲各種運行時數(shù)據(jù)，例如主題、路由、ACL 規(guī)則、告警等等。

MySQL、Postgres、MongoDB 等數(shù)據(jù)庫以及 Redis 和 memcached 等內存存儲大家應該都非常熟悉，對 Mnesia 則可能不甚了解。但它確實有其獨特的優(yōu)勢，可將上述產品的許多功能集成到一個簡潔的應用程序中。

Mnesia 有一個相當學術的定義：一個嵌入式、分布式、事務型的 noSQL（非關系型）數(shù)據(jù)庫。聽起來有些復雜，我們接下來將逐一為大家解釋。

MySQL 和 Postgres 等最廣泛使用的數(shù)據(jù)庫普遍采用客戶端—服務器模式：數(shù)據(jù)庫在單獨的進程中運行（通常在專用服務器上），業(yè)務應用程序通過網(wǎng)絡或 UNIX 域套接字發(fā)送請求并等待答復，通過這種方式來與數(shù)據(jù)庫交互。這種模式在很多方面都很方便，因為它允許將業(yè)務邏輯與存儲分開并單獨管理。 但同時也有一些缺點：與遠程進程交互不可避免地會增加每個請求的延遲。

相反，嵌入式數(shù)據(jù)庫與業(yè)務應用程序則在相同的進程中運行。sqlite 是一個典型的嵌入式數(shù)據(jù)庫的例子。Mnesia 也屬于這一類：它與其他 EMQX 應用程序在同一進程中運行。 從 Mnesia 表中讀取數(shù)據(jù)可以像讀取局部變量一樣快，因此我們可以在熱點中讀取數(shù)據(jù)庫數(shù)據(jù)而不會影響性能。

我們之前提到過 Mnesia 是一個分布式數(shù)據(jù)庫，這意味著數(shù)據(jù)表被網(wǎng)絡復制到不同的物理位置。對于分布式數(shù)據(jù)庫，如果節(jié)點之間不共享任何物理資源（如 RAM 或磁盤），而是在應用程序級別進行協(xié)調，這種類型稱為無共享架構 (SN)。 這種類型通常是首選，因為它不需要任何專門的硬件，并且可以水平擴展。

Mnesia 應用程序與 EMQX 一起運行，有助于通過 Erlang 分發(fā)協(xié)議跨集群中的所有節(jié)點復制表更新。 這意味著業(yè)務應用程序可以在本地讀取更新的數(shù)據(jù)。它還有助于提升容錯性能：只要集群中有一個節(jié)點處于活動狀態(tài)，數(shù)據(jù)就是安全的。EMQX 依靠此功能實現(xiàn)跨集群復制路由信息。

Mnesia 支持 ACID 事務，這是嵌入式數(shù)據(jù)庫的一個非常獨特的功能。這意味著可以將多個讀取和更新操作組合在一起。一個 Mnesia 事務具有原子性（必須完整或無任何效力）、一致性（盡管保證比 Postgres 更寬松）、隔離性（不影響其他事務）和持久性。所有這些保證都在整個集群中保留。

在數(shù)據(jù)一致性關鍵場景中，EMQX 采用 Mnesia 事務。

傳統(tǒng)的關系型數(shù)據(jù)庫使用一種稱為 SQL 的特殊查詢語言與數(shù)據(jù)庫進行交互，這種數(shù)據(jù)庫通常使用 ORM（對象關系映射） 來加快開發(fā)速度。 另一方面，Mnesia 沒有專門的查詢語言：它使用 Erlang（或 Elixir）作為查詢語言，因此不需要 ORM。 它直接使用 Erlang 術語進行查詢操作，與業(yè)務邏輯的集成非常順暢。

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

Mnesia 集群

針對 CAP 原則（在一致性、可用性、分區(qū)容錯性三個要素中選擇兩個），Mnesia 默認為 AP（可用性、分區(qū)容錯性）。

綜上所述，Mnesia 數(shù)據(jù)庫有一系列獨特的功能，并都在 EMQX 中得到了使用。現(xiàn)在，我們要談談它的缺點以及我們改進它的原因。

盡管 Mnesia 與硬件無關，但它最初的開發(fā)考慮了特定的集群架構：一組服務器，通過快速、低延遲的局域網(wǎng)實現(xiàn)互連。

在理想條件下，網(wǎng)狀拓撲結構可以減少事務復制延遲：節(jié)點之間的所有通信都可以并行完成，無需任何中介。 然而，它限制了集群的水平可擴展性，因為節(jié)點之間的鏈接數(shù)量和節(jié)點數(shù)量之間是平方關系。隨著節(jié)點數(shù)量的增加，保持所有節(jié)點完全同步的成本越來越高，事務的性能也會下降。

節(jié)點的同等性質和傳統(tǒng)的集群范式疊加后，使得更換單個節(jié)點變得容易，但是可以同時加入集群的節(jié)點數(shù)量受到限制。

于是我們就面臨這樣一個局面：集群部署在地理冗余的云環(huán)境中，一切都是動態(tài)的和暫時的，節(jié)點在自動擴展組中運行，我們希望它們一直在波動狀態(tài)。

為了應對這些挑戰(zhàn)，我們對 Mnesia 進行了擴展，稱之為 Mria。

Mria 是 Mnesia 的開源擴展版本，它為 Mnesia 帶來了最終一致性。

Mria 從全網(wǎng)狀拓撲架構轉變?yōu)榫W(wǎng)狀+星型拓撲架構。 每個節(jié)點承擔兩個角色之一：核心（core）或復制者（replicant）。

核心（core）節(jié)點的行為很像常規(guī)的 Mnesia 節(jié)點：它們以全網(wǎng)狀連接，每個節(jié)點都可以發(fā)起寫事務、持有鎖等。核心節(jié)點很大程度上都是靜態(tài)和持久的。

另一方面，復制（replicant）節(jié)點不參與事務。它們連接到某一個核心節(jié)點，并被動地從中復制事務。這意味著不允許復制節(jié)點自行執(zhí)行任何寫操作。相反，它們要求核心節(jié)點代表它們更新數(shù)據(jù)。同時，它們擁有數(shù)據(jù)的完整本地副本，因此讀取訪問速度也同樣快。

Mria 集群

可以將 Mria 看作是客戶端-服務器和嵌入式數(shù)據(jù)庫的組合：通過服務器寫入，但在本地讀取。

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

• 水平可擴展性
• 支持集群自動擴展

由于復制節(jié)點不參與寫入，因此當向集群添加更多復制節(jié)點時，事務延遲不會受到影響，從而允許創(chuàng)建更大的 EMQX 集群。

此外，復制節(jié)點被設計為暫時的。 添加或刪除它們不會改變數(shù)據(jù)冗余，因此可以將它們放在自動擴展組中，從而實現(xiàn)更好的 DevOps 實踐。

在下一篇文章中，我們將更詳細地討論如何配置 EMQX 來充分 Mria 的優(yōu)勢。

• MQTT Broker 集群詳解（一）：負載均衡

• MQTT Broker 集群詳解（二）：粘性會話負載均衡

• 原創(chuàng)文章，作者：EMQ，如若轉載，請注明出處：https://www.emqx.com/zh/blog/mqtt-broker-clustering-part-3-challenges-and-solutions-of-emqx-horizontal-scalability