设备采集数据断网补传怎么做：边缘端断点续传的序号、去重与时间戳设计

结论：断网补传的关键不是“把缓存重发一遍”，而是给每条数据一个单调递增的序号和采集时间戳，让云端能够幂等去重、按序回填，并识别缺口。 一、问题场景 车间网络偶尔中断几分钟到几小时，边缘网关继续采集并写入本地缓存。网络恢复后如果直接重发，常见后果是重复数据、乱序、实时看板被旧数据覆盖。 二、消息结构设计 每条消息建议包含：设备ID、点位ID、值、质量位、采集时间戳（设备或网关时钟，UTC）、网关序号（每网关单调递增，重启持久化）、上报时间戳、补传标记。云端以“网关ID+序号”作为幂等键。 三、补传流程 1. 本地缓存按序号顺序落盘，记录“已确认序号”游标。 2. 上报后收到云端ack才推进游标，未ack的重发。 3. 恢复连接时，先发送最新实时数据，再用低优先级通道回填历史，避免实时延迟。 4. 回填限速，防止一次性冲击云端；建议按批次（如每批几百条）并带批次序号。 5. 云端依据序号发现缺口（序号不连续）并请求重传。 四、时钟与乱序 网关与PLC时钟不一致时，补传数据的时间戳会错位。做法：网关定期NTP校时，记录校时偏差；业务看板用“采集时间”排序，用“补传标记”区分是否实时。聚合统计（如产量、OEE）需要对迟到数据支持重算窗口。 五、常见坑 1. 序号在网关重启后清零，导致云端误判重复，应持久化或加入启动纪元号。 2. 缓存满后覆盖策略不明，建议优先保留关键点位、丢弃高频低价值点位并记录丢弃数量。 3. 只在云端去重而没有ack，重发风暴。 FAQ MQTT QoS选几？补传场景用QoS1配合幂等键，QoS2开销较大且仍需业务去重。 缓存放多久？按断网最长时长与采样频率估算容量，再留余量。 补传会影响实时看板吗？分通道、限速即可。 质量位还要保留吗？要，补传不应改变数据当时的质量判定。 本文由AI辅助整理，为通用技术思路，请结合实际环境验证。