1. CDC技术全景与架构演进：从批处理到实时流
大家好，我是老张。做数据架构十几年了，今天咱们聊聊CDC——这个在实时数据领域绕不开的话题。
CDC，全称Change Data Capture，说白了就是“逮住数据的变化”。你想想看，业务系统每天都在产生数据，订单、用户、库存……这些数据怎么实时同步到数仓、缓存或者搜索引擎？CDC就是干这个的。
我刚开始做数据同步那会儿，哪有什么CDC工具。都是半夜跑批处理，把全量数据导一遍。后来业务要求实时性越来越高，批处理扛不住了，才慢慢演变成今天的实时流架构。
1.1 从批处理到实时流：CDC技术发展史
CDC的发展，大致经历了三个阶段。我画了张图，帮你快速建立整体认知。
阶段一：批处理时代（2000-2010年）
那时候做数据同步，最常用的就是ETL工具。每天凌晨跑一个定时任务，把业务库的数据全量拉一遍。或者用时间戳字段，增量抽取当天变更的数据。
我记得有一次，业务方要求数据延迟不超过1小时。我们硬是用了触发器+中间表的方式，每15分钟跑一次增量同步。结果生产库的触发器一多，主库性能直接掉了30%。嗯，那会儿真是踩坑踩出来的经验。
阶段二：日志解析时代（2010-2018年）
转折点出现在MySQL Binlog和Oracle Redo Log的解析技术成熟。大家发现，与其在业务库上折腾，不如直接读数据库的变更日志。这样对源库零侵入，性能影响几乎可以忽略。
这个阶段，Canal和Maxwell成了主流。Canal是阿里巴巴开源的，专为MySQL Binlog解析而生。Maxwell则更轻量，直接输出JSON到Kafka。我2015年在某电商公司做订单同步，就是用Canal把Binlog实时打到Kafka，再消费写入HBase。延迟从小时级降到了秒级。
阶段三：流式CDC时代（2018年至今）
到了2018年以后，事情又变了。Debezium横空出世，它基于Kafka Connect框架，天然支持分布式部署和故障恢复。Flink CDC更是把CDC和流计算合二为一，直接在Flink里解析Binlog，还能做全量+增量一体化同步。
说白了，现在的CDC已经不是简单的数据搬运了。它要解决的是：如何在海量数据、高并发场景下，做到数据不丢、不重、顺序不乱。这就是我们这门课要讲的核心。
1.2 主流CDC工具对比
市面上CDC工具不少，但真正能在生产环境扛得住的，就那么几个。我列了个对比表，你一看就明白。
| 特性 | Debezium | Canal | Maxwell | Flink CDC |
|---|---|---|---|---|
| 开源方 | Red Hat | 阿里巴巴 | Zendesk | Apache Flink社区 |
| 支持数据库 | MySQL、PostgreSQL、MongoDB、Oracle、SQL Server等 | MySQL（主要） | MySQL | MySQL、PostgreSQL、MongoDB、Oracle等 |
| 架构模式 | Kafka Connect Connector | 独立Server + Client | 独立进程 + Kafka Producer | Flink Source Operator |
| 数据输出 | Kafka（Avro/JSON/Protobuf） | 自定义TCP/Adapter | Kafka（JSON） | DataStream API |
| Exactly-Once | 支持（Kafka事务） | 有限支持 | 有限支持 | 原生支持 |
| 全量+增量一体化 | 支持（Snapshot + Streaming） | 需手动切换 | 需手动切换 | 原生支持 |
| 高可用 | Kafka Connect集群 | 多Server + ZooKeeper | 多实例 + 心跳检测 | Flink Checkpoint |
| 学习成本 | 中（需理解Kafka Connect） | 低 | 低 | 中（需Flink基础） |
我的选型建议：
如果你的技术栈已经上了Kafka，Debezium是首选。它生态成熟，社区活跃，支持数据库种类多。我目前在做的几个项目，核心链路全是用Debezium。
如果只是MySQL同步到Kafka，团队又不想引入太多组件，Maxwell够用了。它轻量、简单，部署起来半小时搞定。
如果你们已经在用Flink做流计算，Flink CDC是最自然的。它把CDC和计算合在一起，少了一层网络开销。
Canal嘛……说实话，我在2017年之后就没怎么用了。不是它不好，而是Debezium和Flink CDC在架构设计上更现代。
1.3 企业级CDC架构选型方法论
工具选型这事儿，不能光看技术指标。我在企业里做架构评审，一般会从四个维度来评估。
维度一：数据源兼容性
你的业务库是什么？MySQL？Oracle？还是混合的？Debezium支持最广，Flink CDC次之。如果源库是Oracle，Canal和Maxwell基本不用考虑。
维度二：数据一致性要求
金融场景要求Exactly-Once，丢一条数据都不行。这时候Flink CDC和Debezium是首选，它们有原生的分布式事务保证。我曾经在支付对账项目里，因为用了不支持Exactly-Once的工具，导致对账不平，排查了整整三天……后来果断换了Debezium。
维度三：运维复杂度
团队规模小，运维能力弱？那就选Maxwell或者Canal，部署简单，监控也容易。团队有专门的SRE？Debezium + Kafka Connect集群可以玩出花来，自动扩缩容、故障转移、灰度发布都能做。
维度四：生态集成
下游是Kafka？还是Flink？还是直接写HBase？Debezium天然对接Kafka Connect生态，Flink CDC直接输出DataStream。选型时要考虑整个数据管道的连贯性，别让CDC工具成为孤岛。
我的选型决策树（简化版）：
- 源库是MySQL，下游是Kafka → Debezium 或 Maxwell
- 源库是Oracle/PostgreSQL/MongoDB → Debezium
- 团队已有Flink集群，需要全量+增量一体化 → Flink CDC
- 要求Exactly-Once语义 → Debezium 或 Flink CDC
- 团队小，追求简单 → Maxwell
避坑指南：
我曾经见过一个项目，选了Canal做Oracle同步。结果Canal对Oracle的支持很有限，最后不得不自己写解析器。所以，选型前一定要确认工具对目标数据库的版本兼容性。
还有，别迷信“全量+增量一体化”。有些工具的一体化是假的，全量阶段会锁表。生产环境一定要在低峰期做全量，或者用GTID/SCN机制避免锁表。
好了，这一章我们梳理了CDC的发展脉络和主流工具。从批处理到实时流，从Canal到Debezium再到Flink CDC，技术一直在演进。但核心问题没变：怎么在分布式环境下，把数据变更可靠、高效地传递到下游。