1. CDC 概念与全貌

大家好，我是老赵。做数据同步这行十几年了，今天咱们聊聊 CDC。

CDC 全称是 Change Data Capture，翻译过来叫「变更数据捕获」。说白了，就是实时监听数据库里的数据变化——谁插入了新记录、谁改了字段、谁删了一行，CDC 都能第一时间抓到，然后推给下游系统。

我记得刚入行那会儿，做数据同步全靠定时跑批。每天凌晨两点跑一次，数据延迟至少几个小时。业务方天天抱怨报表不准，我也很无奈。后来接触到 CDC，才真正体会到什么叫「实时」。嗯，这玩意儿确实是个好东西。

1.1 为什么需要 CDC？

你想想看，现代业务系统越来越复杂，数据散落在各个数据库、消息队列、缓存里。怎么让这些系统保持数据一致？怎么把交易数据实时同步到数仓？怎么在用户修改信息后立刻更新缓存？

传统做法是写双写代码——业务逻辑里同时更新数据库和缓存。但这样耦合太深，出问题很难排查。我在一个电商项目里就踩过这个坑：订单服务既要写 MySQL，又要写 Redis，还要发 MQ。结果有一次缓存集群挂了，订单服务也跟着阻塞，差点酿成生产事故。

CDC 的价值就在这里——它把数据同步从业务代码中剥离出来，变成一个独立的基础设施层。源库只管写数据，CDC 负责捕获变更并分发到各个目标端。解耦、可靠、可观测。

1.2 CDC 的典型应用场景

这些年我经手的项目里，CDC 主要用在三个方向。我一个个说。

场景一：数据仓库实时入仓

这是最经典的应用。传统数仓用 Sqoop 或 DataX 做离线全量同步，每天 T+1。但业务方越来越不能忍——老板要看今天的实时销售额，运营要监控秒级的下单量。

用 CDC 把 MySQL binlog 实时同步到 Kafka，然后通过 Flink 写入 ClickHouse 或 StarRocks。延迟从 24 小时降到秒级。我在某金融公司做过一个项目，CDC 链路每天处理 2 亿条变更记录，数仓查询响应时间控制在 200 毫秒以内。

场景二：缓存更新

缓存和数据库的一致性是个老大难问题。很多团队用「先更新数据库，再删除缓存」的策略，但并发场景下还是会有脏数据。

我的做法是：数据库变更后，CDC 捕获到 binlog，然后通过 MQ 通知缓存服务做增量更新。这样即使业务代码有 bug，缓存也能自动跟上数据库的变化。我曾经帮一个社交平台改造过缓存同步方案，把缓存命中率从 82% 提升到了 97%。

场景三：微服务解耦

微服务之间最怕强依赖。订单服务调用库存服务，库存服务挂了订单也失败——这种连锁故障我见过太多次了。

用 CDC 可以做一个事件总线：订单服务只管写自己的数据库，CDC 捕获订单变更后发布到 Kafka，库存服务、支付服务、物流服务各自订阅自己关心的事件。服务之间不再直接调用，耦合度大大降低。

1.3 CDC 主流工具对比

市面上 CDC 工具不少，我挑四个最常用的说说。每个我都用过，有些坑也是真金白银踩出来的。

工具	数据源	同步模式	消息格式	高可用	学习成本
Canal	MySQL	binlog 解析	protobuf / 自定义	依赖 ZooKeeper	低
Debezium	MySQL、PG、MongoDB、Oracle 等	binlog / WAL / oplog	JSON / Avro（Confluent Schema Registry）	内置 Kafka Connect	中
Maxwell	MySQL	binlog 解析	JSON	依赖 Kafka / RabbitMQ	低
DataX	MySQL、Oracle、HDFS、Hive 等 30+ 种	离线全量 + 增量（非实时）	无固定格式	无	低

Canal

阿里巴巴开源的项目，国内用得最多。只支持 MySQL，但生态很成熟。我最早用 Canal 是在 2016 年，那时候版本还比较糙，连 HA 都要自己搭。现在好多了，Canal 1.1.5 以后稳定性提升很大。

优点：部署简单，文档中文友好，社区活跃。适合 MySQL 单数据源场景。

缺点：只支持 MySQL，消息格式不够标准，和 Kafka 集成需要额外配置。

Debezium

Red Hat 主导的项目，目前是 CDC 领域的事实标准。支持多种数据库，基于 Kafka Connect 架构，天然具备高可用和 Exactly-Once 语义。

我个人更倾向 Debezium，尤其是多数据源场景。去年帮一个跨国电商做全球数据同步，源端有 MySQL、PostgreSQL、MongoDB，一套 Debezium 全搞定。不过学习曲线确实比 Canal 陡一些，Kafka Connect 的概念需要花时间理解。

优点：多数据源支持、标准消息格式、强一致性、活跃社区。

缺点：依赖 Kafka 生态、部署配置较复杂、排障需要一定经验。

Maxwell

Zendesk 开源的项目，理念和 Canal 类似，但输出格式更友好——直接输出 JSON。我见过不少中小团队用 Maxwell，因为它真的简单：一个 jar 包跑起来，输出到 Kafka 或 RabbitMQ 就行。

优点：极简部署、JSON 格式易消费、内存占用低。

缺点：只支持 MySQL、功能相对单一、大流量下稳定性不如 Debezium。

DataX

严格来说 DataX 不是 CDC 工具，它是离线同步工具。但很多团队把它和 CDC 配合使用——先用 DataX 做全量初始化，再用 Canal 或 Debezium 做增量同步。这个组合拳我用了很多年，效果不错。

优点：数据源极其丰富、同步效率高、配置灵活。

缺点：不支持实时增量、无高可用机制、不适合流式场景。

1.4 CDC 整体架构图

说了这么多，咱们用一张图把 CDC 的全貌串起来。下面这张 SVG 图展示了 CDC 的核心链路：从源数据库到目标系统的完整数据流转。

这张图把 CDC 的完整链路画清楚了。从左到右：源数据库产生日志，CDC 工具解析日志并发送到消息队列，消费端从消息队列拉取数据并写入目标系统。而监控告警贯穿整个链路——这也是咱们这门课的核心。

1.5 选型建议

说了这么多工具，到底怎么选？我根据实际经验给几个建议：

• 单数据源、团队小、求快：选 Canal 或 Maxwell。部署简单，半天就能跑起来。
• 多数据源、对一致性要求高：选 Debezium。虽然配置复杂点，但长期看省心。
• 需要全量+增量配合：用 DataX 做全量初始化，Debezium 或 Canal 做增量同步。
• 如果你们已经在用 Kafka：优先考虑 Debezium，和 Kafka Connect 天然集成。