断网的两小时，数据去哪了：缓存与补发机制

凌晨数采仪掉线两小时，恢复后平台上的曲线是平直延续还是整齐缺失？运维员盯着屏幕祈祷"千万别空"，考核专员已经在算有效率损失。HJ 212这类环保物联网协议对断链场景早有安排：缓存、补发、标志位三件套。但这套机制能不能救回数据，取决于数采仪配置、平台接收策略与现场时钟三者是否合拍——多数"补不上来"的事故，坏在配置与细节而非协议本身。

断链时刻的三种命运

掉线期间，现场数据通常有三种结局。理想的是数采仪本地缓存：采集线程继续跑，原始值写入本地存储，链路恢复后按时间片打包补传。其次是停止采集：部分老旧配置在通信失败后连仪表都停止轮询，断链期间根本没有原始数据，复线后只能上报缺失标记。最糟的是继续采集并上报但数据悬空：平台端因会话超时丢弃报文，现场以为传了，平台根本没收，双方账本都对不上。三种结局的差别在数采仪的缓存策略与心跳参数设置里，属于"平时无感、事故时定生死"的配置项。

补发的时序规则值得展开：平台一般设补发受理窗口，超限的旧数据拒收或仅作日志；窗口内按原始时标入库，与已到达的新数据交错时，去重与覆盖策略决定最终形态。若数采仪本地时钟漂移，补上来的数据时标整体偏移，最坏情况是把两小时数据叠进错误时段，污染相邻数据的有效性——这类事故的排查成本远高于平时做对一次对时。

把机制变成可验证的预案

机制写在协议里，可靠性要靠演练。投运验收阶段就应做一次断链实测：人为拔线半小时，恢复后到平台端核对补发序列的完整性与时标对齐，把结果记录进验收文档。日常层面，数采仪的缓存余量、覆盖策略与重连参数纳入季度检查项；每次协议升级或平台迁移后重演一次补发测试，因为接收端的窗口规则可能已经改变。

标志位是最后一道诚实防线。补发的数据应带相应标记与原始时标，让审核端能区分实时与补传；把补发数据当作成实时值不仅违反数据管理规范，事后审计时也必然暴露。考核口径上，多数有效率统计对"在允许时限内完成补传"的数据按有效处理——前提依然是补得回、补得对、补得诚实。

运维习惯上还有一条经验：断链复线后的头十分钟值得盯。缓存洪峰拥塞链路、平台批量校验触发异常告警、新旧数据交错暴露时钟偏差，绝大多数补发问题在这十分钟里现形。设一条复线后的自动核对任务，比对补发条数与应有条数，比人工翻平台快得多。

常见问题

问：数采仪显示已发送，平台没有，信谁？
答：以平台入库为准，但先查报文层。核对应答码与重发计数：有应答无入库多是平台侧校验剔除，无应答则是链路或会话问题。两边日志带时区导出，对表即可定位责任段。

问：断链期间仪表数据要不要手工补录？
答：按数据管理规范执行，自动监测数据不允许以手工录入冒充自动采集。应急手段是记录工况台账并申请标记，事后以仪表本地存储做证据核查。

问：补发窗口通常多长？
答：以联网协议与平台技术规定为准，常见为天级到周级量级。超过窗口的历史缺口，正确的处理是有效性标记加台账说明，而不是强行补传。

问：缓存容量有限，优先保哪类数据？
答：优先原始监测值与关键事件记录，日志与报警明细可降频。配置时注意断链判定阈值别设太灵敏，避免网络抖动被误判为断链而浪费缓存。

断网不可怕，可怕的是不知道数据有没有活下来。把缓存、补发、标志位三件套配置到位并定期演练，恢复那一刻的祈祷就变成了例行核对。