在 MQTT Broker 集群架构这条技术演进路线上，FreeMQTT Plus 的黑白（A/B）节点架构采用了一套辨识度很高的设计思路。若将它与 EMQX、HiveMQ、VerneMQ 等主流 MQTT 集群方案放在一起比较，差异主要集中在几个核心维度：节点职责如何划分、集群内部如何通信、对外部组件的依赖程度，以及整体扩容模型究竟如何设计。下面就从这几个方面展开分析。
一、架构模型对比
| 维度 | FreeMQTT Plus | EMQX 5.x | HiveMQ | VerneMQ |
|---|---|---|---|---|
| 核心设计 | A/B 黑白节点分离：A 负责接入，B 负责路由总线 | Core Replicant：Core 处理写入，Replicant 只读复制 | Masterless 无主集群，全对等节点 | 基于 Plumtree/Epidemic Broadcast 的对等集群 |
| 节点角色 | A 节点（接入 Broker） B 节点（路由总线） L 节点（日志，可选） | Core 节点（数据库层） Replicant 节点（无状态业务层） | 所有节点对等，通过嵌入式 KV 存储共享状态 | 所有节点对等，共享状态 |
| 客户端可见性 | 仅 A 节点对外可见，B 节点完全透明 | Core 和 Replicant 均可接受客户端连接 | 所有节点均可接受连接，呈现单一逻辑 Broker | 所有节点均可接受连接 |
| 实现语言 | Python / Tornado | Erlang/OTP | Ja va | Erlang/OTP |
二、关键差异详解
1. 节点职责分离 vs. 数据层分离
FreeMQTT Plus 的创新点在于按功能进行垂直拆分，而不是按数据进行水平拆分：
A 节点（黑节点）：仅负责承载客户端 TCP/WS/TLS 连接、维护本地会话、管理订阅以及离线消息。A 节点之间不直接通信，彼此完全独立。 B 节点（白节点）：仅负责跨 A 节点的消息路由、会话查询以及共享订阅分发。所有 B 节点共同组成一个分布式路由总线，但自身不承载任何客户端连接。这种 MQTT 集群设计的最大优势在于，连接层与路由层能够独立扩容：当设备连接数不足时只增加 A 节点；当跨节点消息吞吐压力上升时只增加 B 节点，从而提升资源利用率与集群弹性。
相比之下：
EMQX 的 Core/Replicant 分离是基于数据读写权限的拆分：Core 节点组成全连接数据库层，负责所有写入；Replicant 被动复制数据并处理客户端连接。这更接近传统数据库主从分离在 MQTT Broker 中的应用。 HiveMQ 则采用全对等无主架构，每个节点既负责连接处理，也承担消息路由，通过嵌入式分布式 KV 存储同步会话状态，对客户端呈现为单一逻辑 Broker。2. 集群通信机制：零外部依赖 vs. 内置数据库/KV 存储
FreeMQTT Plus 最突出的特点之一，就是实现了真正意义上的零外部依赖：
A 节点与 B 节点之间仅通过 MQTT 5.0 原生协议通信，利用 User Property 和 Correlation Data 定义了 17 种内部元指令（如SESSION_QUERY、ROUTE_MESSAGE 等）。 不需要 Redis、ZooKeeper、etcd、Gossip 协议等任何第三方组件来完成集群协调或会话存储。 而其他主流 MQTT Broker 集群方案则有所不同：
EMQX 依赖 Erlang/OTP 内置的 Mria 数据库（Mnesia 的扩展）来完成数据复制与集群协调，Core 节点之间通常要求低延迟网络（<10ms）。 HiveMQ 依赖嵌入式分布式键值存储来复制会话与消息状态。 VerneMQ 曾尝试使用 Plumtree（Epidemic Broadcast Trees）算法进行集群状态同步，但该架构在实际落地中被证明存在问题，项目目前也已停止积极开发。3. 会话迁移：无粘性会话 vs. 粘性会话/状态复制
FreeMQTT Plus 实现了真正的无粘性会话（No Sticky Session）：
客户端可以随机重连到任意 A 节点，新 A 节点会通过 B 总线广播SESSION_QUERY 查询原 A 节点，并自动恢复订阅、未确认消息以及 Retain 信息。 这意味着无需依赖负载均衡器维持客户端与特定节点的绑定关系，节点发生故障时，客户端迁移过程也几乎完全透明。 其他方案则通常采用不同模式：
EMQX 4.x 及更早版本：通常需要粘性会话（Sticky Session），或者要求客户端重连后重新订阅。 EMQX 5.x Replicant：虽然 Replicant 节点本身无状态，但客户端断开后若重连到新的 Replicant，会话数据仍依赖 Core 节点复制，本质上依然属于状态复制模型。 HiveMQ：通过集群内会话状态复制实现无缝迁移，但依赖其内部 KV 存储的复制机制。4. 扩容模型：独立弹性 vs. 整体扩容
FreeMQTT Plus：
A 和 B 节点完全解耦，支持独立弹性扩缩容。例如白天设备在线高峰时自动扩容 A，夜间消息上报高峰时自动扩容 B。 新增节点可直接加入集群，无需数据迁移、无需分片重平衡，也无需重启整个集群。EMQX：
Replicant 节点可进行无状态扩缩容，但 Core 节点由于参与全连接事务处理，并不建议频繁变动（通常不推荐自动扩缩容）。 开源版最多限制 3 个节点（全 Core 模式），而大规模 Core Replicant 架构通常需要企业版支持。HiveMQ：
支持动态增加或移除节点，但由于所有节点都参与状态存储与复制，扩容过程中仍然会产生状态同步开销。5. 性能与规模定位
| 方案 | 定位 | 规模能力 |
|---|---|---|
| FreeMQTT Plus | 轻量级、易部署的集群方案 | 强调单机多核利用（突破 Python GIL），适合中小规模到百万级连接 |
| EMQX | 超大规模企业级 | 企业版实测 23 节点支持 1 亿并发连接，适合电信/车联网级 |
| HiveMQ | 工业级企业方案 | 支持千万级并发客户端，强调工业 UNS（统一命名空间）集成 |
| VerneMQ | 分布式但已停滞 | 理论上支持百万级连接，但项目维护不活跃，生产环境风险高 |
三、总结：FreeMQTT Plus 的独特价值
FreeMQTT Plus 的 A/B 架构本质上是一种分层式分布式架构的极简实现版本，它通过以下设计在易用性、性能与可靠性之间取得了独特平衡：
极简依赖：仅使用 MQTT 5.0 协议自身实现集群协调，降低了对 Redis、etcd、ZooKeeper 等外部中间件的依赖，也减少了单点故障风险。 故障域隔离：A 节点故障只会影响本机在线设备，B 节点故障不会影响客户端连接，且由于 B 节点不承载客户端连接，故障影响面更小。 垂直解耦：连接与路由支持独立扩容，能够更精准地匹配资源瓶颈，避免传统一体化 Broker 出现“为连接扩容却浪费路由资源”的问题。 部署极简：单一 Docker 镜像支持 A/B 双模式，配合 Docker Swarm/K8s 可分别为 A、B 设置独立弹性策略，具备“10 分钟部署集群”的优势。适用场景建议：
如果你追求极简运维、零外部依赖、快速部署，并且业务规模在百万级连接以内，那么 FreeMQTT Plus 的 A/B 架构会是一个很有吸引力的 MQTT Broker 集群方案。 如果你需要超大规模部署（千万级以上）、深度企业集成能力（如 Kafka、规则引擎、QUIC），那么 EMQX 企业版或 HiveMQ 仍然是更成熟的选择。 VerneMQ 由于当前维护停滞，已不建议在新项目中继续采用。
