在這篇文章中，我們將介紹 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 的優勢，
本系列中的其它文章
-
MQTT Broker 集群詳解（一）：負載均衡
-
MQTT Broker 集群詳解（二）：粘性會話負載均衡
著作權宣告： 本文為 EMQ 原創，轉載請注明出處，
原文鏈接：https://www.emqx.com/zh/blog/mqtt-broker-clustering-part-3-challenges-and-solutions-of-emqx-horizontal-scalability
技術支持：如對本文或 EMQ 相關產品有疑問，可訪問 EMQ 問答社區 https://askemq.com 提問，我們將會及時回復支持，
更多技術干貨，歡迎關注我們公眾號【EMQ 中文社區】，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/344374.html
標籤：其他
上一篇：5G工業物聯網網關功能作用