在這篇文章中，我們將介紹 MQTT Broker 集羣在可擴展性方面的一些改進。 我們將主要關注 EMQ X 內部使用的數據庫引擎，以及它在 EMQ X 5.0 版本中是如何改進的。
在開始本文之前，我們需要了解 EMQ X 集羣中是數據是如何複製的：EMQ X broker 將主題和客戶端的運行時信息存儲在 Mnesia 數據庫中，有助於跨集羣複製數據。
Mnesia 簡介
Mnesia 是一個開源數據庫管理系統，由愛立信公司開發作爲開放電信平臺（ 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 事務，這是嵌入式數據庫的一個非常獨特的功能。這意味着可以將多個讀取和更新操作組合在一起。一個 Mnesia 事務具有原子性（必須完整或無任何效力）、一致性（儘管保證比 Postgres 更寬鬆）、隔離性（不影響其他事務）和持久性。所有這些保證都在整個集羣中保留。
在數據一致性關鍵場景中，EMQ X 採用 Mnesia 事務。
NoSQL
傳統的關係型數據庫使用一種稱爲 SQL 的特殊查詢語言與數據庫進行交互，這種數據庫通常使用 ORM（對象關係映射） 來加快開發速度。 另一方面，Mnesia 沒有專門的查詢語言：它使用 Erlang（或 Elixir）作爲查詢語言，因此不需要 ORM。 它直接使用 Erlang 術語進行查詢操作，與業務邏輯的集成非常順暢。
架構
在 Mnesia 集羣中，所有節點都是平等的。 每個節點都可以存儲任何表的副本、啓動事務並訪問這些表。 Mnesia 集羣使用全網狀拓撲：每個節點都與集羣中的所有其他節點對話。 每個事務都被複制到集羣中的所有節點，如下圖所示：
針對 CAP 原則（在一致性、可用性、分區容錯性三個要素中選擇兩個），Mnesia 默認爲 AP（可用性、分區容錯性）。
挑戰
綜上所述，Mnesia 數據庫有一系列獨特的功能，並都在 EMQ X 中得到了使用。現在，我們要談談它的缺點以及我們改進它的原因。
儘管 Mnesia 與硬件無關，但它最初的開發考慮了特定的集羣架構：一組服務器，通過快速、低延遲的局域網實現互連。
在理想條件下，網狀拓撲結構可以減少事務複製延遲：節點之間的所有通信都可以並行完成，無需任何中介。 然而，它限制了集羣的水平可擴展性，因爲節點之間的鏈接數量和節點數量之間是平方關係。隨着節點數量的增加，保持所有節點完全同步的成本越來越高，事務的性能也會下降。
節點的同等性質和傳統的集羣範式疊加後，使得更換單個節點變得容易，但是可以同時加入集羣的節點數量受到限制。
於是我們就面臨這樣一個局面：集羣部署在地理冗餘的雲環境中，一切都是動態的和暫時的，節點在自動擴展組中運行，我們希望它們一直在波動狀態。
爲了應對這些挑戰，我們對 Mnesia 進行了擴展，稱之爲 Mria。
對策：Mria 的引入
Mria 是 Mnesia 的開源擴展版本，它爲 Mnesia 帶來了最終一致性。
Mria 從全網狀拓撲架構轉變爲網狀+星型拓撲架構。 每個節點承擔兩個角色之一：核心（core）或複製者（replicant）。
核心（core）節點的行爲很像常規的 Mnesia 節點：它們以全網狀連接，每個節點都可以發起寫事務、持有鎖等。核心節點很大程度上都是靜態和持久的。
另一方面，複製（replicant）節點不參與事務。它們連接到某一個核心節點，並被動地從中複製事務。這意味着不允許複製節點自行執行任何寫操作。相反，它們要求核心節點代表它們更新數據。同時，它們擁有數據的完整本地副本，因此讀取訪問速度也同樣快。
可以將 Mria 看作是客戶端-服務器和嵌入式數據庫的組合：通過服務器寫入，但在本地讀取。
這種集羣拓撲架構解決了兩個問題：
- 水平可擴展性
- 支持集羣自動擴展
由於複製節點不參與寫入，因此當向集羣添加更多複製節點時，事務延遲不會受到影響，從而允許創建更大的 EMQ X 集羣。
此外，複製節點被設計爲暫時的。 添加或刪除它們不會改變數據冗餘，因此可以將它們放在自動擴展組中，從而實現更好的 DevOps 實踐。
在下一篇文章中，我們將更詳細地討論如何配置 EMQ X 來充分 Mria 的優勢。
本系列中的其它文章
版權聲明： 本文爲 EMQ 原創，轉載請註明出處。
技術支持：如對本文或 EMQ 相關產品有疑問，可訪問 EMQ 問答社區 https://askemq.com 提問，我們將會及時回覆支持。
更多技術乾貨，歡迎關注我們公衆號【EMQ 中文社區】。