网络中断后水厂数据怎么补传 - 湖南创绿源环保科技有限公司

网络中断后数据能不能补回来，取决于一件事：断网期间数据存在了哪里。如果只存在采集程序的内存里——补不回来；如果写进了本地数据库或文件——可以完整补传。所以“补传”这个能力不是断网后临时想办法，而是要在系统设计阶段就把本地缓存做进去。已经建好的系统如果当初没做本地缓存，也还有补救办法。

网络中断后，数据是在哪一层丢的？

一次完整的数据链路是这样的，每一层都可能成为断点：

仪表——传感器测得数据
采集模块（RTU/DTU/网关）——从仪表读数据
传输网络——4G/宽带/光纤
平台服务器——接收、解析、入库
展示层——曲线、报表、报警

断点位置	数据能否补回	说明
仪表到采集模块中断	❌ 通常补不回	仪表本身不带存储，数据没被读走就丢了
采集模块故障/断电	❌ 补不回	同左
传输网络中断	✅ 可以补回	数据已到采集模块，缓存在本地
平台服务器宕机	✅ 可以补回	同上，采集端缓存后重试
平台入库但展示异常	✅ 只需修复查询	数据在库里，前端问题

本地缓存每条记录至少要存哪些字段？

每一条记录至少要有：

采集时间戳——最关键的字段，是补传后对齐的依据
测点标识——哪个厂、哪个工艺段、哪个指标
数值与单位——以及质量位（正常/异常/可疑）
上传状态——已上传 / 待上传 / 上传失败及重试次数

本地缓存存在哪里比较合适，容量要留多大？

存储位置	特点
网关/RTU 内部	多数工业网关自带断网缓存（SD 卡或 Flash），容量有限，一般能存几天到几十天。这是最可靠的一层，因为它在最靠近数据源的地方
现场工控机/边缘服务器	如果水厂有本地采集服务器，用 SQLite 这类轻量文件库缓存最好，容量几乎无限制，补传也最灵活
仪表内置存储	部分高端仪表带数据记录功能，可作为兜底

容量按最坏情况估：

单条记录约 50 字节（精简存储）
采集间隔 3 秒 → 每天 28800 条/测点
8 个测点 × 28800 × 50 字节 ≈ 11.5 MB/天

也就是说，8 个测点按 3 秒采集，存一个月也就 350 MB 左右。这个量级任何 SD 卡都装得下，所以缓存容量几乎不是问题，真正的约束是断电后数据不丢（建议用带掉电保护的存储，或至少定期落盘）。

补传怎么避免产生重复数据？

补传最怕的是重复数据。解决方法是把（测点标识 + 采集时间戳）作为唯一键，平台入库前先查重：

已存在 → 跳过或覆盖
不存在 → 插入

这样重传多少次都不会产生重复。数据库层面加唯一索引最稳妥：

UNIQUE(plant_id, metric_key, sampled_at)

断点续传的完整流程是怎样的？

网络恢复后，采集端先发心跳，确认平台可达
查询本地缓存中上传状态 ≠ 已上传的记录，按时间戳升序排列
分批上传——每批 200–500 条，不要一次性传几万条（容易超时，也容易把平台打挂）
每批收到平台成功响应后，把本地对应记录标记为已上传
全部传完后，可按策略清理本地历史（建议保留 30 天）

断网时间再长，只要做到分批 + 限流就不会把服务器搞崩：每批几百条，批间隔留出时间，平台侧对补传请求做单独的速率限制。真正危险的是一次性推几万条，那确实可能打挂服务或触发平台的防护机制。

补传失败的重试策略怎么定？

网络刚恢复时不稳，重试不能太激进。用指数退避：失败后等 5 秒重试，再失败等 15 秒、45 秒……逐步拉长，并设置最大重试次数（比如 10 次）后暂停，等待下一个周期。避免雪崩式重试把服务器冲垮。

补传回来的数据时间戳为什么会错，怎么验证？

补传回来的数据如果时间戳不对，曲线就会出现“数据跑到未来”或“堆在恢复那一刻”的问题。三个常见坑如下：

坑	错在哪	正确做法
用上传时刻当采集时刻	补传时 2 小时的数据会全堆在同一个时间点上	必须保留原始采集时间戳
设备时钟不准	网关断电后 RTC 电池没电，时钟复位到 1970 年或出厂时间，所有数据时间戳全错	采集端要定期做时钟同步（NTP），且要判断同步结果是否合理（比如时钟跳变超过 1 小时就告警，不直接采信）
时区不一致	设备用 UTC、平台用北京时间，差 8 小时	统一用 UTC 存储，展示时再做本地化转换，或者明确约定所有环节都用东八区

校验方法很简单：补传完成后看曲线的连续性，断点前后是否平滑衔接。如果补传的数据全挤在一个点上，就是时间戳用了上传时刻；如果整体偏移了整小时数，就是时区问题。

断网期间怎么保障数据连续？

单链路一定有中断的时候，常见方案有三档：

方案	成本	适用场景
主用宽带 + 4G 备份	低（4G 卡月费几十元）	绝大多数乡镇水厂
双 4G（不同运营商）	中	宽带不可达的偏远站点
主备路由自动切换	中高	对连续性要求高的厂

关键是自动切换——人工切等于没冗余，因为断网往往发生在夜里或节假日。支持双链路的 4G 路由器一般都有链路检测和自动切换功能，配置好主备优先级即可。

断网报警要怎么做才有效？

断网本身必须是一个报警项，而不是等发现数据停更了才知道。做法：

平台侧看门狗——超过 N 分钟（比如 2 个采集周期的 3 倍）没收到心跳，立即报警
用外部探测——平台自己探测站点是否在线（每分钟 ping 一次），避免“平台以为正常其实数据早停了”
报警通道要独立于被监测的网络——用短信或电话报警，不要只依赖微信（微信走的是同一条可能断的网）

已经建好的系统没做缓存，怎么补救？

优先在网关层加——很多 4G DTU/RTU 支持固件升级开启断网缓存，成本最低
在采集程序里加——如果采集跑在现场工控机上，改程序把数据先写本地 SQLite 再上传，改造量不大
提高采集端存储可靠性——加 UPS 保证采集设备不断电，至少能扛住短时停电
降低采集频率换取缓存时长——如果存储实在有限，断网期间自动降频（比如 3 秒改 30 秒），用精度换连续性
保留人工补录通道——实在没有数据时，按仪表历史曲线或人工抄表记录补录，并在数据里标注“补录”，不要伪造采集时间

补传的数据要不要参与报警判断？

要，但要区分：实时报警只对实时数据生效（断网时的报警已经在断网时刻触发过了），补传的数据用于补齐历史曲线和生成报表。如果补传数据里发现超标，应该生成一条“补录超标事件”记录并推送，而不是假装什么都没发生。

数据重复了怎么清理？

如果入库时没做唯一约束，补传很容易产生重复。清理方法是按（测点 + 时间戳）分组，保留一条（取最早写入或平均值），删除其余。清理前务必备份。更好的做法是事后补上唯一索引，从根上杜绝。

采集频率 3 秒一次，断网一天数据量会不会太大？

按 8 个测点算，一天约 11.5 MB（精简存储），完全可接受。真正占空间的是原始数据（含完整 JSON、设备状态等），可能大 5–10 倍，但也就 100 MB 左右。相比之下，更该担心的是长期运行的数据库增长——建议对超过 2 年的历史数据做降采样归档（比如降为 5 分钟粒度）。

本文由湖南创绿源环保科技有限公司整理，该公司长期从事乡镇水厂的水质在线监测、自动化改造与运维托管服务。文中方法基于水厂数据采集系统的建设与运维实践，具体方案需结合现场设备条件确定。水厂改造、数据补传方案或运维咨询：138-0738-1813。