设备使用较高 QoS 后，业务仍可能重复处理。协议确认覆盖的是消息传递阶段，应用的数据库写入和执行结果还需要自己的身份与确认机制。
QoS 0、1、2 表达不同交付语义，QoS 1 可出现重复；QoS 2 的协议去重范围也不是跨系统业务事务。应用重连、消息再发布或处理回执丢失仍可能触发新的业务动作。
一、问题的范围与前提
消息传输、业务处理与设备执行具有不同完成条件。消息系统可以提供队列和协议确认，但不会自动把数据库写入与物理动作合成一个事务。事件身份、对象版本与会话范围需要由应用定义，尤其在重复、乱序和断网补传时。
二、技术分析与方案取舍
QoS 描述的是 MQTT 连接和会话中的协议传递，业务代码可能在确认之前或之后失败。例如消息收到并提交数据库后，程序还没写应用回执就退出，重新处理可能再次写入。稳定事件身份与唯一约束让这类重放可恢复。对于命令，还需记录设备受理和完成状态，不把 broker 收到消息直接显示为设备已动作。
先区分状态、事件和命令，再选择传输语义与保留方式。发送端持久保存重要意图，接收端用稳定业务键管理去重与结果。队列领取与回收需要并发约束，超时与退避有整体预算，避免持续失败把下游压力无限放大。
三、实现与排查的顺序
- 明确消息所需交付语义。
- 保存稳定事件 ID。
- 让业务写入具备唯一约束。
- 区分传输确认与处理结果。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
4
telemetry/<device>/measurements
state/<device>/current
event/<device>/alarms
command/<device>/requests
主题是通用命名示意，device 为占位。状态、事件与命令分别管理保留、去重与权限。实际 ACL 与消息字段需要一起验证，主题名称本身不提供安全隔离。
四、验证和结果解释
记录消息来源、序号、采集时间、接收时间和处理状态，有助于判断旧消息、重复消息与新事件。次数本身不能解释进展，应看一段时间内领取、失败、下一次执行和确认是否连贯。关键任务等待时间也比 worker 存活更能说明调度质量。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 重复消息不重复入库 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 重启后仍保留已处理身份 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 离线补传与实时消息的处理规则一致 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
故障测试包括发送后断线、受理后丢回执、处理中崩溃和重连乱序。系统应能明确查询、回收或拒绝，不能把网络未知结果一律当作失败重发。保留消息不替代历史库，高 QoS 也不自动提供跨系统业务只执行一次。
五、适用边界与结论
不能为了宣称只执行一次忽略断电与重连。执行器还应管理任务归属和完成回执，避免把 MQTT 确认当成机械动作完成。
这条路径把“明确消息所需交付语义”与“区分传输确认与处理结果”连在一起，中间保留可复查的条件。实施时优先确认“重复消息不重复入库”，再检查“离线补传与实时消息的处理规则一致”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
