一、CDC概念与Debezium简介

1.1 什么是变更数据捕获（CDC）

变更数据捕获，英文叫 Change Data Capture，简称 CDC。说白了，就是一种能实时捕捉数据库里数据变化的技术。

你想想看，传统做法是轮询——每隔几秒查一次表，看有没有新数据。这方式效率低，延迟高，还容易把数据库查垮。我早期做数据同步时就吃过这个亏，一个订单表几千万行，轮询间隔设短了数据库扛不住，设长了业务又嫌延迟高。

CDC 的思路完全不同。它不主动去查，而是让数据库自己把变化「推」出来。具体来说，CDC 会监听数据库的事务日志（比如 MySQL 的 binlog、PostgreSQL 的 WAL），一旦有 INSERT、UPDATE、DELETE 操作，就立刻捕获到变更事件。

我个人习惯把 CDC 分成两种模式：

• 基于日志的 CDC——解析数据库的事务日志，性能最好，最推荐
• 基于触发器的 CDC——在表上建触发器记录变更，侵入性强，不推荐

Debezium 走的就是第一种路线，而且是目前做得最成熟的方案之一。

1.2 CDC 的应用场景

CDC 能解决什么问题？我列三个最常见的场景，都是我在项目中实际遇到过的。

场景一：数据同步

这是最经典的应用。比如你有一个 MySQL 订单库，需要把数据实时同步到 Elasticsearch 做搜索，或者同步到数据仓库做分析。

传统做法是写 ETL 脚本，每天跑一次全量同步。但业务要求实时性越来越高，每天一次根本不够用。用 CDC 就能做到秒级同步。

场景二：缓存失效

缓存和数据库之间的一致性，是个老难题。常见的做法是更新数据库后手动删除缓存，但总有遗漏的时候。

用 CDC 就优雅多了。数据库一有变更，CDC 自动捕获事件，然后通知缓存层做失效或更新。这样代码里不用再到处写缓存清理逻辑。

场景三：审计日志

很多业务系统需要记录谁在什么时间改了哪条数据。用 CDC 可以自动生成审计日志，不需要业务代码里手动埋点。

我曾经帮一个金融客户做审计系统，他们要求记录所有账户余额的变更历史。用 Debezium 监听账户表，每次余额变更都自动生成一条审计记录，既完整又省事。

总结一下这三个场景：

场景	核心需求	CDC 的优势
数据同步	实时复制到其他系统	低延迟、无侵入
缓存失效	保持缓存与数据库一致	解耦业务代码
审计日志	记录所有数据变更	自动捕获、完整可靠

1.3 Debezium 的定位与核心优势

Debezium 是一个开源的分布式 CDC 平台，基于 Apache Kafka 构建。它的定位很明确：让数据库的变更事件像消息一样被消费。

为什么选 Debezium？我总结几个核心优势：

• 支持多种数据库——MySQL、PostgreSQL、MongoDB、Oracle、SQL Server 等，基本覆盖主流
• 基于 Kafka——天然具备高可用、持久化、顺序保证等能力
• 变更事件结构统一——不管源库是什么，输出的 JSON 格式是一致的
• 断点续传——记录消费偏移量，宕机后从断点恢复，不会丢数据
• Schema 历史——记录表结构的变化，即使字段增减也能正确处理

我记得刚开始接触 Debezium 时，最让我惊艳的是它的「快照」机制。第一次启动时，它会先做一次全量快照，把现有数据全部读出来，然后无缝切换到增量监听。整个过程对业务完全透明。

下面这张图展示了 Debezium 的整体架构和工作流程：

从这张图可以看到，Debezium 的工作流程其实很清晰：

1. 源数据库产生事务日志
2. Debezium Connector 读取日志，解析出变更事件
3. 通过 Kafka Connect 运行时，将事件写入 Kafka 主题
4. 下游消费者从 Kafka 订阅并消费这些事件

嗯，这里要注意一点。Debezium 输出的变更事件包含三个部分：before（变更前的值）、after（变更后的值）、op（操作类型，c=创建，u=更新，d=删除）。这个结构非常清晰，下游系统拿到后可以直接使用。

最后说说 Debezium 的社区和生态。它现在是 Apache 顶级项目，社区非常活跃。支持的连接器越来越多，文档也很完善。我个人觉得，如果你需要做 CDC，Debezium 是目前最值得投入的方案之一。

当然，它也不是银弹。比如对 DDL 变更的支持还不够完美，某些数据库的特定类型处理起来有坑。这些我会在后面的章节里详细讲。