1. CDC 技术概述
CDC,全称 Change Data Capture,中文叫变更数据捕获。说白了,就是实时监听数据库的变化——谁插入了新订单、谁修改了用户信息、谁删了一条记录,CDC 都能第一时间告诉你。
我最早接触 CDC 是在 2018 年,当时要做一个实时数仓项目。业务方要求「数据变更后 5 秒内必须看到」,传统 ETL 根本扛不住。后来调研了一圈,发现 CDC 才是正解。
核心思想:CDC 不依赖业务代码写双写逻辑,也不靠定时任务全量扫描。它直接从数据库的事务日志或 binlog 里捞变更事件,对源库几乎零侵入。
1.1 CDC 的应用场景
这些年我见过的 CDC 落地场景,大致可以归为以下几类:
- 实时数仓 & 数据湖入湖:MySQL/PostgreSQL 的变更实时同步到 Kafka,再入湖到 Iceberg 或 Hudi。我做过一个日活千万的电商项目,订单表每秒变更上千次,全靠 CDC 撑住。
- 缓存失效与刷新:数据库更新后,CDC 触发 Redis 缓存淘汰或预热。嗯,这里要注意——如果缓存和数据库双写,很容易出现不一致,CDC 反而更可靠。
- 跨机房/跨数据库同步:从 MySQL 同步到 Elasticsearch,或者从 Oracle 同步到 ClickHouse。我曾经帮一个金融客户做 Oracle 到 Kafka 的 CDC,延迟控制在 200ms 以内。
- 微服务事件驱动:订单状态变更后,通过 CDC 发布事件,下游服务订阅处理。说白了,就是替代业务代码里到处埋点发 MQ 的做法。
- 审计与合规:记录所有数据变更历史,用于事后追溯。这个场景对数据完整性要求极高,丢一条都不行。
我的经验:选 CDC 场景时,先问自己三个问题——数据量级多大?延迟要求多高?源库类型是什么?这三个问题决定了你选哪种 CDC 方案。
1.2 CDC 主流技术对比
市面上 CDC 工具不少,但真正在生产环境经得起考验的,我个人觉得就三个:Debezium、Canal、Maxwell。下面这张表是我根据项目经验整理的对比:
| 特性 | Debezium | Canal | Maxwell |
|---|---|---|---|
| 开发方 | Red Hat (开源) | 阿里巴巴 (开源) | Zendesk (开源) |
| 支持数据库 | MySQL、PostgreSQL、MongoDB、Oracle、SQL Server 等 | MySQL (主要)、MariaDB | MySQL、MariaDB |
| 数据格式 | Avro、JSON、Protobuf (通过 Kafka Connect) | JSON (自定义格式) | JSON |
| 输出端 | Kafka (原生集成)、Pulsar、HTTP | Kafka、RocketMQ、TCP 直连 | Kafka、Kinesis、RabbitMQ、HTTP |
| DDL 变更支持 | 部分支持 (MySQL 较全) | 支持 | 不支持 |
| 断点续传 | 支持 (基于 offset) | 支持 (基于 position) | 支持 (基于 binlog 位置) |
| 社区活跃度 | 非常高 | 高 | 中等 |
| 部署复杂度 | 中等 (依赖 Kafka Connect) | 低 (独立 Java 进程) | 低 (独立 Java 进程) |
1.3 三大工具深度解析
Debezium
Debezium 是我目前最常用的 CDC 工具。它基于 Kafka Connect 框架,天生就是为流式数据管道设计的。你想想看,一个工具能同时支持 MySQL、PostgreSQL、MongoDB、Oracle,而且输出格式标准化,这在多数据源场景下太香了。
我曾经在一个跨国电商项目中用 Debezium 同步 MySQL 到 Kafka,日均处理 2 亿条变更事件。最头疼的是 MySQL 大事务——一个事务更新 10 万行,Debezium 会拆成 10 万条独立事件,下游消费端差点被打爆。后来我加了事务缓冲和批量合并,才算稳住。
Debezium 的核心优势:生态丰富、多数据库支持、与 Kafka 深度集成。适合中大型团队,尤其是已经上了 Kafka 的架构。
Canal
Canal 是阿里巴巴开源的,国内用得非常多。它只支持 MySQL(以及 MariaDB),但胜在轻量和易用。部署就是一个 Java 进程,配置好数据库连接和 binlog 位置就能跑。
我记得有个创业公司的项目,数据量不大但要求快速上线。我推荐了 Canal,从部署到跑通只花了半天。不过要注意——Canal 的 DDL 变更支持虽然比 Maxwell 好,但遇到复杂的 ALTER TABLE 还是可能丢事件。我曾经踩过这个坑,后来加了 DDL 事件告警才放心。
避坑指南:Canal 默认的 JSON 格式比较「阿里系」,字段命名和结构跟 Debezium 不一样。如果你后续要切换工具,数据格式兼容性是个大问题。我建议一开始就做一层格式标准化。
Maxwell
Maxwell 是 Zendesk 开源的,同样只支持 MySQL。它的特点是输出格式非常简洁,就是一个 JSON 串,包含 database、table、type、data 等字段。对于简单的同步场景,Maxwell 上手最快。
但 Maxwell 有个硬伤——不支持 DDL 变更。如果你需要监听表结构变化,Maxwell 直接 pass。另外,它的社区活跃度不如前两者,遇到问题可能要靠自己啃源码。我个人只在一些边缘场景用过 Maxwell,比如日志量不大的审计同步。
我的选型建议:
- 多数据库、大规模、已有 Kafka → Debezium
- 纯 MySQL、轻量级、快速上线 → Canal
- 纯 MySQL、只做简单同步、不关心 DDL → Maxwell
1.4 CDC 核心流程与架构
不管用哪个工具,CDC 的核心流程都差不多。我画了一张图,帮你理清整体逻辑:
这个流程看起来简单,但实际落地时坑不少。比如 binlog 格式必须设置为 ROW 模式,否则 CDC 拿不到完整的数据变更。我曾经遇到一个项目,DBA 为了省空间把 binlog 设成了 STATEMENT 模式,结果 CDC 解析出来的全是 SQL 语句,根本没法用。
注意事项:
- MySQL 必须开启 binlog,且格式为 ROW
- binlog 保留天数要足够长,防止 CDC 断连后追不上
- CDC 工具需要 REPLICATION SLAVE 权限
- 大事务会产生大量变更事件,建议设置事务缓冲
1.5 选型决策树
最后,我总结了一个简单的选型决策树,帮你快速定位:
- 源库只有 MySQL?
- 需要 DDL 支持 → Canal
- 不需要 DDL → Maxwell 或 Canal 都行
- 源库有多种数据库? → Debezium
- 团队已有 Kafka 基础设施? → Debezium(原生集成)
- 团队没有 Kafka,也不想引入? → Canal(可直连 TCP)
- 数据量极大(日均亿级)? → Debezium + Kafka,注意分区策略
- 快速验证/POC? → Maxwell,十分钟跑通