最近在折腾一个项目现场的 Modbus 水表采集网关通过 4G 网络把数据推到云端。用户抱怨最多的是两件事一是网络一抖后台就缺数据二是链路恢复了老数据和新数据挤在一起乱得没法看。这种问题几乎把所有做采集网关、文件传输、设备上云的人都磨了一遍。解决思路也不复杂——在网关里做一层“断点续传”的传输通道。断点续传这词听着像下载工具专属但放到网关场景里它能同时解决数据完整性和连接连续性问题也就是标题里说的“数据完整并无缝上网”。这篇分享从一个做了多年链路传输的老工程师视角出发把原理、设计、代码和踩过的坑一次性讲清楚。如果你做 IoT 采集、自建文件同步或者只是总被 Git 断线重拉折磨都能在里面找到对应的解法。1. 断点续传网关是什么解决什么问题1.1 断点续传和完整上传的本质区别先从一个最基础的问题说起断点续传和完整上传到底差在哪完整上传的思路是把一整份数据当作一个单位传的过程中只要任何一个字节出错、任何一个分片没到整个文件就视为失败下次只能从头开始。这种模式在链路质量好的内网里影响不大但在公网、4G、Wi-Fi 漫游这类场景里传输中断是常态。一次 2GB 的文件传输网络在 80% 的位置断掉完整上传意味着你实际上消耗了接近 4GB 的流量而且时间翻倍。如果网络反复抖动这个消耗会被无限放大。断点续传的做法是先把数据切成多个分片每个分片独立校验网关记录“已经传到哪一片”的进度断线重连之后从进度位置继续。这里的核心不是“省流量”那么简单而是让传输行为从“一锤子买卖”变成“可持续推进的过程”。数据完整性的保障也分阶段落实每一个分片都有独立校验不必因为某一小段的失败而否定前面几千个分片的成功。对比下来完整上传简单粗暴适合内网可靠链路、小文件、对实时性要求高的场景断点续传适合公网、弱网、大文件、长时间积累数据的场景。在采集网关场景下数据是持续产生的链路中断也不是例外而是常态所以断点续传几乎是最符合需求的方案。1.2 为什么续传逻辑要放在网关里有一个设计取舍很关键续传逻辑放在终端设备上还是放在云端还是放在中间的网关很多终端设备的能力有限。比如 Modbus 水表本身就是一个传感器或者简单仪表它连 TCP 都不知道是什么只会按 645 协议把数据帧吐出来。你不可能让它自己管理断点续传也不适合让它缓存大量数据。云平台呢倒是能力足够但它离现场链路太远管不到网关到设备这一段子网的细节。网关放在中间天然适合扮演“缓冲区和调度器”的角色。它往下连接终端把 Modbus 645、DL/T 645 这类协议的数据收上来然后对上用一条可控的传输链路把数据异步推到云平台。终端感知不到网络状态云平台只需要处理已经按序到达的数据包。网络断了网关本地缓存网络恢复网关按序继续传。对于整个系统来说真正跟不可靠公网打交道的角色只有网关一个所以把断点续传逻辑集中部署在那里是性价比最高的选择。1.3 断点续传的三种常见形态断点续传不是一个单一技术按数据粒度可以分成三种形态网关里往往同时用到文件级断点续传以文件为操作对象通过 HTTP Range 或者 FTP REST 实现重传时从指定字节偏移量开始。典型场景是固件升级包分发、日志文件归档。消息级确认重传每条消息独立编号接收方收到后回 ack超过超时未收到 ack 就重发。MQTT QoS 1 和 QoS 2 就是这种思路。流式游标续传以记录数、时间戳或者自增 ID 作为游标网关记录“已确认的最大位置”恢复后从游标继续读取。适合采集点数据、数据库同步。实际网关设备通常会把三种形态混用从终端拿到的一帧采样数据按消息粒度入库再按时间戳游标分片上云大文件固件单独走文件级续传。理解这个层次后面设计数据完整性机制就不会搞混。2. 网关保障数据完整的四个核心动作断点续传能保证“不丢数据”吗能但要满足一定条件。要保证数据完整网关里必须有四个核心动作分片校验、游标记录、幂等去重、本地落盘。缺一个断点续传就只是半成品。2.1 分片与指纹让每一段数据可校验首先要解决的问题是我怎么知道传过去的这一段是不是完整的做法是把连续数据按固定大小切分然后给每个分片算一个指纹通常是 SHA-256。发送方把分片和指纹一起发过去接收方算一遍指纹一致才算这个分片被正确接收。类似寄快递时每个包裹都贴封条件件都对得上号才确认签收。分片大小选择有讲究。分片太大一旦出错重传的代价就大分片太小指纹计算和确认的开销会占太多带宽。我一般在局域网或者传输质量好的链路上用 1MB 分片在 4G 弱网环境用 256KB 到 512KB。对于 Modbus 采集数据这种小帧可以按一批数据的自然边界来分片不要硬切避免把一帧数据拆成两半。要注意的是指纹校验不仅仅防“传错”还防“写坏”和“中间环节改数据”。如果网关和云平台之间有公网传输建议校验字段用 HMAC 带上会话密钥防止中间某个节点偷偷改数据。纯 SHA-256 只能发现错误加上密钥才能确认是可信端发来的内容。2.2 游标与水位记录关键在“已确认”断点续传最关键的状态是什么是“进度”。如果我记录的是“已发送位置”那这个信息不可靠因为发送了不代表接收方成功收到了。必须记录“已确认位置”用确认游标来表示——云平台明确回复“这一片收到且校验通过”网关才能把游标推进。这个确认游标有个形象的叫法水位。水位以下的数据可以放心淘汰水位以上的数据必须继续保留。设计时注意不同分片到达云平台可能乱序所以游标不一定是单调增长的最大序号而是“连续没断档的最大序号”。比如云平台收到了 1、2、3、5 号的分片游标停在 3因为 4 号还没确认4 号补齐后游标才跳到 5。这样的好处是即使后面传了 100 个分片只要中间缺了一个网关就知道从缺口处继续补不用把后面全部重传。这也是我强烈建议的做法游标推进逻辑写成“连续确认才推进”而不是“收到最大号就推进”。2.3 幂等与去重防止数据重复断点续传最讽刺的坑是网络恢复后疯狂补传结果把一大堆数据重复推到了平台上。为什么会出现重复因为网络中断可能发生在“云平台已经收到并回复 ack”之后网关没收到 ack于是判定传输失败重新发送。此时同一分片就会被传两遍。解决思路就是幂等让接收方对同一标识的数据只处理一次。实现上云端要记录每条消息或每个分片的唯一标识消息 ID、序列号、业务主键处理之前先查一下标识是否已存在已存在就直接返回成功不再重复入库。网关侧也要依赖这个机制不要以为“我发了两次说明数据有风险”只要云端幂等做对了重传就是安全的。这里有个经验唯一标识最好由业务数据内容生成比如设备序列号加采集时间戳而不是用网关内部递增序号。因为网关重启后序号可能重置内容生成的标识是天然幂等的。我在实际项目里用“设备ID 批次号 数据序号”的组合至今没有出现过因为重传导致的数据重复。2.4 本地落盘断点数据的保管所断点续传要成立一个前提是断线期间的数据不能放在易失内存里。网关电力一断、进程一崩内存里的数据就全没了。所以网关必须有本地存储把待传数据持久化。具体做法是给每个数据分片加一个状态机待传、传输中、已确认。状态明确之后即使网关重启也能从本地数据库或文件系统里把所有“待传”和“传输中”的分片找回来继续处理。“传输中”的分片再依赖云端的幂等去重重传也不会有问题。存储介质的选择要看数据量。如果只是几万条采样记录SQLite 足够如果每天产生 GB 级数据建议用文件分片加索引结构避免把大对象塞进数据库拖慢性能。磁盘写入不需要每条数据都同步落盘可以攒一批批量 flush但要保证操作系统崩溃时可恢复。我常用的做法是数据先写日志型存储再异步合并成正式分片文件兼顾性能和可靠性。3. 无缝上网背后的链路保持技术说完数据完整性的保障再说“无缝上网”。这里的重点不是让网络永不中断——公网做不到——而是让传输在链路切换和抖动时尽量无感用户和上层业务几乎察觉不到发生过断线。3.1 多链路切换与出口探测网关要真正做到“无缝”不能只依赖一条物理链路。常见的做法是双 SIM 卡、4G 加有线以太网、Wi-Fi 和蜂窝混合。网关持续探测各条链路的实际质量不是简单地看接口有没有 up而是周期发送心跳报文看往返时延和丢包率。检测到当前链路异常后网关把实时流量切到备用链路。切换的关键是提前准备备用链路的默认路由、DNS、认证参数都要预先配置好切换动作不能现场现配。同时链路切换要尽量平滑对于 TCP 长连接可以把原链路上未确认的数据暂存新链路建立后再补发对于短连接业务可以通过在网关里维护一个统一的会话表让业务进程感知不到底层出口变化。3.2 会话保持与重连策略之前做调测时发现一个问题链路切换后业务断了一会儿是因为上层应用没有重连机制一直在等旧连接的超时。网关可以做的一层工作是“连接代理”上游业务和网关之间保持稳定的本地会话网关和云端之间维护传输连接底层断了网关立即重建连接同时上层会话保持不动。重连策略也要讲究不是断线就立刻高频重试。建议用指数退避第一次 1 秒、第二次 2 秒、第四次 8 秒最大到 30 秒左右。这样做的好处是链路刚刚恢复时比较容易建立连接反复失败时不会把网关的资源耗尽也能给蜂窝网络一点恢复时间。3.3 业务协议怎么配合如果上层业务是文件分发或者数据上报协议选择对“无缝”程度影响很大。数据上报适合选 MQTT开启 QoS 1 或者 QoS 2Broker 断线不丢消息重连后消息自动续传。大文件同步适合支持 Range 的 HTTP 协议把文件切成块每块独立上传。如果要保证严苛的顺序需要自己在业务层排号协议本身只保证到达不保证全局有序。还有一个小细节网关和云平台之间的时间同步也很关键。断点续传的游标如果依赖时间戳网关本地时钟漂移会带来数据错排。建议网关启用 NTP 校时云平台对时间戳做阈值校验发现明显异常时标记待人工核查。4. 手把手搭建一个断点续传采集网关光讲原理不过瘾我直接展示一个能跑的骨架。场景是 Modbus 水表采集网关通过 4G 上传到云平台弱网环境下要保证数据完整。4.1 场景与基本架构现场有若干水表走 RS-485 总线接到网关网关定期按 Modbus 645 协议读取数据然后通过 MQTT 上报到云平台。网关运行 Linux内含四个模块采集器Collector按周期调用 645 协议读取水表数据生成采集记录本地队列Store把采集记录持久化到 SQLite标记待传状态传输器Transmitter按批次从队列取数据分片推送到云平台处理 ack状态管理State保存确认游标、链路状态、运行日志这四个模块尽量独立尤其是采集和传输之间必须解耦。采集器不管网络通不通只负责把数据收好存好传输器只管上传上传失败不影响采集。4.2 数据结构设计队列表的关键字段设计如下id自增主键本地使用device_id设备标识用于区分不同水表seq全局递增序号用于保证整体有序payload采集到的数据帧内容sha256数据指纹上传时携带statuspending、sending、confirmed 三种状态created_at采集时间注意 seq 要同时兼顾两个维度全局递增序列号和设备内序列号。全局序列号用来保证整体有序传输设备内序列号是业务唯一标识。我把两个都独立存储计算游标的时候按全局序列算去重的时候按设备内序列号算。4.3 核心代码骨架下面代码展示传输器的主循环省去具体协议细节只保留断点续传的核心逻辑Python 伪代码import hashlib import sqlite3 import time CHUNK_SIZE 256 * 1024 # 弱网环境下用小分片 MAX_RETRY 10 BASE_TIMEOUT 2 class ResumeTransmitter: def __init__(self, db_path, cloud): self.conn sqlite3.connect(db_path) self.cloud cloud self.retries 0 def send_pending(self, device_id): rows self.conn.execute( SELECT id, seq, payload FROM upload_queue WHERE status IN (pending,sending) ORDER BY seq ).fetchall() for row_id, seq, payload in rows: fingerprint hashlib.sha256(payload).hexdigest() ack self.cloud.push( device_iddevice_id, seqseq, payloadpayload, checksumfingerprint ) if ack and ack.get(checksum) fingerprint: self.conn.execute( UPDATE upload_queue SET statusconfirmed WHERE id?, (row_id,) ) self.retries 0 else: self.retries 1 delay min(BASE_TIMEOUT * (2 ** self.retries), 30) time.sleep(delay) break self.conn.commit()这个主循环的关键点是传输严格按 seq 顺序遇到失败就停在这一条先退避重试成功之后再推进。这样天然满足“连续确认才推进”的游标逻辑后面顺序不乱前面也不缺。当然这个骨架比较简化。实际项目里要加上多线程、批量确认、磁盘 flush 策略、云平台幂等去重这些前面的章节已经讲过直接套上去就能用。4.4 参数选择的工程建议几个关键参数的推荐值我直接给出来都是实测过一轮的分片大小弱网 256KB内网 1MB。太小指纹计算开销占比高太大失败重传代价高。超时时间初始 2 秒超过按指数退避到 30 秒封顶。不要设成固定长超时否则断线时每一条都要白白等很久。本地队列容量按最极端断网时长估算。比如每天 2880 条采集记录最坏断网 3 天就要预留 1 万条以上的容量再算上磁盘余量。批量确认云端可以每收到 50 个分片批量回一个 ack减少小包交互。但游标记录仍然按逐个分片推进不能因为批量确认就跳着记进度。4.5 断线恢复全流程演示为了让大家有直观感受我模拟一次完整的断线恢复过程。假设队列里有 10 条记录seq 从 1 到 10传输器发送 seq1..6云平台 ack 到达 seq6。突然断网传输器尝试发送 seq7 失败进入退避重试。断网 3 分钟重试期间 seq7 一直没成功seq8..10 保持在待传状态。网络恢复传输器重试 seq7 成功继续发送 seq8..10。云平台确认全部 10 条游标推到 10队列清空。整个过程云平台最终收到的 seq 是连续的 1..10没有一条数据因断网丢失也没有一条重复也没有乱序。所谓“数据完整并无缝上网”在业务层的体现就是这样——用户看到的是云端数据毫无破洞后台日志里可能确实记录了几次重连但业务体感上是连续的。5. 常见问题与排查技巧实录做了几年传输链路的东西把高频问题整理成速查表再讲三个让我印象深刻的真实案例。5.1 高频问题排查速查表现象可能原因排查方向数据缺了一段游标推进逻辑不对允许跳号检查“连续确认才推进”是否生效数据大量重复云端没做幂等去重查消息 ID 是否唯一、后端是否查重卡在某一条一直重试该条数据校验始终失败可能是序列号冲突或数据本身损坏恢复后顺序错乱多线程并发上传没有统一排序检查是否严格按 seq 串行推进重启后进度丢失状态没落盘或落盘太晚确认游标和消息状态的持久化时机网关内存占用持续上涨队列无限堆积设置队列上限增加告警5.2 三个印象深刻的真实问题第一个问题是“对端 ack 卡了一小时”。现象是云平台明明收到了数据但网关一直显示待传一个小时后又把这批数据重传了一遍。排查到最后发现云端 ack 消息里带了额外的耗时操作个别 ack 超过了网关的超时阈值。网关等不到 ack 就重传云端因为幂等做得好没有产生重复但浪费了很大带宽。后来我把 ack 和业务入库解耦先回 ack 再异步写库问题消失。第二个问题是“传上去的数据是乱的”。断点续传的游标是连续的但并发上传把顺序搞乱了。原本设计里就有全局 seq 排序但实现时图方便用了两个线程各传一半结果后半段先到云端前半段还堵在队列里。我最后把上传改成了严格串行用单线程加队列牺牲一点吞吐换顺序对采集数据这种场景完全不亏。第三个问题是“重启后本地队列丢失一半”。原因是每一条记录都等落盘才返回磁盘 IO 太慢于是代码改成了攒 100 条才落盘结果进程在断电时提前死亡最后 100 条还没有落盘的数据就没了。后来我改成了 WAL 模式加每 5 秒强制检查点既保证了性能又能在断电后恢复。这个坑提醒我性能优化不要以牺牲崩溃一致性为代价两者的平衡要控制好。5.3 排查工具和手段排查断点续传问题我常用的手段其实不复杂抓包看 TCP 重传和连接断开判断是不是链路层的问题在网关里记录每一条 seq 的发送和 ack 时间做成时间线日志一眼看出卡点在云端对比收到的 seq 序列画一个缺口图缺口在哪说明游标就停在哪抓包工具首选 WiresharkMQTT 场景可以直接过滤 mqtt 报文看 QoS 交互。链路层延迟测试用 ping 和 mtr 结合断线时看哪一跳出了问题。6. 几点实战体会与设计取舍把所有这些经验浓缩成几条供参考第一断点续传一定要把“已发送”和“已确认”分开记录。很多半吊子实现只记录已发送位置导致大量重传和丢数据。已确认才是真正的进度未确认的都要重做。第二幂等去重要在接收方做而且越靠近存储层越好。网关层重传是难免的只要云端保证同一业务标识只处理一次重传就是完全安全的。反过来如果云端有重复你在网关层使劲优化也补不齐。第三链路要分主备不要指望单条链路从不中断。蜂窝网络在信号差的区域波动非常大多出口加上自动切换体验会有根本性的提升。但不是所有切换都能做到零丢包把断点续传和链路切换结合起来才是完整的“无缝”方案。第四别把实现做太复杂。分片、校验、游标、幂等、状态持久化这五件事做扎实90% 的传输问题都能解决。过度设计反而容易引入新的状态错误到时候查问题比解决问题更花时间。最后分享一个调优小技巧如果你发现断点续传经常在某个进度位置反复失败先别急着调重试逻辑去看那个位置附近的数据内容。很多时候不是网络问题而是某一帧数据本身格式异常或者被别的进程改写了导致校验永远不过。先把脏数据剔除重启传输你会发现一切恢复正常。链路断了可以续传缓存满了可以扩容数据的完整性和唯一性一旦在业务层面失信整个采集平台的可信度就很难救回来。这也是我一直坚持要把网关这一层做扎实的原因。