MQTT 在 IoT 业务里的可靠性取舍

在智能货柜、陪伴硬件这类场景，MQTT 是设备与云之间的神经。选错 QoS 或忽略幂等，线上会表现为偶发「指令丢失」——日志里 broker 显示已投递，业务侧却没有任何执行记录。我的做法是：先画清楚「消息到达」和「业务完成」两条线，再决定 QoS 和会话策略。

QoS 不是银弹

• QoS 0：适合高频遥测，丢一两个采样可接受
• QoS 1：开柜、OTA、配置下发优先，至少达一次
• QoS 2：成本高，多数业务用「QoS1 + 业务去重」更划算

指令类 topic 与遥测类 topic 分开命名，避免高吞吐遥测挤占 broker 资源，拖慢关键指令。

订阅与发布规范

• 下行指令：device/{id}/cmd/{action}，payload 含 commandId、版本、过期时间
• 上行回执：device/{id}/ack/{action}，必须回传同一 commandId
• 禁止在 payload 里塞超大 blob，OTA 包走 HTTP 下载，MQTT 只传 manifest

会话与遗嘱

设备异常掉线时，遗嘱消息（LWT）可以把在线状态打成离线，运维看板立刻可见。清洁会话要按设备类型选择：需要离线补消息的，保留会话；纯遥测设备可清洁会话减负。

连接参数建议固化进设备配置：keepalive、重连退避上限、最大 inflight 数量。弱网环境下频繁重连会放大「重复投递」问题，和业务幂等必须一起设计。

业务层仍要幂等

MQTT 保证的是消息投递语义，不保证业务只执行一次。开柜、改配置、触发 OTA 都必须带 commandId，设备与云都做去重表，过期条目定期清理。

云端收到回执后，先写「指令已完成」流水，再驱动状态机迁移——顺序反了，就会出现「状态已变但指令可重放」的漏洞。

Broker 与网络现实

生产环境我会把 EMQX / Mosquitto 的集群、持久化与 ACL 写进部署文档：哪些 clientId 只能订阅自己的 topic，哪些服务账号只能发布下行。TLS 证书轮换要提前通知设备端支持双证过渡，否则大规模离线比业务故障更难收拾。内网 broker 也要限流，防止错误代码里的 publish 循环把 broker 打满。

和设备固件对齐

固件升级时，MQTT 行为变更（topic 改名、payload 增字段）必须向后兼容至少一个版本。我会在联调清单里要求：旧固件收到新字段仍能忽略，新固件收到旧指令仍能执行或明确报错。否则 OTA 一半设备新一半旧，云端逻辑无法写。

弱网场景下，设备侧应缓存未确认的下发指令，重连后主动请求「待执行列表」，而不是假设 broker 会一直替它留着。云端则以数据库流水为准做补偿下发，双保险才扛得住现场网络质量。

排障与检查清单

• [ ] 任意 commandId 可在云端查到：下发、回执、业务结果
• [ ] 重复 QoS1 投递不会重复开柜或重复扣费
• [ ] Broker 磁盘与连接数有监控告警
• [ ] 遗嘱离线与服务端心跳超时策略一致，避免「双离线/双在线」
• [ ] 压测时区分遥测 flood 与指令延迟

把「消息到达」和「业务完成」拆开看，IoT 系统会好懂很多。MQTT 选型只是第一层，真正决定口碑的是指令可追溯、可重放、可对账。

联调阶段建议维护一张「topic 对照表」和「错误码对照表」，设备、后端、运维共用。排障时先查 commandId 流水，再查 broker 日志，能避免团队在 QoS 与业务逻辑之间互相甩锅。

若你同时运营货柜与陪伴硬件两类设备，不要共用同一套 topic 命名空间。混用后 ACL 难写、误订阅风险高，后期拆分成本更大。从一开始就按产品线前缀隔离，运维会轻松很多。

小结

MQTT 提供投递语义，业务完成仍靠幂等与状态机。按消息类型选 QoS，用遗嘱与会话策略暴露离线，再配合指令 ID 去重，设备系统才会可追踪。把源健康度与积压长度看在看板上，比出事后翻设备日志快得多。