1. Debezium入门：从Binlog到实时同步
1.1 什么是CDC？
CDC，全称是Change Data Capture，中文叫「变更数据捕获」。说白了，就是监听数据库的变化，然后把变化实时同步到别的地方去。
我刚开始接触这个概念时，觉得它不就是个数据同步工具吗？后来踩过坑才明白——CDC解决的是「如何在不影响业务库的前提下，拿到每一笔数据变更」这个核心问题。
举个例子：你的订单表每秒钟产生几百条新记录，业务系统需要实时更新缓存、同步到搜索引擎、推送消息通知。如果每次都用定时任务去扫表，性能扛不住，还会给数据库造成额外压力。CDC就是干这个的——它监听数据库的Binlog（二进制日志），把每一次INSERT、UPDATE、DELETE都捕获下来，推给下游系统。
CDC的核心价值：
- 实时性高——毫秒级延迟，不是分钟级
- 对源库无侵入——只读日志，不查表
- 保证数据完整性——每条变更都有记录，不会丢
1.2 Debezium简介
Debezium是一个开源的分布式CDC平台，基于Kafka Connect构建。它支持MySQL、PostgreSQL、MongoDB、SQL Server等多种数据库。
我记得第一次用Debezium时，最让我惊讶的是它的配置极其简单——只要告诉它「我要监听哪个数据库的哪些表」，它就能自动捕获变更并推送到Kafka。不需要写一行代码。
Debezium的核心能力：
- 全量+增量同步——先做一次快照，然后持续监听增量变更
- Exactly-Once语义——每条变更至少投递一次，不会重复
- Schema演进——表结构变了，Debezium会自动适配
- 容错与断点续传——挂了重启，从上次中断的位置继续
我的经验：Debezium对MySQL的支持最成熟。如果你刚开始接触CDC，建议先从MySQL入手。我在项目中遇到过用Debezium同步PostgreSQL的情况，配置稍微复杂一些，但稳定性同样不错。
1.3 核心概念与架构
要理解Debezium，先搞懂几个关键概念：
| 概念 | 说明 |
|---|---|
| Connector | 连接器，负责连接源数据库并捕获变更 |
| Snapshot | 快照，首次启动时读取表的全量数据 |
| Change Event | 变更事件，每条数据变更对应一个事件 |
| Offset | 偏移量，记录当前读取到Binlog的哪个位置 |
| Topic | Kafka主题，Debezium把变更事件写入Kafka Topic |
Debezium的架构其实不复杂。你想想看，它本质上是一个Kafka Connect的Source Connector。数据流向是这样的：
- Debezium Connector连接到源数据库
- 读取Binlog（或WAL日志）
- 把变更解析成结构化的Change Event
- 写入Kafka的指定Topic
- 下游消费者从Kafka消费这些事件
下面这张图可以帮你直观理解整个流程：
嗯，这里要注意一个细节：Debezium不是直接连数据库查表，而是读Binlog。这意味着它对源库几乎没有性能影响。我在项目中见过有人用定时任务每秒扫一次表，数据库CPU直接飙到80%。换成Debezium后，CPU降到5%以下。
1.4 应用场景
Debezium能干什么？我总结了几类最常见的场景：
- 缓存同步——数据库更新后，自动刷新Redis缓存
- 搜索引擎索引——数据变更后，实时更新Elasticsearch索引
- 数据仓库实时入仓——把MySQL数据实时同步到ClickHouse或Doris
- 微服务事件驱动——订单创建后，通过Debezium触发库存扣减、物流通知
- 审计日志——记录所有数据变更，用于合规审计
避坑指南：我曾经在一个项目中，直接把Debezium的Change Event原封不动地写入Elasticsearch，结果发现DELETE事件处理起来很麻烦——因为ES不支持直接删除文档的某个字段。后来我加了一层转换逻辑，把DELETE事件转成ES的删除请求。这个坑，你早晚也会遇到。
说白了，Debezium就是数据库和下游系统之间的「实时管道」。它让数据流动起来，而不是躺在数据库里等着被定时任务扫走。
我个人习惯在项目初期就引入Debezium，而不是等到数据同步出问题再补救。你想想看，如果业务量上来了，再想从定时任务切换到实时同步，迁移成本会高很多。