1. 同步策略概述：为什么需要数据同步？快照与增量的核心概念对比
1.1 我们为什么要聊数据同步？
说实话，我入行头两年，觉得数据同步这事儿特简单。
不就是把数据从 A 库搬到 B 库吗？写个定时任务，全量导一遍，完事。直到有一次，我在一家电商公司做数据平台重构。业务方要求每天凌晨 3 点前必须看到前一天的全量订单数据。我当时图省事，直接写了个 SELECT * FROM orders 然后全量覆盖目标表。
结果呢？
订单表 2 亿行，全量跑了 4 个多小时。凌晨 3 点的 SLA 从来没达成过。更惨的是，有一次跑了一半源库连接超时，目标表里数据不完整，第二天运营出的报表全是错的。老板拍桌子，我差点背了 P0 事故。
从那以后我明白了一个道理：数据同步不是“搬砖”，而是“绣花”。你选什么策略，直接决定了系统的稳定性、时效性和成本。
核心观点：数据同步的本质是在“数据一致性”和“同步效率”之间找平衡。没有银弹，只有最合适的策略。
1.2 快照同步：简单粗暴，但代价不小
快照同步，说白了就是“全量复制”。
每次同步时，把源端的数据全部读出来，然后覆盖或重建目标端的数据。就像给你的数据库拍一张“定妆照”，每次同步都重新拍一张。
它的工作流程大致是这样：
- 锁定源表（或开启事务快照），防止同步过程中数据被修改。
- 全量读取所有数据行。
- 清空目标表。
- 将全量数据写入目标表。
- 释放锁。
听起来很直接，对吧？但代价也很直接。
| 维度 | 快照同步 |
|---|---|
| 数据量 | 每次传输全部数据，数据量 = 表大小 × 同步次数 |
| 源库压力 | 全表扫描 + 锁表，对 OLTP 系统极不友好 |
| 同步耗时 | 与数据量线性增长，TB 级表基本不可用 |
| 一致性 | 强一致（快照点），但窗口期数据丢失 |
| 实现复杂度 | 低，几乎无状态管理 |
我曾经踩过的坑：有一次用快照同步同步一个 500GB 的日志表，每次跑 2 小时。结果源库是 MySQL 主库，全表扫描导致 CPU 飙到 90%，业务接口超时率暴增。从那以后，我定了个规矩：生产环境主库严禁全表扫描做同步。
1.3 增量同步：只取所需，轻装上阵
增量同步的思路完全不同——它只同步“发生变化”的数据。
你想想看，一个 10 亿行的用户表，每天可能只有 1 万行数据在变动。如果每次都全量同步，99.99% 的数据都是重复劳动。增量同步就是只抓那 0.01% 的变化。
常见的增量同步实现方式：
- 基于时间戳：记录
updated_at字段，只同步大于上次同步时间的数据。 - 基于版本号：每行数据维护一个递增版本号，同步时拉取版本号大于上次记录的数据。
- 基于日志解析（CDC）：解析数据库的 binlog、redo log 等，实时捕获变更事件。
- 基于触发器：在源表上创建触发器，将变更记录写入变更表，然后同步变更表。
| 维度 | 增量同步 |
|---|---|
| 数据量 | 只传输变更数据，通常远小于全量 |
| 源库压力 | 低（时间戳索引扫描）或极低（CDC 异步读取） |
| 同步耗时 | 秒级到分钟级，与变更量相关 |
| 一致性 | 最终一致，需处理乱序和重复 |
| 实现复杂度 | 高，需要维护偏移量、去重、幂等 |
我个人习惯：在业务初期，数据量小于 1000 万行时，我倾向于先用快照同步，简单可靠。当数据量突破 1 亿行，或者同步频率要求小于 10 分钟时，我会果断切换到增量同步。这个阈值是我在多个项目中验证过的经验值。
1.4 快照 vs 增量：一张图看懂核心差异
下面这张图是我自己画的一个对比框架，帮你快速建立直觉。
1.5 什么时候该用哪种？我的经验法则
没有的“好”与“坏”，只有“适合”与“不适合”。我根据自己的项目经验，总结了一个决策矩阵：
| 场景 | 推荐策略 | 理由 |
|---|---|---|
| 首次同步 / 全量初始化 | 快照同步 | 目标表为空，增量无从谈起，必须全量 |
| 小表（< 1000 万行）低频同步 | 快照同步 | 实现简单，维护成本低，全量耗时可接受 |
| 大表（> 1 亿行）高频同步 | 增量同步 | 全量无法满足时效性，必须增量 |
| 源库为 OLTP 主库 | 增量同步（CDC 优先） | 避免锁表和全表扫描影响业务 |
| 需要实时或准实时同步 | 增量同步（CDC） | 快照同步无法做到秒级延迟 |
| 数据一致性要求极高 | 快照同步 + 校验 | 增量同步的乱序和重复问题更难处理 |
我的建议：不要在一开始就追求“纯增量”。我见过太多团队，上来就搞 CDC，结果 binlog 解析搞了两个月，业务早就等不及了。正确的做法是：先用快照同步跑起来，再逐步演进到增量同步。先解决“有没有”，再解决“好不好”。
1.6 一个常见的误区
很多人觉得增量同步一定比快照同步好。其实不一定。
我记得有一次，一个同事非要用增量同步同步一个配置表——总共 200 行数据，每天变更不超过 5 行。他花了两天时间搭了一套 Debezium + Kafka 的 CDC 管道。结果呢？维护成本比全量同步高了 10 倍，而且因为配置表变更频繁，偶尔还会出现乱序导致数据不一致。
我后来跟他说：“200 行的表，全量同步 0.1 秒就搞定了，你折腾 CDC 图啥？”
嗯，这里要注意：技术选型不要炫技，要务实。
1.7 本章小结
- 快照同步：全量复制，简单可靠，但数据量大时效率低、源库压力大。
- 增量同步：只传变更，高效轻量，但实现复杂，需要处理乱序和重复。
- 选型原则：小表用快照，大表用增量；首次用快照，后续用增量；OLTP 主库优先用 CDC 增量。
- 最佳实践：先跑通，再优化。不要为了“技术先进”而过度设计。