11 MQTT：从连接到消息¶

难度：入门到中级｜前置：网络、MQ｜目标：理解 MQTT 的核心机制与业务边界

为什么 IoT 常用 MQTT¶

设备通常存在：

网络不稳定；
带宽和功耗有限；
需要长连接；
设备与多个业务服务解耦；
服务需要向设备主动下发。

MQTT 使用发布/订阅模型：

设备 Publisher
   → Topic
   → Broker
   → Subscriber 业务服务

设备与业务服务不直接知道彼此地址，Broker 负责连接与路由。

Topic 设计¶

示例：

tenant/{tenant_id}/device/{device_id}/telemetry
tenant/{tenant_id}/device/{device_id}/event
tenant/{tenant_id}/device/{device_id}/command
tenant/{tenant_id}/device/{device_id}/reply

设计时考虑：

方向是否明确；
租户和设备边界；
是否需要通配订阅；
Topic 中是否泄露敏感信息；
权限能否按 Topic 控制；
未来版本如何兼容。

QoS¶

QoS	协议语义	业务影响
0	最多一次	快，可能丢
1	至少一次	可能重复，业务需幂等
2	协议层恰好一次	开销更高，仍不替代业务幂等

QoS 1 收到重复消息是正常行为，不是 Broker Bug。消息 ID 和业务幂等仍然必要。

Session¶

Session 保存订阅和未完成的 QoS 流程，使客户端断线后可以继续。它与 TCP 连接不是同一个概念：

连接断开；
Session 可以继续保留；
客户端重连后恢复。

MQTT 5 使用 Clean Start 与 Session Expiry Interval 更明确地控制会话生命周期。

Retained Message¶

Broker 为一个 Topic 保存最后一条保留消息。新订阅者会立刻收到它。

适合：

最新配置；
当前期望状态；
最新公告。

不适合：

完整历史；
高频遥测全量存储；
需要严格事务的业务事实。

Will Message¶

设备连接时预先设置遗嘱；设备异常断开时由 Broker 发布。

遗嘱可以作为离线信号，但不应成为唯一事实：

网络抖动可能触发；
正常断开通常不发布；
Broker 或集群故障会影响事件；
业务仍需超时和重连校验。

Keep Alive 和业务心跳¶

MQTT Keep Alive 主要帮助 Broker 判断连接是否活跃；业务心跳可以携带设备时间、固件、网络和运行状态。两者可以结合，但语义不同。

自测¶

QoS 1 为什么仍要求业务幂等？
Session 和 TCP 连接有什么区别？
Retained Message 为什么不能当历史数据库？
Will Message 为什么不能单独决定最终离线状态？

完成标准¶

能画出 Publisher、Topic、Broker、Subscriber
能解释 QoS 0/1/2 的业务取舍
能区分 Session、Retain、Will 和 Keep Alive
完成 MQTT 可靠性实验

延伸阅读：MQTT 5.0 标准、EMQX MQTT 核心概念

下一单元：设备身份与接入