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 的核心流程都差不多。我画了一张图,帮你理清整体逻辑:

CDC 实时同步核心流程 源数据库 MySQL / PostgreSQL / Oracle Binlog / WAL 日志 CDC 工具 Debezium / Canal / Maxwell 消息队列 Kafka / Pulsar 目标存储 Lakehouse / ES / Redis 流程说明: ① 源数据库产生变更,写入 Binlog/WAL 日志 ② CDC 工具模拟 Slave 节点,实时读取日志并解析为变更事件 ③ 变更事件发送到消息队列,下游消费者按需处理

这个流程看起来简单,但实际落地时坑不少。比如 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,十分钟跑通