FreeMQTT Plus 的黑白（A/B）节点架构在 MQTT Broker 集群领域采用一种独特的设计思路。与 EMQX、HiveMQ、VerneMQ 等主流方案相比，其核心差异体现在节点职责分离方式、集群通信机制、外部依赖程度以及扩容模型上。以下是详细对比：
一、架构模型对比
| 维度 | 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 | Java | Erlang/OTP |
二、关键差异详解
1. 节点职责分离 vs. 数据层分离
FreeMQTT Plus 的创新在于按功能垂直拆分而非按数据水平拆分：
- A 节点（黑节点）：只负责承载客户端 TCP/WS/TLS 连接、维护本地会话、订阅和离线消息。A 节点之间不直接通信，完全独立。
- B 节点（白节点）：只负责跨 A 节点的消息路由、会话查询和共享订阅分发。所有 B 节点组成一个分布式路由总线，但本身不承载任何客户端连接。
这种设计的最大好处是连接层和路由层可以独立扩容：设备连接数不够时只加 A 节点，跨节点消息吞吐压力大时只加 B 节点，资源利用率更高。
相比之下：
- EMQX 的 Core/Replicant 分离是按数据读写权限拆分：Core 节点组成全连接的数据库层处理所有写入，Replicant 被动复制数据并处理客户端连接。这更像传统数据库的主从分离在 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 协议等任何第三方组件来协调集群或存储会话。
而其他方案：
- 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 架构非常有吸引力。
- 如果你需要超大规模（千万级以上）、深度企业集成（Kafka/规则引擎/QUIC），EMQX 企业版或 HiveMQ 仍是更成熟的选择。
- VerneMQ 目前因维护停滞，不建议在新项目中采用。
