边缘采集数据可靠上报：缓存、重试、幂等与状态追踪

现场设备接入云平台后，真正困难的通常不是完成一次接口调用，而是在网络波动、进程重启、平台超时等情况下，仍然保证数据可追踪、可恢复且不重复。

本文从工程实现角度拆解一条边缘数据可靠上报链路，重点讨论本地持久化、发送确认、失败重试、幂等处理和业务时限。文中的设备与数据截图仅用于说明技术场景，具体实现应以设备通信协议和接收平台接口文档为准。

1. 为什么“读取后立即发送”并不可靠？

最简单的数据采集程序通常采用以下顺序：

读取设备数据 → 调用平台接口 → 等待返回结果

这种方式在网络稳定时可以运行，但存在几个明显风险：

• 数据只保存在进程内存中，程序退出后无法恢复；
• 网络请求超时，但平台实际上可能已经收到数据；
• 持续快速重试造成重复提交或接口压力；
• 设备仍在产生新数据，失败记录却没有独立队列；
• 无法回答“哪一条失败、失败多少次、最后是否成功”。

因此，发送动作不应该直接决定原始数据是否保留。

2. 更可靠的基本顺序

一条可恢复的数据链路可以拆成：

1. 从设备读取数据；
2. 为记录生成可追踪标识；
3. 写入本地缓存队列或文件；
4. 尝试向平台发送；
5. 平台明确确认成功后更新发送状态；
6. 失败时保留原记录，等待下一次调度。

这套顺序的核心是“先持久化，再发送”。即使程序重启或网络中断，待发送记录仍能重新加载。

3. 网关侧状态流

可靠上报不应只有“成功”和“失败”两个瞬时结果，而应形成可查询的状态变化。

常用状态可以包括：

• pending：已经持久化，尚未发送；
• sending：正在请求平台；
• confirmed：平台明确确认成功；
• retry_wait：发送失败，等待重试；
• manual_check：连续失败或字段异常，需要人工检查。

状态名称可以调整，但必须能够区分“没有发送”“正在发送”“平台已确认”和“需要重试”。

4. 超时为什么容易产生重复数据？

一次HTTP请求超时，并不能证明平台没有收到数据。可能出现以下情况：

1. 平台已经写入数据；
2. 返回响应时网络中断；
3. 边缘端认为发送失败；
4. 网络恢复后再次提交相同记录。

解决这一问题通常需要幂等设计。边缘端为业务记录提供稳定的唯一标识，平台收到重复标识时返回已有处理结果，而不是再次创建记录。

唯一标识如何组成，应根据实际业务字段确定。例如项目、设备、施工对象、工序批次和记录时间都可能参与，但不能脱离接口约定自行固定格式。

5. 重试策略不能只有固定间隔

不同错误需要不同处理：

如果所有错误都无限快速重试，容易形成重试风暴，并掩盖真正的数据格式问题。

6. HTTP与MQTT关注点不同

使用HTTP时，需要明确请求方法、鉴权方式、字段格式、超时时间、成功返回码及幂等规则。

使用MQTT时，需要明确Broker、Topic、QoS、会话策略、消息格式和平台确认方式。

设备到网关的读取协议与网关到平台的上行协议是两段不同链路。例如Modbus解决设备数据如何读取，HTTP或MQTT解决数据如何向平台发送，不应混为一谈。

7. 断网续传仍受业务时限约束

本地缓存和断网续传解决的是技术可恢复性，但不能自动满足业务实时性。

如果接收平台要求施工过程中逐条上报，即使网络恢复后能够补传，也可能已经超过业务允许时限。因此实施前必须确认：

• 上传时限是多少；
• 是否允许补传；
• 补传数据是否需要额外标记；
• 平台如何判断迟到数据；
• 联调阶段如何模拟网络中断。

8. 平台侧应保存哪些追溯信息？

除了业务数据本身，平台还应能够查询记录标识、采集时间、首次发送时间、最后发送时间、重试次数、确认结果和错误原因。

在施工数据场景中，还需要保留原始过程曲线和记录表，便于核对数据是否完整。下图中的曲线折点、字段和数值均来自原始界面截图，未重新绘制或修改。

9. 上线前的故障演练

正式上线前建议完成一次完整演练：

1. 正常采集并确认平台收到数据；
2. 采集过程中断开网络；
3. 检查数据是否进入本地缓存；
4. 重启采集程序或网关；
5. 恢复网络并观察续传；
6. 检查平台是否重复、缺失或乱序；
7. 核对发送时间是否满足业务要求；
8. 验证错误记录是否能够追踪。

总结

可靠上报不是简单增加一次重试，而是建立“先持久化、再发送、成功确认、失败保留、恢复续传、平台追踪”的完整闭环。

只有把设备读取、缓存策略、网络异常、幂等规则和业务时限一起设计，才能在现场环境不稳定时明确知道数据在哪里、为什么失败以及最终是否完整到达平台。