突发！车企需求验证：smart - mqtt 高可用比性能更重要
在维护 [smart - mqtt] 的这些年，常有人问：“这个 Broker 单机能支撑多少连接？”说实话，这问题不好答，不同业务场景和硬件配置，结果不同。
但前段时间，一位国内头部车企技术人员的问题让我印象深刻：“单机已经够用了，但我们还是要做集群”。沟通中我询问业务规模，对方称大概几万，单机轻松顶住，但有单点故障问题，且有高可用部署要求。
这让我意识到，对真正的生产系统，性能是工程问题，高可用才是业务问题。比如 Broker 所在服务器宕机、系统升级重启服务、节点异常退出，这些比“单机能扛多少连接”更重要。于是我决定本地复现高可用架构，验证“当 Broker 真正发生故障时，smart - mqtt 是否还能正常工作”。
其实这次验证不意外，设计 [cluster - plugin] 时，我就在想，若 smart - mqtt 用于企业生产环境，最先遇到的问题是什么？答案不是性能，而是高可用，如设备连不同 Broker 后消息跨节点投递、节点故障后业务持续运行、不停机完成系统升级等问题。基于这些预判，smart - mqtt 设计之初预留集群扩展能力，演化出 `cluster - plugin`，当初像面向未来的准备，这次车企真实需求让我明白，那些“暂时用不上”的设计，终会体现价值。
为模拟实际生产环境，我本地搭建环境：3 个 smart - mqtt Broker 节点、1 个 HAProxy 负载均衡实例、多个 MQTTX 客户端。整体架构如下：
MQTT Client │ ▼ SLB / HAProxy │ ┌────────┼────────┐ ▼ ▼ ▼ Broker Broker Broker ╲ │ ╱ ╲ │ ╱ cluster - plugin需说明，生产环境常用云厂商 SLB，本次用 HAProxy 仅本地模拟负载均衡。很多人初接触 MQTT 集群，以为加负载均衡、多部署 Broker 就行，实则不然。假设 Client - A 连 Broker - 1 订阅 `car/+/status`，Client - B 连 Broker - 2 发布 `car/001/status`，若 Broker 独立，Broker - 2 不知 Broker - 1 有匹配订阅，Client - A 收不到消息。所以真正可用的 MQTT 集群需连接高可用和消息高可用，HAProxy（SLB）负责客户端接入，cluster - plugin 负责跨节点消息同步，即 SLB 送客户端进来，cluster - plugin 送消息过去。
为保证实验可复现，我将 `docker - compose.yaml` 和 `haproxy.cfg` 提交到 smart - mqtt 官方仓库。用 Docker Compose 启动 3 个独立 Broker 节点，但它们还是“孤岛”。接着登录各 Broker 管理后台启用 `cluster - plugin`，因实验在 Docker 内部网络，节点通过容器名称通信。完成配置保存生效后，各 Broker 节点建立集群连接，3 个独立节点组成 MQTT 集群。
环境准备好后，我用 MQTTX 创建多个客户端连接，HAProxy 分发连接到不同 Broker 节点，系统看似正常。但真正的高可用是故障发生时仍能服务。于是我执行 `docker restart mqtt - broker - 1` 模拟 Broker 节点异常退出。几秒内，HAProxy 识别故障节点，新连接不进 Broker - 1，MQTT 客户端重连，cluster - plugin 跨节点投递消息，其他 Broker 节点服务。Broker - 1 恢复后重新加入集群，业务未因单节点故障中断。
这次验证让我确信，对企业用户，MQTT Broker 价值不只在性能指标，几万级连接对现代 Broker 不难，真正决定能否进生产环境的是面对故障的表现，如节点下线时业务是否中断、客户端能否恢复、消息能否送达，这些比“单机能支撑多少连接”更重要。
正如车企用户所说：“单机也能轻松顶住，只不过有单点故障问题。”这也是很多企业推进 MQTT 落地的问题。性能决定系统上限，高可用决定系统能否承载业务。做开源项目常如此，很多能力诞生时无明确场景，但方向正确，总会遇到需要它的人。`cluster - plugin` 对 smart - mqtt 或许就是提前准备。希望这次验证能为评估 MQTT 高可用方案的团队提供参考，真正值得信赖的系统是故障时仍可用。
如果你的团队正在评估 MQTT 技术选型，或者面临高可用、集群部署、性能优化等问题，也欢迎与我们交流。
社区资源
-官方文档：
-GitHub 仓库：
-Gitee 仓库：