3. CDC 工具选型：常见工具对比与我的实战经验
选 CDC 工具，说白了就是选「数据管道的心脏」。我见过不少团队，一上来就追新工具，结果跑了两周发现延迟对不上、数据丢了一堆，最后还得回退重来。这一章，我把自己这些年踩过的坑、对比过的工具，以及选型时的核心考量，一次性讲清楚。
3.1 主流 CDC 工具速览
目前市面上用得最多的 CDC 工具，基本就这四个：Debezium、Canal、Maxwell、Flink CDC。它们都能抓取数据库变更，但底层逻辑和适用场景差别很大。
| 工具 | 核心原理 | 数据源 | 输出格式 | 社区活跃度 |
|---|---|---|---|---|
| Debezium | 基于 Kafka Connect，解析 binlog | MySQL、PostgreSQL、MongoDB、Oracle 等 | Avro / JSON / Protobuf | ★★★★★ |
| Canal | 阿里开源，模拟 MySQL slave 拉取 binlog | MySQL（主要）、兼容 MariaDB | JSON / Protobuf | ★★★★☆ |
| Maxwell | 伪装成 MySQL slave，输出 JSON 到 Kafka | MySQL | JSON | ★★★☆☆ |
| Flink CDC | 基于 Debezium 封装，集成 Flink 生态 | MySQL、PostgreSQL、MongoDB 等 | RowData / DataStream | ★★★★☆ |
3.2 逐个拆解：每个工具的特点与坑
3.2.1 Debezium —— 生态最全的「万金油」
Debezium 是我用得最多的工具。它基于 Kafka Connect，天然支持分布式、断点续传、Schema Registry。你想想看，只要配一个 connector，就能把 MySQL 的 binlog 流式推到 Kafka，下游随便消费。
优点：
- 支持的数据源最多，从 MySQL 到 Oracle、SQL Server 都能接
- 社区活跃，文档齐全，遇到问题基本能搜到答案
- 与 Kafka 生态无缝集成，适合已有 Kafka 的团队
缺点：
- 部署依赖 Kafka Connect，运维成本稍高
- 初次配置较复杂，尤其是 DDL 变更处理
schema.history.internal 和 tombstones.on.delete 的配置才稳住。所以，上线前一定要测试 DDL 场景。
3.2.2 Canal —— 阿里出品，MySQL 场景的「老司机」
Canal 是阿里巴巴开源的，专门针对 MySQL binlog 解析。它的核心逻辑很简单：伪装成 MySQL 的 slave，实时拉取 binlog 并解析成 JSON 或 Protobuf。我在早期做埋点同步时用过它，确实轻量。
优点：
- 部署简单，一个 Java 进程就能跑
- 解析性能高，延迟通常在毫秒级
- 支持多维度订阅（数据库、表、字段级别）
缺点：
- 只支持 MySQL，扩展性受限
- 社区更新速度放缓，新特性较少
3.2.3 Maxwell —— 小而美的「轻量选手」
Maxwell 也是一个 MySQL binlog 解析工具，但它比 Canal 更轻。它直接输出 JSON 到 Kafka、Kinesis 或 stdout，不需要额外依赖。我记得第一次用 Maxwell 时，只花了半小时就搭好了从 MySQL 到 Kafka 的管道。
优点：
- 配置极简，一条命令就能启动
- 输出格式清晰，自带 bootstrap 功能（全量+增量）
- 资源占用低，适合小规模场景
缺点：
- 功能相对单一，不支持复杂过滤和转换
- 社区规模小，遇到问题可能要靠自己
3.2.4 Flink CDC —— 流计算时代的「新贵」
Flink CDC 是近几年火起来的，它底层封装了 Debezium，但把数据直接转成 Flink 的 DataStream，省去了 Kafka 这一层。如果你已经在用 Flink 做实时计算，Flink CDC 能让你「一条龙」搞定。
优点：
- 与 Flink 生态深度集成，支持 exactly-once 语义
- 支持动态加表、Schema 变更自动适应
- 全量+增量一体化，无需手动切换
缺点：
- 强依赖 Flink 环境，不适合非 Flink 场景
- 社区版本迭代快，API 变动较大
3.3 选型考量因素：别只看功能列表
选工具不是看谁功能多，而是看谁最适合你的场景。我一般从四个维度来评估：数据源、延迟、一致性、运维成本。
3.3.1 数据源
你的数据源是什么？只有 MySQL，还是混合了 PostgreSQL、MongoDB？如果只有 MySQL，Canal 和 Maxwell 都够用；如果有多源，Debezium 或 Flink CDC 更合适。
3.3.2 延迟
埋点数据对延迟要求通常不高（秒级即可），但如果你做实时风控或交易同步，延迟必须控制在毫秒级。Canal 和 Debezium 在低延迟场景表现最好，Maxwell 稍慢一点。
3.3.3 一致性
这里要特别注意：CDC 工具只能保证「至少一次」或「恰好一次」？Debezium 和 Flink CDC 支持 exactly-once，但需要配合 Kafka 或 Flink 的 checkpoint 机制。Canal 和 Maxwell 默认是 at-least-once，需要下游做去重。
3.3.4 运维成本
说白了，就是你的团队能不能 hold 住。Debezium 依赖 Kafka Connect，需要运维 Kafka 集群；Flink CDC 依赖 Flink 集群；Canal 和 Maxwell 相对独立，运维成本低。我个人习惯：如果团队小，优先选运维简单的工具。
| 考量维度 | Debezium | Canal | Maxwell | Flink CDC |
|---|---|---|---|---|
| 数据源多样性 | ★★★★★ | ★★☆☆☆ | ★★☆☆☆ | ★★★★☆ |
| 延迟 | ★★★★☆ | ★★★★★ | ★★★☆☆ | ★★★★☆ |
| 一致性 | ★★★★★ | ★★★☆☆ | ★★★☆☆ | ★★★★★ |
| 运维成本 | ★★★☆☆ | ★★★★☆ | ★★★★★ | ★★☆☆☆ |
3.4 我的选型经验：一个真实案例
我之前负责一个埋点数据实时同步项目，数据源是 MySQL（埋点事件表），目标端是 Kafka + HBase。当时我对比了四个工具，最终选了 Debezium。原因很简单：
- 团队已经有 Kafka 集群，Debezium 可以直接复用
- 未来可能接入 PostgreSQL，Debezium 支持更好
- 需要 exactly-once 语义，避免埋点数据重复
但我也不是一开始就选对的。早期我试过 Canal，发现它不支持动态加表，每次新增埋点事件都要重启 Canal 实例，太折腾了。后来换成 Debezium，配合 Kafka Connect 的 REST API，加表只需要发一个 POST 请求，省心多了。
- 多数据源、已有 Kafka → Debezium
- 纯 MySQL、轻量部署 → Canal 或 Maxwell
- Flink 生态、需要 exactly-once → Flink CDC
- 小团队、运维能力弱 → Maxwell（最简单）
3.5 选型决策流程图
下面这张图是我自己总结的选型决策流程，你可以照着走一遍，基本不会选错。
3.6 避坑指南：我踩过的几个坑
- 坑一：binlog 格式没配对。 我曾经用 Canal 时，MySQL 的 binlog 格式是 STATEMENT，结果解析出来的数据全是 SQL 语句，根本没法用。记住：CDC 工具要求 binlog 格式必须是 ROW。
- 坑二：全量同步压垮数据库。 有一次用 Debezium 做全量 snapshot，没限流，结果源库 CPU 飙到 100%，业务直接告警。后来我加了
snapshot.fetch.size和max.queue.size参数，才稳住。 - 坑三：忽略 DDL 变更。 埋点表经常加字段，如果 CDC 工具没处理好 DDL，轻则丢数据，重则任务挂掉。Debezium 和 Flink CDC 对 DDL 支持较好，但也要提前测试。