1. CDC技术概述：什么是CDC、核心价值与数据保护角色
1.1 什么是CDC？从一次数据库迁移说起
先讲个故事。几年前我接手一个金融核心系统的迁移项目，要求把Oracle迁移到MySQL，停机窗口只有4小时。传统做法是：停服→全量导出→导入→增量补数→校验→切流。结果呢？全量导出花了3小时，导入又花了2小时，增量数据积压了上千万条，最后切流时发现数据不一致，回滚了。
问题出在哪？增量补数阶段，我们用的是时间戳+批处理扫描，每次扫描都要全表扫一遍，性能差、延迟高、还容易丢数据。后来我换了个思路——用CDC（Change Data Capture，变更数据捕获）。
CDC说白了就是一套技术机制，它能实时捕获数据库中的数据变更事件（插入、更新、删除），然后把这些变更以流式的方式推送给下游系统。你想想看，这不就是给数据库装了个"监控摄像头"吗？
CDC的核心定义：一种通过解析数据库日志或触发器，实时捕获数据变更并同步到目标系统的技术方案。它让数据从"批处理搬运"变成了"流式实时同步"。
我个人的理解更简单：CDC就是数据库的"日志监听器"。它不侵入业务代码，不增加数据库负载，却能让你知道每一行数据是什么时候、被谁、怎么改的。
1.2 CDC的核心价值：为什么大家都在用？
这些年我接触过几十个数据同步项目，总结下来CDC有四个核心价值，缺一不可。
- 实时性：从秒级到毫秒级延迟。传统ETL跑一次要几十分钟，CDC能做到数据一变，下游立刻感知。我在电商大促场景中见过CDC把延迟压到200毫秒以内。
- 低侵入性：不需要改业务代码，不需要加字段，不需要写触发器。CDC直接读数据库的binlog或redo log，对源库几乎零影响。
- 一致性保障：基于日志的CDC能保证"至少一次"或"精确一次"的语义。不会丢数据，不会重复消费。嗯，这里要注意，不同工具的实现方式不同，后面我会细讲。
- 全量+增量一体化：好的CDC工具支持先做全量快照，再无缝切换到增量同步。整个过程对业务透明，不需要停服。
我的经验：判断一个CDC方案好不好，就看三点——延迟能不能接受、数据会不会丢、运维复不复杂。其他都是锦上添花。
1.3 CDC在数据保护中的角色
很多人以为CDC只是做数据同步的，其实它在数据保护领域扮演着更重要的角色。我把它归纳为三个层次：
- 灾备层：CDC可以实现跨机房、跨地域的数据库实时备份。源库挂了，备库秒级切换，数据零丢失。我曾经帮一家银行做过同城双活，CDC延迟控制在1秒以内，RPO（恢复点目标）几乎为零。
- 审计层：CDC捕获的每一条变更都包含操作类型、时间戳、旧值、新值。这些数据可以直接用于合规审计、数据溯源。说白了，谁改了数据、改了什么、什么时候改的，一清二楚。
- 恢复层：基于CDC的变更日志，可以实现"任意时间点恢复"。比如误删了一张表，不用全量恢复，直接从CDC日志里回放变更就能找回数据。我遇到过开发误操作删了生产库的配置表，靠CDC日志5分钟就恢复了。
避坑指南：CDC不是银弹。它不能替代全量备份，也不能解决逻辑错误（比如业务代码写入了错误数据）。我曾经见过一个团队完全依赖CDC做灾备，结果源库磁盘坏了，CDC日志也丢了——因为没有做日志的异地备份。记住：CDC是数据保护体系的一部分，不是全部。
1.4 常见CDC工具对比
市面上CDC工具不少，我挑几个主流的说说。先看一张对比表：
| 工具 | 实现方式 | 支持数据库 | 延迟 | 一致性 | 运维复杂度 |
|---|---|---|---|---|---|
| Canal | MySQL binlog解析 | MySQL | 毫秒级 | 至少一次 | 低 |
| Debezium | Kafka Connect + 日志解析 | MySQL、PostgreSQL、MongoDB、Oracle等 | 毫秒级 | 精确一次 | 中 |
| Oracle GoldenGate | Oracle redo log解析 | Oracle、MySQL、SQL Server等 | 秒级 | 精确一次 | 高 |
| Maxwell | MySQL binlog解析 | MySQL | 毫秒级 | 至少一次 | 低 |
| Flink CDC | Debezium + Flink | MySQL、PostgreSQL、MongoDB等 | 毫秒级 | 精确一次 | 中高 |
说说我的使用感受：
- Canal：阿里开源的，轻量好用。如果你只用MySQL，Canal是最快上手的方案。我第一个CDC项目就是用的Canal，部署起来半小时搞定。
- Debezium：社区活跃，生态好。它基于Kafka Connect，天然支持流式处理。我建议新项目优先考虑Debezium，尤其是需要多数据库支持的场景。
- Oracle GoldenGate：商业产品，功能强大但贵。适合大型企业、核心交易系统。我接触过几个银行客户，他们用GoldenGate做核心库的灾备，稳定是稳定，但运维团队至少得配两个人专门管它。
- Maxwell：和Canal类似，但输出格式更灵活。它直接把变更事件输出为JSON，适合对接消息队列。
- Flink CDC：如果你已经在用Flink做流计算，Flink CDC是天然的选择。它把CDC和计算引擎合二为一，省去了中间环节。
选型建议：没有最好的工具，只有最合适的。我的习惯是：小团队、MySQL单库选Canal；中大型项目、多数据库选Debezium；金融核心、不差钱选GoldenGate；已经在用Flink的，直接上Flink CDC。
1.5 CDC技术全景图
为了让你更直观地理解CDC在整个数据体系中的位置，我画了一张架构图：
这张图展示了CDC的完整链路：数据源→日志解析→消息队列→下游应用。你想想看，整个过程不需要改一行业务代码，不需要停服，就能实现数据的准实时同步。这就是CDC的魅力所在。
1.6 本章小结
这一章我们聊了CDC是什么、为什么用、怎么选。核心就三句话：
- CDC是数据库的"日志监听器"，能实时捕获数据变更。
- 它的核心价值是实时性、低侵入性、一致性保障、全量增量一体化。
- 在数据保护中，CDC扮演灾备、审计、恢复三个角色。
工具选型没有标准答案，关键看你的场景和团队能力。我个人建议：从Debezium入手，它生态好、文档全、踩坑的人多，遇到问题容易找到解决方案。