大批量数据同步实战:分页策略与断点续传设计

大批量同步的真实约束

历史数据初始化(如三年订单、十万级 SKU 商品)与日常增量完全不同:数据量大、平台限流收紧、单页返回有限(常见 50~200 条),一次全量拉取动辄数小时。这段时间里任何环节都可能失败——网络抖动、限流、平台维护窗口。不能断点续传的同步任务,失败一次就前功尽弃。

三种分页策略的取舍

实践中的稳健组合:时间窗做主策略,游标做窗口内翻页。即先把总区间切成小时间窗,窗口内用游标翻完,逐窗口提交进度。

断点续传:进度即状态

断点续传的核心是把"同步到哪了"变成可持久化、可查询的状态:

1. 定义进度粒度:以时间窗为最小进度单元,每完成一个窗口,把 (task_id, window_start, window_end, status) 落库;
2. 原子提交:窗口内数据写入与进度更新放同一事务(或先写数据、再记进度,失败时宁重勿漏——配合幂等写入保证重跑安全);
3. 恢复逻辑:任务重启时查询最后一个成功窗口,从下一窗口继续;
4. 边界重叠:窗口边界允许少量重叠(如 1~2 分钟),重叠部分靠幂等键去重,杜绝因修改时间精度导致的漏数据;
5. 重跑能力:任何窗口都可手动标记重跑,用于事后补数。

增量水位线

初始化完成后,日常同步切换为水位线模式:记录 last_sync_time,每轮拉取 modified_time > last_sync_time 的数据,成功后推进水位线。两个细节:

• 水位线推进要用本批次数据里的最大修改时间,而不是服务器当前时间,否则在途数据会丢;
• 水位线回拨(如重跑昨天全天)必须是运维可控的一等操作,而不是改库。

落地步骤

1. 估算数据量与限流约束,算出总耗时与窗口大小;
2. 实现"窗口 + 游标"拉取器与幂等写入;
3. 进度表落库,实现恢复与重跑;
4. 低峰期跑历史初始化,监控积压与平台限流;
5. 切增量水位线,保留随时重跑任意时间窗的能力。

轻易云数据集成平台的同步任务天然按此模型运行:窗口化调度、幂等写入、断点自动恢复,历史初始化与增量同步共用一套链路。