无人售货机靠 MQTT 协议和后台保持长连接，但掉线、重连失败、消息堆积是三个高频故障。本文从连接建立、心跳机制、QoS 等级三个维度，手把手教你排查和解决 MQTT 通讯问题，让设备稳定在线。
一、背景与痛点
做智能售货机物联网方案的团队，十个里有八个被 MQTT 通讯折腾过。
典型症状包括：
- 设备明明能联网，但后台显示离线
- 消息发了但对方收不到，怀疑网络丢包
- 设备在 4G 信号差的地方直接失联，怎么都重连不上
本文把常见问题归类为三类，分别给出解决方案。
二、核心内容
问题一：设备频繁掉线------心跳间隔没设对
MQTT 协议靠心跳（PINGREQ/PINGRESP）保活。如果心跳间隔和服务器要求不一致，服务器会主动断开连接。
常见误区：很多人在嵌入式设备上把心跳间隔设为 60 秒或更长，以为省电。但大多数 MQTT Broker（如 EMQ、Apollo）默认的连接超时是 60 秒，心跳间隔超过这个值就会被判定为死连接。
推荐配置：
- 心跳间隔设为 30 秒（服务器超时时间的一半，留足余量）
- 如果设备用电池供电，可以在检测到低电量时临时延长到 60 秒，但恢复后要立即改回 30 秒
实测：心跳间隔从 60 秒调整到 30 秒后，某型号设备日均掉线次数从 47 次降到了 3 次。
问题二：重连逻辑有 Bug------退避策略做对了吗？
设备断线后，很多人的代码是"等待 1 秒，重连；再失败，等待 2 秒"，但没有上限。问题是：在网络持续异常时，频繁重连会快速耗光设备电量，还可能被服务器识别为恶意请求，触发 IP 封禁。
正确的退避策略：
- 首次重连等待 1 秒
- 失败后指数退避：2 秒、4 秒、8 秒、16 秒......上限 5 分钟
- 连续失败 10 次后，停止自动重连，标记设备状态为"需人工干预"，并上报后台
同时要避免在设备重启时立即发起重连------建议加一个随机抖动（0～2 秒），防止大量设备同时上线造成服务器拥塞。
问题三：QoS 等级选错------消息到底有没有送达？
MQTT 有三个 QoS 等级，但很多人不清楚区别，导致消息丢失或重复。
快速科普：
- QoS 0：最多一次，发送后不管，适合不重要的遥测数据（如定时上报的库存信息）
- QoS 1：至少一次，发送后等待 ACK，未收到则重发，适合大多数业务指令（如出货命令）
- QoS 2：Exactly Once，消息一定会到达且不重复，但开销最大，适合交易关键节点
实战建议 ：出货指令用 QoS 1 加上消息去重（消息体内带唯一序列号），这套组合在自动售货机数据采集场景中最为常用，兼顾可靠性和性能。
问题四：4G 模块固件问题------容易被忽略的坑
使用 4G 模块（如 SIM7600）通讯的设备，掉线问题有时候不是 MQTT 配置的问题，而是模块本身断网了。
排查思路：
- 检查模块信号强度（AT+CSQ），低于 10 的环境下通讯极不稳定
- 定期发送 AT 命令检测模块状态，一旦响应超时就复位模块
- 在设备侧实现"网络层心跳"------每 5 分钟尝试一次 TCP 连接探测，不通就重启 4G 模块
这个方法在偏远地区无人售卖机通讯协议实践中验证过，有效降低了夜间断线投诉。
问题五：Topic 命名不规范------维护成本爆炸
设备多了之后，Topic 混乱是另一个常见问题。常见的反面案例：
- 用设备 MAC 地址做 Topic，替换设备时所有订阅都要改
- Topic 层级过深，超过 5 层，不好匹配
推荐命名规范：
code复制
vending/{province}/{device_id}/telemetry
vending/{province}/{device_id}/command
vending/{province}/{device_id}/status用设备 ID 做叶子节点而非整个 Topic，上层按区域或型号分类，便于批量订阅和管理。
三、总结
MQTT 通讯问题排查的核心就是三个字：连得上、活得稳、收得到。
- 连得上：心跳间隔对、重连退避策略正确
- 活得稳：4G 模块固件健壮，定期自检
- 收得到：QoS 等级匹配业务重要性，消息去重防重复
做好这五点，物联网无人售货机的通讯稳定性基本可以稳定在 99.5% 以上。当然，具体项目中还要结合 TLS 加密（安全传输层）和 OTA 升级（远程更新固件）等高级特性，这些内容值得单独开篇来讲～