共计 2763 个字符，预计需要花费 7 分钟才能阅读完成。
在这篇文章中，咱们将介绍 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 中文社区】。
