1. EMQX集群架构总览
在物联网系统中，设备数量往往从几千到百万级不等，连接协议涵盖 MQTT、MQTT over WebSocket、CoAP、LwM2M 等，消息模式既有高频遥测上报，也有低频指令下发。EMQX 在这类系统中承担的角色，是位于设备与应用之间的消息接入与分发中枢：向下承接海量设备的并发连接与主题订阅，向上为业务平台提供统一的消息发布、订阅、规则转发与数据桥接能力。单节点 EMQX 可以完成这些功能，但当连接规模、吞吐量或可用性要求上升时，单机就会成为瓶颈和单点故障，集群化因此成为必选项。
EMQX 在物联网消息链路中的定位
从数据流向看，EMQX 处在“设备侧”和“平台侧”之间。设备通过 MQTT CONNECT 建立会话，发布到诸如 factory/line1/sensor/temp 这样的主题；EMQX 根据订阅关系把消息投递给订阅者，同时可以通过规则引擎把消息写入数据库、转发到 Kafka、调用 HTTP 接口，或桥接到另一个 EMQX 集群。也就是说，EMQX 不只是“消息中转站”，还是协议适配、主题路由、会话管理和数据分发的统一入口。
这一位置决定了它的关键职责：维持大量长连接、保证订阅匹配的正确性、在节点故障时尽量不丢失会话与消息、并让上层业务无需关心设备实际连到了哪台服务器。集群化要解决的，正是把这些职责从“一台机器扛”变成“多台机器协同扛”。
集群化要解决的核心问题
单节点 EMQX 面临三类典型问题。第一是容量上限：单机可承载的连接数、主题数和消息吞吐受 CPU、内存、文件描述符和网络带宽限制，达到上限后新设备无法接入。第二是单点故障：节点宕机后，所有连接中断，若没有持久化会话，订阅关系和未确认消息都会丢失。第三是运维连续性：升级、扩容、机房迁移都需要停机，而物联网业务通常要求 7×24 小时在线。
集群化通过多节点组成一个逻辑整体来应对这些问题。客户端连接任意一个节点，都能看到相同的主题路由信息；某个节点故障时，其他节点继续提供服务；需要扩容时，加入新节点并重新分配负载即可。EMQX 集群内部通过 Erlang/OTP 分布式机制维护节点间通信，路由表、会话信息和订阅关系在集群范围内同步或按策略分布。
高可用部署的整体目标与关键指标
高可用不是“永不停机”的口号，而是可以用指标衡量的工程目标。对 EMQX 集群而言，通常关注以下几类指标：
- 可用性：以年度停机时间衡量，例如 99.9% 对应全年约 8.76 小时不可用，99.99% 对应约 52.6 分钟。集群中至少保留一个可服务节点，是达到高可用的基本条件。
- 连接保持能力：节点故障时，客户端能否快速重连到其他节点；若使用持久会话，重连后订阅关系和未确认 QoS 1/2 消息能否恢复。
- 消息时延与吞吐：在集群规模扩大后，跨节点路由会引入额外跳数，需要观察 P99 时延和每秒消息处理量是否仍在业务可接受范围内。
- 数据一致性：路由表、会话状态在节点间的同步延迟应尽可能小，避免出现“消息已发布但订阅者所在节点尚未收到路由”的情况。
- 可扩展性：增加节点后，连接数和吞吐量应近似线性增长，而不是因为集群内部通信开销而迅速饱和。
这些指标之间往往存在权衡。例如，为了降低跨节点时延，可以让订阅者和发布者尽量落在同一节点；为了提高容灾能力，又需要把会话复制到多个节点。实际部署时，应根据业务对时延、成本和一致性的要求选择集群拓扑和会话策略。
集群架构的组成与协作关系
一个典型的 EMQX 集群由多个对等节点组成，节点之间通过 Erlang 分布式协议通信。每个节点都运行完整的 EMQX 服务，包括连接接入层、协议解析、会话管理、路由表和规则引擎。客户端可以连接到任意节点，节点根据主题路由表决定把消息转发给哪些节点，再由目标节点投递给本地订阅者。
集群之外，通常还会配合负载均衡器（如 HAProxy、Nginx 或云负载均衡）做连接分发，配合外部数据库或 Kafka 做数据持久化与桥接。负载均衡器负责把设备连接分散到各节点，并在节点健康检查失败时摘除故障节点；EMQX 集群内部则负责路由和会话的协同。两者分工不同，但共同决定整体可用性。
从单节点到集群：部署形态的演进
实际落地时，EMQX 集群通常经历几个阶段。最初是单节点部署，所有功能集中在一台服务器上，适合开发测试或小规模试点。当连接数接近单机上限时，引入负载均衡器和第二个节点，形成双节点集群，此时需要确认集群发现方式（静态节点列表、DNS 或 etcd）和会话持久化策略。进一步扩展时，节点数量增加，跨节点路由开销上升，就需要考虑按业务或地域划分集群，例如把工厂 A 的设备接入集群 A，工厂 B 接入集群 B，再通过桥接或规则引擎做数据汇聚。
部署形态的选择没有唯一答案，但判断依据是清晰的：如果业务对可用性要求高、连接规模大、且希望扩容时不影响在线设备，那么集群化就是必要投入；如果只是少量设备做验证，单节点反而更简单可控。理解集群要解决的问题和衡量指标，是后续选择具体拓扑、配置参数和排障方法的基础。