支持上亿物联网终端设备接入的MQTT集群

1. MQTT 协议简介

  MQTT是一种轻量级、灵活、可扩展的发布/订阅消息传递协议，常用于物联网(IoT)领域。它可以在不同的网络环境中传递小型的消息，使得在低带宽和不可靠的网络环境下进行通信变得更加容易。

1.1 MQTT 几个重要概念

• Broker: MQTT协议中的中介，负责接收和转发消息。客户端需要连接到Broker才能进行消息的发布和订阅。

• Topic: MQTT中的消息主题，用于标识消息的类型或内容。客户端可以发布或订阅一个或多个主题。例如，一个温度传感器可以发布温度数据到名为“温度”的主题上。

• QoS: MQTT支持3种消息质量等级(QoS)，用于确保消息传递的可靠性。QoS 0表示消息最多传递一次，QoS 1表示消息至少传递一次，QoS 2表示消息恰好传递一次。

• 客户端: MQTT连接到Broker的客户端，可以是发布者、订阅者或两者兼备。

1.2 MQTT相关产品与服务

1.2.1 MQTT Broker

  MQTT Broker 是MQTT协议的核心组件，负责接收和转发消息。常用的 MQTT Broker 包括Eclipse Mosquitto、EMQX、HiveMQ、ActiveMQ、Mosca等，它们提供了开源和商业版本供用户选择。

1.2.2 MQTT云平台

  MQTT云平台是基于MQTT协议的云服务，可以提供MQTT Broker、数据存储、数据分析等功能，使得开发者可以快速构建和管理物联网应用。常用的MQTT云平台包括AWS IoT、Microsoft Azure IoT、IBM Watson IoT等。

1.2.3 MQTT客户端库

  MQTT客户端库用于在客户端设备上实现MQTT协议，以便与Broker进行通信。主流的MQTT客户端库包括Paho MQTT、MQTT.js、Eclipse Kura等，支持各种编程语言和平台，例如Java、Python、JavaScript等。

  本文选取 EMQX 作为研究对象，基于 EMQX 开源版本搭建 MQTT 服务集群。

2. EMQX 企业版与开源版功能对比

备注：上图数据来源于EMQ官方网站–产品概览。

  如上图所示，红色部分为开源版本不支持的功能。开源版本与企业版本从伸缩性与性能上对比基本上一致，即不管是开源版本还是企业版本均支持至多1亿的连接以及500万每秒的消息，这样能够满足大部分业务场景，如果团队没有运维资源，则考虑使用企业版会有更高的 SLA 稳定性保障；如果团队有自己的运维力量，且对于企业版扩展的功能没有很强烈的需求，则可以考虑使用开源版本。

3. EMQX 集群部署

3.1 EMQX 集群架构

3.1.1 EMQX 4.x 以及以前版本架构

  EMQX 集群中所有节点之间两两互相连结的架构。

3.1.2 EMQX 5.x 基于 Mria 的新架构

  EMQX 集群的节点分为核心节点（Mria Core）与复制节点（Mria Replicant），核心节点之间两两互相连结。

• 核心节点：核心节点作为数据库的数据层，节点间以全网状连接，每个节点都包含一个最新的数据副本，这保证了容错性：只要有一个节点存活，数据就不会丢失。核心节点一般是静态和持久的，不建议进行自动伸缩（即经常添加、删除或替换节点）。

• 复制节点：复制节点会连接到核心节点，并被动地复制来自核心节点的数据更新。复制节点不允许执行任何的写操作，而是将其转交给核心节点代为执行。同时，由于复制节点有一个完整的本地数据副本，因此数据读取速度非常快，这样有助于降低 EMQX 路由的时延。

  将这种数据复制模型当做无主复制和主从复制的一种混合，这种结构的优势在于：

• 更高的水平可扩展性：EMQX 5.0 已能支持包含 23 个节点的大规模集群。
• 更轻松的集群自动扩展：通过复制节点的自动伸缩简化集群的自动扩展。

  相比与 4.x 版本所有节点采用全连接的方式，节点数量越多节点之间完成数据同步的成本就越高，EMQX 5.0 中由于复制节点不参与数据写入，当更多的复制节点加入集群时，表的更新效率不会受到影响，进而允许创建更大的 EMQX 集群。

  另外，复制节点被设计成可以按需增删，添加或删除它们不会改变数据冗余，所以它们可以被放在一个自动伸缩组中，从而实现更好的 DevOps 实践。但随着总数据量的增大，从核心节点初始化复制数据是一个相对繁重的操作，所以复制节点的自动伸缩策略不也能太过于激进。
  上述内容摘抄至EMQ官网，关于EMQX集群架构详细信息请参考：部署架构与集群要求。

3.1.3 EMQX 集群节点发现策略

  节点发现作为创建分布式集群的必要过程，EMQX 默认配置采用手动发现策略创建集群，配置信息在 /etc/emqx/emqx.conf 配置文件中。

cluster {
  name = emqxcl
  discovery_strategy = manual
}
1
2
3
4

  discovery_strategy 的值可以是：manual | static | mcast | dns | etcd | K8s。分别对应不同的节点发现方式。不同发现方式详细信息请参考：EMQX集群节点发现。

3.2 EMQX 集群支持的部署方式

• Kubernetes Operator 部署
• Docker 容器部署
• 源码编译安装部署
• 二进制安装包部署（Linux、Windows、MacOS）

3.3 EMQX 集群部署过程

  首先打开EMQ的官方网站，找到安装包下载入口，然后在部署方式中选择EMQX下载。
点击 EMQX 下载后，下边将会出现企业版与开源版两行，然后选择 EMQX 开源版，如下图所示：

  根据操作系统版本选择对应的版本，然后点击 免费下载 按钮。本文以 Centos 7 为例。选择 Centos 7 后点击免费下载进入到安装包的下载页面。

  选择安装方式为 rpm，CPU 架构为 amd64，然后执行下边的命令获取到 emqx 的 rpm 安装包。如果不知道如何选择CPU与内存的配置，可以使用EMQ提供的配置估算工具进行粗略的计算，实际生产环境需要的配置信息以实际运行为准。配置估算工具地址。

3.3.1 EMQX 安装部署

• 下载安装包

mkdir -p /opt/emq
cd /opt/emq
wget https://www.emqx.com/zh/downloads/broker/5.0.24/emqx-5.0.24-el7-amd64.rpm
1
2
3

• 安装 EMQX 以及依赖

sudo yum install emqx-5.0.24-el7-amd64.rpm -y
1

• 修改EMQX的节点名称，将 /etc/emqx/emqx.conf 配置文件中参数 name 的值设置成 emqx@节点内网IP地址 的形式

node {
  name = "emqx@192.168.0.200"
  cookie = "emqxsecretcookie"
  data_dir = "/var/lib/emqx"
}
1
2
3
4
5

• 启动 EMQX 服务

sudo systemctl start emqx
1

在每一台节点分别执行上边的命令，完成各节点单机版本的部署。

• 查看服务运行情况

netstat -ltnp | grep emq
1

或者通过 18083 端口打开 emqx 的 dashboard 控制台进行管理，访问地址：http://节点IP:18083。首次登陆账号为：admin，密码是：public。

3.3.2 创建集群或加入集群

  采用手工发现策略创建集群。假设 EMQX 节点 1 的节点名称是：emqx@192.168.0.200， EMQX 节点2 的名称是：emqx@192.168.0.145。在节点2上执行下边名称创建集群：

emqx_ctl cluster join emqx@192.168.0.200
1

• 查看集群状态，如下图所示，表示当前集群中有两个节点处于 running 状态。

emqx_ctl cluster status
1

3.3.3 退出集群

emqx_ctl cluster leave
1

3.4 EMQX 优化改进

3.4.1 性能测试与资源优化

• EMQ提供了开源的性能测试工具，工具下载地址 emqtt-bench。
• 系统参数优化，详细信息请参考 EMQX 系统调优

3.4.2 EMQX 集群脑裂问题

  EMQX 4.x 以及之前版本采用了 Erlang/OTP 自带的实时分布式数据库 Mnesia，其支持两种数据访问模式：本地模式与远程模式。本地模式是全连接、点对点复制模式，如上边的 3.1.1 章节所示，节点中的数据会复制到集群中其他所有节点。远程模式是数据分布到集群中的不同节点，如果当前节点没有客户端想要访问的数据，则这个节点通过RPC访问其他节点获取数据。本地模式的优点是网络开销小，数据访问效率高，只要集群有一个节点正常，就能保障数据的完整，缺点是水平扩展性差，存在脑裂风险。
   EMQX 5.x 引入了 Mria 新架构，如上边的 3.1.2 章节所示，将集群中所有节点分为核心节点与复制节点，核心节点之间采用全连接、点对点模式，复制节点只与某个制定的核心节点进行数据被动同步更新。通过降低集群中复制节点与核心节点 Mnesia 数据库事务处理，有效的降低了集群脑裂的风险。

   EMQX 通过设置 /etc/emqx/emqx.conf 参数 cluster.autoheal = on 开启集群网络分区自动修复功能。

• 节点在收到 Mnesia 的 “数据库不一致” 事件 3 秒后执行网络分区确认。
• 节点确认网络分区发生后，它将消息报告给 Leader 节点（集群中最早开始的节点）。
• 在 Leader 节点延迟一段时间后，当所有节点都在线时，它创建一个 SplitView。
• Leader 节点选择多数分区中的自愈协调者节点。
• 协调者节点重新启动少数派分区的节点以恢复集群

3.4.3 EMQX集群负载均衡

  负载均衡（Load Balancing）用于均衡多个网络组件的负载，从而优化资源的使用，避免由于组件过载造成故障。负载均衡虽然不是集群中的必备组件，但是能给集群带来一些非常有用的特性，例如当配置在 EMQX 集群中时，将能带来如下优势：

• 均衡 EMQX 的负载，避免出现单节点过载的情况；
• 简化客户端配置，客户端只需连接到负载均衡器上，无需关心集群内部伸缩变化；
• TLS/SSL 终结，减轻 EMQX 集群的负担；
• 提高安全性，有了负载均衡在集群前端，能够通过设置阻止不需要的流量，保护 EMQX 集群免受恶意攻击。

  当在 EMQX 中部署 LB (负载均衡器) 后，LB 会负责处理 TCP 连接，并将收到的 MQTT 连接与消息分发到不同的 EMQX 集群节点，部署架构如下所示：

• EMQX TCP 负载均衡部署
  

  推荐在 LB 终结 SSL/TLS 连接。设备与 LB 之间采用 SSL/TLS 安全连接，LB 与 EMQX 之间普通 TCP 连接，这种模式能够使 EMQX 集群性能最大化，部署架构如下所示：

• EMQX 负载均衡终结 TLS 部署
  

  除了负载均衡部署集群外，还可以使用 DNS 轮询直连 EMQX 集群，即将所有节点加入 DNS 轮询列表，设备通过域名或者 IP 地址列表访问集群，通常不建议在生产环境中采用 DNS 轮询直连方式。

备注：以上内容来源于EMQ官方网站。

4. 总结

  EMQX 5.x 版本单集群支持至多1亿设备的接入，以及每秒500百万消息发布，基本上满足当前大多数物联网相关业务场景，例如车联网云平台车辆接入。开源版本与企业版本在设备接入上限与性能上基本上一致，极大的提升了开源版本的应用价值，对于拥有运维实力的团队，且对于企业版本功能诉求没有那么高的场景下，可以部署开源版本降低软件采购成本；对于缺乏运维实力，或者期望使用企业版的拓展功能时，可以考虑购买企业版，提升服务的可靠性，降低维护难度。