📚 课程目录第3章 MQTT协议深度解析

3. MQTT协议深度解析

MQTT 是 IoT 云平台最常用的接入协议之一，它的核心价值在于用极轻量的报文把海量设备与云端解耦。理解 MQTT，不能只记“发布/订阅”四个字，而要同时看清四件事：消息如何经 Broker 转发、QoS 如何决定可靠性、保留消息与遗嘱消息如何补足“最后状态”和“异常离线”语义、主题如何设计才能既安全又可扩展。

一、发布/订阅模型：解耦的关键在 Broker

在 MQTT 中，设备不直接互相连接。发布者（Publisher）把消息发往 Broker，订阅者（Subscriber）向 Broker 订阅感兴趣的主题过滤器（Topic Filter），由 Broker 完成匹配与转发。发布者与订阅者彼此不知道对方地址、数量甚至是否存在，这就是空间解耦；双方也无需同时在线，这是时间解耦。

一次典型链路是：温度设备向 iot/plant1/lineA/dev001/telemetry 发布一条 JSON 数据，Broker 收到后查找所有匹配该主题的订阅，例如规则引擎订阅了 iot/plant1/+/+/telemetry，监控服务订阅了 iot/plant1/#，于是同一条消息被分别投递给它们。发布者只发一次，Broker 负责扇出。

主题匹配支持两种通配符：+ 匹配单层，# 匹配多层且只能出现在末尾。例如 iot/plant1/+/dev001/telemetry 能匹配 iot/plant1/lineA/dev001/telemetry，但不能匹配 iot/plant1/lineA/sub/dev001/telemetry；而 iot/plant1/# 可以匹配其下所有层级。注意：通配符只能用于订阅，不能用于发布。

二、QoS 等级：可靠性、开销与幂等的权衡

QoS 决定消息投递保证，而不是“消息一定成功”。QoS 0 为“至多一次”，发布后不等待确认，适合高频、可容忍丢失的遥测，如每秒上报的温湿度。QoS 1 为“至少一次”，发布者收到 PUBACK 才认为完成，但网络抖动可能导致重复，业务侧必须做幂等处理。QoS 2 为“恰好一次”，通过 PUBREC/PUBREL/PUBCOMP 四次握手实现，开销最大，适合计费、开关指令等不能重复执行的场景。

需要特别记住：最终投递 QoS 等于发布 QoS 与订阅 QoS 的较小值。若设备以 QoS 2 发布，而订阅端只声明 QoS 1，Broker 会按 QoS 1 投递。因此设计时要同时约束两端，不能只改发布侧。

三、保留消息与遗嘱消息：补足状态与异常语义

保留消息（Retained Message）让 Broker 为某个主题保存最后一条消息。新订阅者一旦订阅该主题，会立即收到这条保留消息，而不必等待下一次发布。典型用法是设备在线状态：设备上线后向 iot/plant1/lineA/dev001/status 发布 retained 消息 {"online":true}，任何新接入的监控端都能立刻知道当前状态。注意：向同一主题发布空载荷 retained 消息可清除保留消息。

遗嘱消息（Will Message）在客户端异常断开时由 Broker 代为发布。连接时通过 CONNECT 报文携带 Will Topic、Will Payload、Will QoS 和 Will Retain。例如设备连接时声明遗嘱主题 iot/plant1/lineA/dev001/status、载荷 {"online":false,"reason":"unexpected"}、QoS 1、retain=true。当设备掉电或网络中断且未正常发送 DISCONNECT 时，Broker 立即发布该遗嘱，监控端即可判定设备离线。若设备正常断开，遗嘱不会触发。

保留消息解决“新订阅者看不到历史状态”，遗嘱消息解决“设备异常离线无人知晓”，两者常配合在线状态主题一起使用。

四、主题设计规范：可读、可扩展、可授权

主题是 MQTT 的“地址系统”，设计质量直接影响权限控制、规则引擎匹配和后期扩展。推荐采用分层语义：{业务域}/{区域}/{产线}/{设备ID}/{消息类型}。例如：

iot/plant1/lineA/dev001/telemetry   # 遥测数据
iot/plant1/lineA/dev001/status      # 在线状态（retained）
iot/plant1/lineA/dev001/cmd         # 下行指令
iot/plant1/lineA/dev001/cmd/ack     # 指令回执

设计时遵循几条硬规则：第一，主题区分大小写，统一用小写，避免 Telemetry 与 telemetry 被当成两个主题。第二，不要以 / 开头或结尾，/iot/plant1 与 iot/plant1/ 会产生空层级，导致匹配混乱。第三，设备 ID 放在固定层级，便于用 + 做单设备订阅、用 # 做批量订阅。第四，不要把敏感信息写进主题，主题在 Broker 日志和 ACL 中可见。第五，为指令与回执使用不同后缀，避免请求与响应混在同一主题。

权限控制通常基于主题前缀：设备只允许发布 iot/plant1/lineA/dev001/telemetry 和 .../status，只允许订阅 .../cmd；云端服务可订阅 iot/plant1/#。这样即使设备凭证泄露，影响范围也被限制在自身主题内。

五、一个可落地的配置示例

下面给出设备端连接参数示例（以常见客户端库参数形式表达，数值为示例假设）：

clientId:   dev001-plant1-lineA
keepAlive:  60            # 秒
cleanSession: false       # 保留会话，离线期间 QoS1 消息可缓存
willTopic:  iot/plant1/lineA/dev001/status
willPayload: {"online":false,"reason":"unexpected"}
willQos:    1
willRetain: true
publish:    iot/plant1/lineA/dev001/telemetry  QoS1
subscribe:  iot/plant1/lineA/dev001/cmd        QoS1

验证时可按以下顺序观察：设备上线后向 status 发布 retained 在线消息；用第二个客户端订阅 status，应立即收到在线状态；断开设备电源，等待 keepAlive 超时后，订阅端应收到遗嘱离线消息；恢复供电后再次收到在线消息。若订阅端未收到遗嘱，优先检查是否使用了 cleanSession、遗嘱是否在 CONNECT 中正确声明，以及 Broker 是否因正常 DISCONNECT 而未触发遗嘱。

QoS 1 的重复投递是协议允许行为，不是 Broker 故障。指令类消息务必在业务层用 msgId 或幂等键去重，否则可能出现重复开关、重复扣费等后果。

把发布/订阅模型、QoS、保留消息、遗嘱消息和主题规范放在一起看，MQTT 的设计逻辑就清晰了：Broker 负责解耦与转发，QoS 负责可靠性分级，保留消息负责状态快照，遗嘱消息负责异常通知，主题规范负责可管理性。五者配合，才能支撑起稳定、可扩展的 IoT 云平台消息底座。