断网期间怎么办：本地缓存、补传与去重

现场设备断网是常态：基站维护、园区停电、工业环境里的电磁干扰、运营商侧的策略调整。项目验收时网络都好，上线三个月后才发现某个站点每天断十几分钟。设计阶段就把离线当作正常状态处理，比事后补救省事得多 —— 这也是我们在制造业类现场项目里优先确认的一项。

本地缓存存多久

容量规划的输入是三个数：单条记录的字节数、上报频率、可接受的最长离线时长。三者相乘就是需要的存储空间。要注意按最坏情况算 —— 如果业务上要求「断网一天的数据不能丢」，那就按一天算，而不是按通常断几分钟算。

存储介质也要考虑写入寿命。高频写入普通 Flash 会在几年内把擦写次数用完，表现为设备在质保期后期批量出现存储故障。降低写入频率、使用磨损均衡、或者改用适合频繁写入的介质，都应当在硬件选型时确定。

缓存满了怎么办

必须明确选择丢弃策略，并写进文档：丢最旧的，还是丢最新的，还是降采样保留。对趋势类数据，丢最旧的通常可接受；对告警类数据，任何一条都不能丢，应当单独存放、单独限额。最糟的做法是没有策略 —— 写满之后行为由存储层决定，而不同批次的硬件可能表现不同。

重连补传会把平台打垮

一个园区的几百台设备因为同一次网络中断同时离线，网络恢复后它们也会同时重连、同时开始补传。瞬时流量可能是平时的几十倍，而这正是平台最脆弱的时刻。

• 设备侧：重连加随机退避，不要所有设备都在网络恢复的那一秒发起连接；
• 设备侧：补传限速，按固定速率发送，不要一次性把缓存全部推出去；
• 平台侧：对补传通道单独限流，保证实时数据的处理不被补传挤占；
• 平台侧：接入层做好背压，宁可让设备稍后重试，也不要让后端服务被压垮。

时间戳必须是采集时间

补传数据最容易出的错，是平台用「收到的时刻」当作数据时间。这样一来，断网一小时后补传的数据会全部挤在恢复后的那一分钟里，曲线完全失真，基于时间窗口的统计和告警也会跟着出错。

正确做法是设备在采集时就打上时间戳并随数据一起上报，平台以这个时间为准。随之而来的要求是设备时钟必须准确，这又牵出对时问题 —— 两件事必须一起设计，只做其中一件等于没做。

去重与幂等

补传过程中断再重来、确认报文丢失导致重发，都会产生重复数据。设备为每条记录生成稳定的唯一标识（常见做法是设备标识加采集时间加序号），平台按此判重。这个标识必须在设备重启后仍然稳定，否则重启前后的同一条数据会被当成两条。

下游的计算也要能接受乱序和迟到。这一层的取舍通常在物联网平台解决方案的方案阶段就要定下来。实时流处理里通常用水位线机制处理迟到数据，但补传可能迟到几小时甚至几天，超出常规水位线的容忍范围。这类数据更适合走单独的批处理补算路径，而不是强行塞进实时链路。