评论区有位兄弟说他在工业园区用MQTT，每个网关连100个设备左右，跑了一年半了。

这是个好案例。但我也见过很多MQTT项目一上量就崩——几千个设备同时在线，Broker就扛不住了。

为什么有的项目100个网关稳稳当当，有的项目几千个设备就崩了？

第一个坑：Broker选型不对。

MQTT Broker有好几种——Mosquitto、EMQX、HiveMQ、VerneMQ、NanoMQ。

Mosquitto是最轻量的，适合小规模部署。单机支持几千个连接没问题。但它的集群能力很弱，做高可用比较麻烦。

EMQX是国内用得最多的，单集群可以支撑千万级连接。功能全、文档好、社区活跃。但如果配置不当，性能会打折扣。

HiveMQ是商业版的，性能好、支持完善，但收费。

VerneMQ是开源的，支持集群，但配置复杂。

NanoMQ是边缘侧的Broker，适合在网关上跑，不适合做中心Broker。

工业园区那个项目为什么稳？ 100个网关，每个网关连100个设备——但对MQTT Broker来说，它承载的连接数不是10000个设备，而是100个网关。因为设备是连到网关的，网关再连到Broker。

连接数少了一个数量级，Broker的压力自然小。

第二个坑：QoS等级设太高。

MQTT有三种QoS等级：

QoS 0：最多送达一次。发了就不管，不保证送达。

QoS 1：至少送达一次。保证送达，但可能重复。

QoS 2：恰好送达一次。保证送达且不重复，但握手次数最多。

很多人觉得“QoS越高越好”，全部设成QoS 2。

QoS 2的代价是什么？ 每条消息要经过四次握手（PUBLISH → PUBREC → PUBREL → PUBCOMP）。如果每秒有1000条消息，QoS 2的握手次数就是4000次。Broker的CPU和网络开销翻了几倍。

我的建议： 数据采集用QoS 0，重要告警用QoS 1，计费相关用QoS 2。大部分场景QoS 0和QoS 1就够了。

第三个坑：主题设计不合理。

MQTT的主题设计直接影响Broker的性能。

有人用这样的主题：device/+/data——所有设备的数据都发到这个主题下，用通配符订阅。

如果只有一个订阅者，没问题。如果有10个订阅者都用通配符订阅，每条消息都要被复制10份，分别推送给10个订阅者。

消息复制是Broker最大的开销之一。

合理的做法是：按业务分主题。factory1/line1/device1/data、factory1/line2/device2/data——订阅者只订阅自己关心的主题，不需要的就不订阅。

第四个坑：连接数规划不足。

每个MQTT连接都会占用Broker的内存和文件描述符。一个空闲的连接占几KB，一个活跃的连接占几十KB甚至更多。

如果你的Broker配置是1万连接，但实际有1.5万设备要连——多出来的设备就连不上。

规划连接数的时候，要留余量。 实际设备数量乘以1.5，作为Broker的配置上限。

第五个坑：没有做连接保活。

设备掉线了，Broker不知道。这个连接一直占着内存和文件描述符，直到TCP超时。

MQTT有Keep Alive机制——设备定期发PING，Broker收到PING就知道设备还在线。如果超过Keep Alive时间没收到PING，Broker就断开连接。

Keep Alive设多少？ 太短了，设备频繁发PING浪费带宽；太长了，掉线设备不能及时清理。一般设30秒到60秒。

一张表总结：

坑 症状 解决方案 Broker选型不对 小规模没问题，一上量就崩 根据规模选Broker（小规模Mosquitto，大规模EMQX） QoS设太高 CPU占用高、带宽消耗大 按场景选QoS（采集QoS 0，告警QoS 1） 主题设计不合理 Broker消息复制开销大 按业务分主题，避免通配符订阅 连接数规划不足 设备连不上 实际设备数×1.5作为配置上限 没做连接保活 掉线设备占用资源 设置合理的Keep Alive时间 如果你的MQTT项目也有“一上量就崩”的问题，先按这个顺序查一遍。

平时我也写写代码，维护两个开源项目：

ProtoForge（工业协议仿真平台，28种协议，130+设备模板）： GitHub：suoten/ProtoForge Gitee：suoten/ProtoForge

EdgeLiteGateway（AI物联网关，13种协议采集，边缘AI推理）： GitHub：suoten/EdgeLiteGateway Gitee：suoten/EdgeLiteGateway