增量同步与全量同步的取舍:变更捕获的五种方法

全量与增量的本质取舍

全量同步每次拉全部数据,逻辑简单、天然自愈(这次错了下次全量还能覆盖回来),代价是资源消耗大、实时性差。增量同步只拉变化部分,轻快、准实时,代价是一旦漏捕,差异会一直存在,直到下次全量才被发现。所以工程上的标准答案是:增量做日常,全量做兜底对账,两者不是二选一。

五种变更捕获方法

1. 时间戳(Modified Time)

按"最后修改时间 > 上次水位线"拉取。实现最简单,主流平台 API 都支持。弱点:时钟漂移导致漏数据;同一秒内的多条记录翻页易错;删除动作不产生修改时间,捕获不到删除。对策:水位线回退 5-10 分钟重叠拉取 + 按主键去重。

2. 自增 ID / 序号

按自增主键或单号水位线推进。可靠捕获新增,但捕获不到更新——老记录改了,ID 不变。适合纯追加型数据(流水、日志),不适合档案类数据。

3. 日志型 CDC

直接订阅数据库的事务日志(MySQL binlog、PostgreSQL WAL),新增、更新、删除都能捕获,且对业务库零侵入。缺点是需要数据库级权限和运维能力,SaaS 系统不可能给你日志权限——所以日志 CDC 只适用于自有系统之间的同步。

4. 触发器

在源库上建触发器,把变更写入一张变更队列表,同步程序读队列表。能捕获全部 DML,但侵入业务库:触发器写失败会拖累业务事务,大表上性能影响明显,且 DBA 通常反感。仅在无其他手段时考虑。

5. 消息订阅 / Webhook

源系统产生业务事件时主动推送。实时性最好,且有业务语义(不是"某行变了"而是"订单发货了")。弱点:推送可能丢失(网络、对端宕机),必须有"定时增量兜底"配合;消息可能重复,消费端要幂等。

对比与选型

工程实践要点

1. 水位线持久化:增量游标必须落库,崩溃重启后从断点继续;
2. 重叠 + 去重:任何基于时间的增量都要重叠窗口并按主键去重,宁可重复处理,不可漏;
3. 定期全量对账:按天或按周跑一次全量比数,差异报警,这是增量可靠性的最后防线;
4. 删除单独设计:软删除(状态字段)优先于物理删除,同步链路只处理状态变更。