1. CDC 概念与场景：从采集到应用的全链路起点
各位同学，咱们正式开始这门课之前，先聊一个最基础的问题：CDC 到底是什么？
CDC，全称 Change Data Capture，中文叫「变更数据捕获」。说白了，就是实时监听数据库里的数据变化——谁插入了新记录、谁改了字段、谁删了一行，CDC 都能第一时间抓到，然后把这些变化推出去。
我最早接触 CDC 是在 2016 年，当时做一个电商实时数仓项目。业务方要求「下单后 5 秒内看到订单数据进入数仓」，用传统 ETL 跑批根本做不到。嗯，那时候我才意识到，CDC 不是锦上添花，而是刚需。
一句话总结：CDC 让数据从「定时搬运」变成「实时流动」。
1.1 为什么需要 CDC？
你想想看，传统的数据同步怎么做？
- 定时批量同步：每天凌晨跑一次 ETL，把业务库数据全量拉到数仓。缺点很明显——延迟至少一天，而且全量扫描对源库压力很大。
- 应用双写：业务代码里同时写数据库和缓存/ES。问题是耦合度高，一旦一方失败，数据就不一致了。
CDC 解决了这两个痛点：
- 低延迟：秒级甚至毫秒级捕获变更，不用等批处理窗口。
- 无侵入：CDC 读取数据库的日志（比如 MySQL 的 binlog、PostgreSQL 的 WAL），不需要改业务代码。
- 高可靠：日志是数据库原生机制，只要日志不丢，数据就不会丢。
我在项目中遇到过一种情况：某团队用应用双写同步数据到 Elasticsearch，结果业务代码里有个 bug，导致 ES 里多了几万条脏数据。后来换成 CDC 方案，直接从 binlog 消费，再也没出过这种问题。
我的建议：只要你的场景允许读数据库日志，优先用 CDC。别在业务代码里搞「双写」，那是给自己挖坑。
1.2 CDC 的典型应用场景
CDC 能做的事，比你想象的多。我挑三个最常用的场景讲讲。
场景一：数据仓库实时入仓
这是 CDC 最经典的应用。传统数仓每天 T+1 更新，但业务方越来越不能忍——老板要看今天的实时销售额，运营要监控活动效果，风控要实时拦截异常交易。
CDC 的做法是：监听业务库的变更日志，实时写入 Kafka，然后从 Kafka 消费写入数仓（比如 ClickHouse、Doris、Hudi）。
我曾经帮一个金融客户做实时数仓，他们原来的批处理任务要跑 4 小时，换成 CDC 后，延迟降到 3 秒以内。你想想看，这对业务决策意味着什么。
场景二：缓存更新
缓存和数据库的一致性，是个老生常谈的问题。常见的做法是「先更新数据库，再删除缓存」，但总有并发问题导致缓存里是旧数据。
CDC 提供了一种更优雅的方案：
- 数据库发生变更后，CDC 捕获到变更事件。
- 把事件发到消息队列。
- 消费者根据事件内容，更新或失效对应的缓存 key。
这样做的好处是：缓存更新逻辑和业务代码完全解耦。你甚至可以用同一个 CDC 管道同时更新 Redis、CDN 预热、搜索引擎索引。
注意：CDC 更新缓存时，要处理好「先更新数据库还是先更新缓存」的顺序问题。我一般建议：让 CDC 消费者等数据库事务提交后再处理，避免读到未提交的数据。
场景三：微服务解耦
微服务之间怎么共享数据？最粗暴的方式是服务 A 直接调用服务 B 的 API 写入数据。但这样耦合太紧——服务 B 挂了，服务 A 也写不进去。
CDC 的思路是：让数据通过事件流动。
- 服务 A 只写自己的数据库。
- CDC 捕获服务 A 数据库的变更。
- 变更事件进入消息队列。
- 服务 B 订阅事件，更新自己的数据库或缓存。
这样一来，服务 A 和服务 B 完全解耦。服务 B 挂了也不影响服务 A 的正常写入，等 B 恢复后继续消费事件就行。
我记得有个电商项目，订单服务和库存服务之间就是用 CDC 解耦的。订单创建后，CDC 把订单事件推给库存服务扣减库存。后来库存服务重构了三次，订单服务一行代码都没改。
1.3 CDC 的核心知识体系
下面这张图，是我梳理的 CDC 全链路知识框架。你可以把它当作这门课的「地图」。
从这张图你能看到，CDC 全链路分为五个层次：
| 层次 | 核心职责 | 常见技术选型 |
|---|---|---|
| 数据源层 | 产生变更日志的数据库 | MySQL、PostgreSQL、Oracle、MongoDB |
| 采集层 | 读取日志，解析为统一事件格式 | Canal、Debezium、Maxwell、Flink CDC |
| 传输层 | 缓冲和分发事件，保证不丢不重 | Kafka、Pulsar、RocketMQ |
| 消费层 | 订阅事件，做 ETL 或路由 | Flink、Kafka Connect、自定义 Consumer |
| 目标层 | 数据最终写入的存储或服务 | 数仓、缓存、搜索引擎、下游微服务 |
这门课会按照这个链路，从下往上、从原理到实战，一步步带你走通。每个层次我都会结合项目中的踩坑经验来讲——比如 binlog 解析时遇到的大事务问题、Kafka 分区分配不均导致的延迟、Flink CDC 的 exactly-once 保证……这些都是你在文档里看不到的实战细节。
一个小建议：学 CDC 之前，最好先熟悉你用的数据库的日志机制。比如 MySQL 的 binlog 格式（ROW/STATEMENT/MIXED），PostgreSQL 的复制槽（Replication Slot）。这些基础不牢，后面排查问题会很痛苦。
1.4 本章小结
这一章我们聊了：
- CDC 是什么——变更数据捕获，实时监听数据库变化。
- 为什么需要 CDC——低延迟、无侵入、高可靠，替代传统批处理和双写。
- 三个典型场景——实时数仓、缓存更新、微服务解耦。
- 全链路五层架构——数据源、采集、传输、消费、目标。
下一章，我们会深入数据源层，专门讲 MySQL binlog 的原理和实战配置。到时候我会手把手带你搭一个 Canal 环境，让你亲眼看到 binlog 事件长什么样。
嗯，今天就到这儿。有问题随时在课程群里讨论，我看到就会回。