MQTT Broker 负责什么？Mosquitto、EMQX 和 HiveMQ 怎么选？
MQTT Broker 是 MQTT 系统里的中枢，不只是“转发消息”的服务器。它要维护客户端连接、处理认证授权、保存订阅关系、按主题路由消息，还要根据 QoS 管理确认、重传和离线消息。选 Broker 时不能只看宣传里的百万连接，更要看你的消息量、持久化要求、集群能力、运维团队是否能长期维护。
Broker 到底做哪些事？
第一件事是连接管理。客户端通过 CONNECT 建立长连接，Broker 要校验 Client ID、账号、证书和 Keep Alive。连接建立后，它还要发现客户端是否掉线，并在异常断开时发布遗嘱消息。连接数一多，文件句柄、内存、心跳间隔都会变成真实的容量问题。
第二件事是主题路由。发布者把消息发到某个 topic，Broker 根据订阅关系找到匹配的订阅者。这里不只是字符串匹配那么简单，还涉及 +、# 通配符、共享订阅、保留消息和 ACL。主题层级设计得好，Broker 的规则就清晰；主题乱了，后面无论换什么产品都很难救。
第三件事是可靠性和存储。QoS 1 要保存未确认消息，QoS 2 要维护更完整的握手状态，持久会话还要保存离线消息。很多人压测只测 QoS 0 在线消息，结果上线后一开持久会话，磁盘和内存马上顶不住。Broker 不是数据库，离线消息要设置过期和队列上限。
常见实现里，Mosquitto 轻量、简单，适合边缘网关、实验室和小型项目。EMQX 功能完整，规则引擎、集群、管理界面都比较成熟，适合物联网平台。HiveMQ 企业能力强，商业支持好，适合预算充足、稳定性要求高的团队。RabbitMQ 的 MQTT 插件适合已有 RabbitMQ 体系的公司，但它不是专用 MQTT Broker，协议能力和超大连接场景要谨慎评估。
选型时还要把运维能力算进去。Broker 需要监控连接数、订阅数、消息速率、队列堆积、认证失败和磁盘水位，不是启动一个容器就结束。规则引擎、桥接、Webhook 看起来方便，但每增加一条链路，就多一个延迟和失败点。小团队宁可先把核心链路跑稳，也不要一开始把所有高级功能都打开。
docker run -d --name emqx -p 1883:1883 -p 18083:18083 emqx/emqx:latest mosquitto_sub -h localhost -t 'demo/#' mosquitto_pub -h localhost -t demo/test -m 'hello mqtt'
如果只是学习 MQTT，可以先用 Mosquitto，因为它足够透明，日志和配置都容易理解。如果目标是业务平台，最好尽早验证 EMQX 或 HiveMQ 这类产品的认证、规则转发、监控和集群能力。不要等设备已经铺出去以后再换 Broker，客户端协议版本、证书、主题和重连策略都会牵一发动全身。Broker 选型越靠前做，迁移成本越低。
追问
Mosquitto 和 EMQX 最大区别是什么？
Mosquitto 的优势是轻、小、部署快，几分钟就能跑起来。EMQX 更像平台型 Broker，集群、规则引擎、认证插件和监控能力更完整。取舍很直接：边缘侧或小项目用 Mosquitto 很舒服，中心平台和多租户接入更适合 EMQX。不要因为“未来可能百万连接”就一开始上复杂集群，运维复杂度也是真成本。
Broker 能不能当消息队列长期存数据？
不建议。MQTT Broker 可以保存离线消息、保留消息和 QoS 状态，但它的目标是实时分发，不是长期存储和复杂查询。历史数据应该落到时序数据库、对象存储或业务数据库里。踩坑点是离线设备太多时消息堆积，如果没有过期时间和队列上限，Broker 会被自己的可靠性功能拖垮。
集群部署时最难的地方是什么？
难点不是把多个节点启动起来，而是会话、订阅关系和消息路由如何在节点间同步。共享订阅、持久会话、QoS 1/2 都会让集群状态变重。边界是网络分区：节点之间一旦抖动，客户端可能重连到不同节点，重复投递和短暂不可达都要在业务侧兜底。实际项目要压测故障切换，而不是只压测正常吞吐。
选 Broker 时要看哪些指标？
至少看四个指标：并发连接数、每秒消息数、QoS 级别、消息大小。还要看认证方式、ACL 复杂度、持久化策略和监控告警能力。只报“百万连接”没有意义，因为一百万空闲连接和十万高频上报连接完全不是一个负载。选型时最好用自己的主题结构和真实 payload 做压测。
RabbitMQ 插件适合 MQTT 场景吗？
如果公司已经大量使用 RabbitMQ，只需要少量设备接入 MQTT，它可以降低系统数量。问题是 RabbitMQ 的核心模型不是为海量 MQTT 长连接设计的，通配符、会话、共享订阅等能力也要逐项确认。高并发设备接入、复杂 ACL 和物联网规则处理更适合专用 Broker。这里的取舍是复用现有基础设施，还是为 MQTT 场景单独建设更合适的接入层。