MQTT 基础--保留消息：第 8 部分

一、核心概念：什么是 MQTT 保留消息？

保留消息是 保留标志（Retain Flag）设为 true 的普通 MQTT 消息，由 MQTT 代理（Broker）负责存储 —— 每个主题仅保留最后一条符合条件的保留消息及对应的 QoS 等级。

其核心价值在于：新订阅该主题（或主题通配符匹配）的客户端，订阅后会立即收到这条 “最后已知的有效状态”，无需等待发布端发送下一条更新。

关键特性说明：

1. 与通配符兼容：若订阅时使用通配符（如 myhome/#），即使保留消息的主题（如 myhome/livingroom/temperature）不完全匹配，也能触发消息推送。
2. 与持久会话无关：保留消息的存储由代理独立管理，不受客户端会话是否持久的影响。
3. “最后有效” 而非 “最后发送”：保留消息是 “保留标志为 true” 的最后一条消息，不一定是该主题的最后一条普通消息。

二、实操指南：发送与删除保留消息

1. 发送保留消息

开发视角下实现简单，核心步骤仅 1 步：

• 在调用 MQTT 发布接口时，将 保留标志（Retain Flag）设置为 true。
• 几乎所有主流 MQTT 客户端库（如 Paho、EMQ X Client）都提供了简洁的配置方式（例：publish(topic, payload, qos=1, retain=True)）。

2. 删除保留消息

两种常用方式，按需选择：

删除方式	操作步骤	适用场景
覆盖删除	向目标主题发布一条 新的保留消息	需更新主题 “最后有效状态” 时（新保留消息会自动覆盖旧消息）
清空删除	向目标主题发布一条 保留标志为 true、有效负载为 0 字节 的消息	需彻底移除该主题保留消息（新订阅者不再接收）

三、应用场景：为什么需要保留消息？

保留消息的核心作用是 “消除新订阅者的信息延迟”，尤其适用于以下场景：

1. 设备状态同步：如 myhome/devices/device1/status 主题存储设备在线 / 离线状态，新订阅者可立即获取设备当前状态，无需等待设备下次上报。
2. 周期性数据补全：温度、湿度、GPS 坐标等周期性上报的数据，新订阅者无需等待下一个上报周期，即可获取最新读数。
3. 系统初始化配置：设备接入时需加载的初始化参数（如服务器地址、工作模式），通过保留消息可让新设备快速获取配置。

反例场景（不建议使用）：

• 实时性要求极高的指令（如设备控制指令）：保留消息是 “历史最后状态”，无法替代实时推送。
• 一次性通知（如告警弹窗）：这类消息无需长期存储，且新订阅者无需追溯历史通知。

四、典型示例：通配符订阅与保留消息触发

场景描述：

1. 客户端 A 向主题 myhome/livingroom/temperature 发布一条保留消息（内容：25℃，保留标志 = true）；
2. 后续客户端 B 订阅主题 myhome/#（通配符 # 匹配 myhome 下所有子主题）；
3. 客户端 B 订阅成功后，立即收到客户端 A 发布的温度保留消息，且消息中保留标志仍为 true，便于客户端识别处理。

五、常见误区提醒

1. 混淆 “保留消息” 与 “持久会话”：两者无关联 —— 持久会话是为了恢复客户端断开前的订阅关系，保留消息是为了给新订阅者提供历史状态。
2. 过度使用保留消息：非状态类、非周期性数据无需设置保留标志，避免代理存储冗余数据。
3. 忘记处理保留标志：订阅端需通过保留标志区分 “实时消息” 和 “保留消息”，避免误将历史状态当作实时数据处理。