物联网消息可靠性：送达与入账的两道边界

物联网计量平台收到确认报文后，仍可能漏记或重记一笔用量。问题在于网络交付与业务入账分属不同状态机。要判断可靠性，必须分别检查协议确认覆盖到哪里，以及消费端如何关闭重复处理的窗口。

先看消息经过的边界。设备向代理发布数据、代理再向订阅端转发，是两段交付过程，各自维护报文标识与确认状态。发布端收到确认，只能据此判断对应协议步骤完成，不能推出订阅程序已经提交数据库。订阅使用的服务质量还受请求等级与授权等级等条件限制，不能拿设备上行的配置代替整条链路的配置。现场应分别记录发布确认、代理转发和业务提交，以定位数据停在哪个责任边界。

服务质量为一级时，确认丢失可能引发重传，因此消费程序必须接受重复到达。二级通过额外交互约束协议消息的重复交付，但它并不与外部数据库组成一个事务。如果消费程序在写库后崩溃，而上游仍把该业务任务视作未完成，恢复逻辑依然可能再次提交相同内容。另一方面，协议报文标识会在交互完成后复用，不能拿它作为永久账目编号。设计时应为一条真实测量生成稳定业务标识，并在应用重新发布、转发转换时保持这个标识不变。

选择服务等级也要考虑代价。增加确认轮次会占用往返时间和在途状态，频繁短连接的终端更容易让交互成本超过载荷本身。允许少量样本缺失的连续趋势数据，与不可重复计费的脉冲累计值，可以采用不同交付策略。验收应注入确认报文丢失、代理重启和订阅端停机三类故障，分别观察重传与恢复结果；仅在稳定网络里统计接收率，无法证明异常时的协议状态能够正确收敛，更不能证明账目没有被重复修改。

入账端需要解决另一道窗口：去重标记与账目更新必须共同成功，或者共同失败。若先记录已处理再写账，进程在中间退出会造成永久漏记；若先写账再登记标记，重试又可能重复计费。对于同一事务数据库，可把业务标识的唯一约束、计量记录和累计值修改放入一个事务。并发消费时由数据库裁决相同标识的竞争，不能依赖两个进程各查一次缓存，因为二者可能同时看到不存在，再各自写入一笔。

业务标识还应限定命名空间。单用设备内的递增序号，在换板或恢复出厂后可能碰撞；可以组合可信设备身份、持久化启动代号与采集序号，并明确代号更新规则。物联网平台若跨越消息队列和数据库，通常难以直接建立单一事务，可先把待处理项持久化，再由可重试任务完成入账。若后续还要发送通知，应将待发事件与账目共同落库，然后独立投递。这样做并未消除重复，而是让重复到达不再改变已经完成的业务结果。

去重保留期不能凭缓存容量随意设置，它至少应覆盖允许的补传、重试和历史回放范围。过早删除标记后，一条延迟数日的旧记录仍可能再次产生账目影响；永久保留则会增加索引维护成本。可以按业务周期归档标识，但回放任务必须同时识别归档边界。对于调用外部结算接口的流程，还需传递相同的幂等请求号，并核对接口是否承诺在所需时间内保存结果。只有本地事务成功，而远端请求缺少稳定身份，仍不能保证最终结果只发生一次。

可靠交付需要两份独立证据：协议状态完成，业务结果可重试且不重复改变。把确认边界和事务边界分别验收，才能判断一条计量记录究竟只是到达，还是已经可靠入账。