分散污水站断点续传机制：网关存储与补传原理

农村分散污水站有一个躲不开的现实：位置偏，信号差。站点建在村头田间，有的地方 4G 信号就一两格，运营商基站一抖动、雷雨天气一干扰，网络就断。断网的时候，站里的液位、水泵状态、流量数据还在产生，可要是传不上去，事后监管平台和台账里就是一段空白。赶上考核数据完整率，这段空白就是硬伤。

很多运维单位一开始以为"断网就是没数据"，其实不是。数据在站里一直在，缺的是把它存下来、再补上去的机制。这个机制就是断点续传，它分三步：本地缓存、按序补传、平台合并。下面把每一步的原理拆开讲。

断点续传发生在哪个环节

分散站点的数据链路通常是：仪表和控制器采集数据 → 网关汇聚上传 → 平台接收存储。断点续传的活主要在网关这一层干。仪表数据先以固定周期采上来，网关一边往平台发，一边在本地留一份。网络正常时两件事同时做，网络断了，本地这份就顶上来，等网络恢复再补发。所以网关的存储能力和数据管理逻辑，直接决定断点续传靠不靠谱。

网关在选型上差别不小。WBOX 系列里，WBOX100 主打宽温低功耗，适合户外机柜、夏天暴晒冬天上冻的环境；WBOX50 突出协议兼容，上百种工业协议能接；WBOX300 带 5G 和边缘算力，适合数据量大、还要做本地处理的站点。站点信号差、环境恶劣的，优先看宽温和低功耗，这两条不过关，网关自身先罢工，续传就更谈不上了。

本地缓存：数据先落地，别裸传

网关内部一般都带非易失存储，数据采集上来先写缓存，再异步上传。写缓存要满足三个条件：一是掉电不丢，断电重启后数据还在，不然雷雨天气跳闸一次，缓存全清空，等于没存；二是按时间戳组织，每条数据带采集时刻，这样补传时平台才知道这条数据属于哪个时间点；三是容量可覆盖足够长的时间段，缓存能存多久，取决于存储容量和采集频率，采集周期越短、数据越密，同样容量覆盖的时间越短。实际配置时要算一笔账：按现场采集周期，把缓存容量留到能覆盖数小时甚至数天的中断，宁可多留，不要刚好卡在运营商"修个基站要一天"这种场景上。

采集周期本身就是可调的技术参数。像液位、水泵状态这类变化不剧烈的点，5 秒到 60 秒一个周期都常见；流量、余氯这类要精细统计的点，周期会短一些。周期越短数据越全，但对缓存和上行带宽的要求也越高，现场按点位重要性分开设，别一刀切。

恢复通信后：按序补传，平台按时间戳去重

网络恢复后，网关要做的是把中断期间缓存的数据按时间顺序补发出去，不是一股脑乱传。补传一般走消息队列机制，传输协议用 MQTT 时常见配置 QoS 1 或 QoS 2，确保平台收到确认才从缓存里清除这条，没收到确认就继续重发，这样不丢数据。平台侧收到补传数据后，按时间戳和序列号做去重合并：正常时段的数据和补传数据如果时间戳重叠，保留一份即可，避免重复入库把报表数字放大。

这套逻辑跑顺之后，监管平台看到的就是一条连续的数据曲线，中间缺乏断档，考核数据完整率时能拿得出手。反过来说，如果网关缺乏断点续传，只靠"网络好时传、断时丢"，平台上的曲线就是一段段豁口，事后补台账都无从补起。

断网场景不同，处理策略也要分层

断网不是一种情况，处理策略得分层：

秒级到分钟级的抖动，靠重发机制兜住。网络闪断时，网关自动重连、自动重发未确认的数据，用户基本无感。

小时级的中断，靠缓存兜住。基站检修、停电超过半天，网关本地缓存持续记录，恢复后统一补传。这要求缓存容量和掉电保持都过关。

长时间离线（比如一周以上），缓存可能溢出。好的做法是缓存满了按"先覆盖时间靠前的数据"的策略滚动，同时在平台侧把离线时长记下来，运维人员能看到"这个站离线 3 天、期间数据覆盖到哪"，心里有数。

现场选网关，盯住这四条

一是协议兼容性，站里既有 Modbus RTU 仪表又有走 4G 的控制器，网关能不能；二是缓存与掉电保持能力，这是断点续传的地基；三是宽温范围，户外机柜冬夏温差大，普通商用级设备扛不住；四是上行通道，4G 网络是底线，有条件的地方可以配以太网或 WiFi 做双通道冗余，一条断了另一条顶上。

数据从站里出来到平台，中间这一跳看着不起眼，却是整个远程运维的数据命根子。断点续传做扎实了，无人值守站点才敢真正放手。平台端配合做好接收合并，比如司水云官这类运营平台对补传数据按时间戳去重入库，曲线连续、报表准确，运维和迎检都省心。网关选对、缓存留够、协议理顺，分散站点的数据完整性就有底了。

（正文实点字数：1774）