MQTT在服务端与数千客户端实时通信场景是否高效？如何解决订阅扩容问题

一、海量客户端实时通信场景选择MQTT是合理的 #

MQTT是专为海量设备长连接、双向低延迟通信场景设计的轻量级协议，原生支持QoS分级、遗嘱消息、离线消息推送等特性，相比AMQP更适配数千台甚至更多客户端的实时通信需求。你遇到的重复消费问题并非MQTT本身的缺陷，属于订阅模式使用不当导致的可解决问题。

二、重复消费扩容问题的解决方案 #

• 方案1：使用MQTT 5.0标准的共享订阅特性（最优解）
  共享订阅是MQTT 5.0正式纳入的标准能力，专门解决多订阅者负载均衡的问题，使用格式为$share/<订阅组名>/<原始业务Topic>。同一个订阅组内的多个订阅者，只会有一个实例收到同一条消息，和AMQP的队列消费逻辑完全一致。
  举例：你原来后端订阅的Topic为client/+/up，调整为$share/backend_consume_group/client/+/up即可。所有后端实例都订阅该共享Topic，扩容时直接新增实例加入该订阅组即可，消息会自动负载均衡分发，不会出现重复消费的问题。
  目前主流MQTT Broker（EMQX、VerneMQ、Mosquitto 2.0+）均已原生支持该特性，无需修改客户端侧代码，仅调整后端订阅的Topic格式即可落地。

• 方案2：适配低版本Broker的中转方案
  如果你使用的Broker不支持MQTT 5.0，可以新增一层消息中转层：先由统一的中转服务订阅所有客户端上行Topic，再将消息写入AMQP队列，后端服务从AMQP队列消费消息，天然实现负载均衡无重复消费。该方案额外增加了一层转发链路，延迟略高于共享订阅方案，仅适合无法升级Broker的存量场景。

• 优化建议：
  可以根据业务维度、客户端区域维度拆分Topic，配合共享订阅实现分组消费，进一步提升消费吞吐量。如果需要保证同一个客户端的消息按顺序投递到同一个后端实例，可以在Broker侧配置共享订阅的负载策略为按客户端ID哈希分发即可。

内容的提问来源于stack exchange，提问作者George p