1. Debezium入门：CDC概念、Debezium是什么、核心特性与适用场景、架构概览
1.1 从一个真实问题说起
先讲个我亲身经历的事。几年前我在一家电商公司负责订单系统的数据同步，每天凌晨跑批把MySQL里的订单数据同步到Elasticsearch。业务量上来之后，凌晨的批处理窗口越来越紧张，经常跑到早上八九点还没跑完。更头疼的是，白天用户下单后，ES里的数据要等至少半小时才能搜到——这谁受得了？
后来我接触到了CDC（Change Data Capture），说白了就是「变更数据捕获」。它能让下游系统实时感知数据库的变化，而不是靠定时任务去轮询。嗯，这个思路一下子就解决了我的痛点。
1.2 CDC是什么？
CDC是一种数据同步技术，核心思想是：捕获源数据库中的数据变更事件（插入、更新、删除），并将这些事件实时推送给下游消费者。
常见的CDC实现方式有几种：
| 实现方式 | 原理 | 典型代表 | 我踩过的坑 |
|---|---|---|---|
| 基于触发器 | 在源表上创建触发器，记录变更到日志表 | 自建方案 | 对源库性能影响大，生产环境慎用 |
| 基于时间戳 | 在表中增加更新时间戳字段，轮询查询 | 自建方案 | 无法捕获删除操作，延迟取决于轮询间隔 |
| 基于日志解析 | 解析数据库的事务日志（如MySQL的binlog） | Debezium、Canal | 对源库无侵入，推荐使用 |
核心结论：基于日志解析的CDC是目前生产环境最成熟、最可靠的方式。它不侵入业务表结构，不增加源库负载，还能保证数据一致性。
1.3 Debezium是什么？
Debezium是一个开源的分布式CDC平台，基于Apache Kafka构建。它的核心能力是：把数据库的变更事件转换成Kafka消息，让下游应用可以实时消费这些变更。
我个人习惯把Debezium比作「数据库的监控摄像头」——它24小时盯着你的数据库，一旦有数据变化，立刻录下来（生成事件），然后通过Kafka广播出去。
Debezium目前支持的数据库包括：
- MySQL / MariaDB — 解析binlog
- PostgreSQL — 解析WAL（Write-Ahead Log）
- MongoDB — 解析oplog
- Oracle — 解析LogMiner或XStream
- SQL Server — 解析CDC表或变更跟踪
- Db2 / Cassandra / Vitess 等
我的建议：如果团队刚开始接触CDC，先从MySQL或PostgreSQL入手。这两个数据库的Debezium连接器最成熟，社区文档也最全。我当年就是从MySQL起步的，踩坑少，上手快。
1.4 核心特性
Debezium能成为CDC领域的标杆，靠的是下面这几个硬核特性：
- 低延迟 — 从数据库提交事务到Kafka收到事件，延迟通常在毫秒级。我实测过MySQL场景，平均延迟在50ms以内。
- 断点续传 — 连接器会记录已消费的binlog位置（offset）。即使进程重启或崩溃，也能从断点处继续消费，不会丢数据。
- Exactly-Once语义 — 结合Kafka的事务机制，可以保证每条变更事件恰好被处理一次。
- Schema演进 — 数据库表结构变更（如新增字段）时，Debezium能自动感知并更新事件Schema。
- 无侵入 — 不需要修改业务表结构，不需要在源库安装任何插件（PostgreSQL除外，需要开启逻辑复制）。
- 高可用 — 支持Kafka Connect的分布式模式，多个Worker节点可以组成集群，实现故障转移。
注意：Debezium的Exactly-Once语义依赖于Kafka的事务特性。如果你的Kafka集群版本低于2.5，或者没有开启事务支持，这个特性是无法保证的。我曾经在一个老版本Kafka集群上踩过这个坑，数据重复消费了整整一天才被发现。
1.5 适用场景
根据我这几年的实战经验，Debezium最适合以下场景：
| 场景 | 说明 | 我遇到的真实案例 |
|---|---|---|
| 缓存同步 | 数据库变更后实时更新Redis/ES缓存 | 订单数据同步到ES，搜索延迟从30分钟降到1秒 |
| 数据仓库实时入仓 | 将OLTP数据库的变更实时同步到数仓（如ClickHouse、Snowflake） | 用户行为数据实时入仓，报表延迟从T+1降到秒级 |
| 微服务间数据同步 | 一个微服务的数据库变更，通过事件驱动其他微服务 | 订单服务变更后，通知库存服务、物流服务 |
| 审计与合规 | 记录所有数据变更历史，用于审计追踪 | 金融交易流水变更的完整审计链路 |
| 数据库迁移 | 不停机将数据从旧库迁移到新库 | MySQL迁移到TiDB，零停机完成 |
一句话总结：只要你的业务需要「数据库一变化，下游马上知道」，Debezium就是最合适的工具。
1.6 架构概览
Debezium的架构其实不复杂，核心就三层。我画了一张图帮你理解：
这张图展示了Debezium的核心数据流：
- 源数据库：产生变更日志（binlog/WAL/oplog）
- Debezium连接器：运行在Kafka Connect上，负责解析日志并生成Change Event
- Kafka：作为事件总线，持久化存储变更事件
- 下游消费者：从Kafka消费事件，实现缓存同步、数据入仓等业务逻辑
我的经验：在实际部署中，Kafka Connect建议以分布式模式运行，至少2个Worker节点。这样即使一个节点挂了，连接器会自动迁移到其他节点，业务无感知。我见过不少团队图省事用单机模式，结果Worker一挂，整个数据管道就断了。
1.7 小结
这一章我们聊了CDC的概念、Debezium的核心能力、适用场景和整体架构。说白了，Debezium就是帮你把数据库的变更「实时地、可靠地」搬到Kafka里，然后让下游系统各取所需。
我个人觉得，Debezium最大的价值在于「解耦」——它让数据生产者和消费者不再强绑定，数据库只管写，下游只管读，中间通过Kafka异步通信。这种架构在微服务和实时数据场景下，几乎是标配。