一、CDC概述:什么是CDC、为什么需要CDC、CDC的典型应用场景

各位同学好,我是老张。做数据同步这行十几年了,今天咱们聊聊CDC——Change Data Capture,中文叫变更数据捕获。

说实话,我第一次接触CDC是在2015年,当时要给一个电商平台做实时数据同步。业务方要求订单数据从MySQL同步到Hadoop,延迟不能超过30秒。我一开始想用全量同步+定时任务,结果被领导骂了一顿——你想想看,几千万订单每天全量跑一次,服务器扛得住吗?

后来我才发现,CDC才是解决这类问题的正确姿势。

1.1 什么是CDC

CDC,说白了就是捕获数据库中的数据变更事件。插入、更新、删除,这些操作都会被CDC工具捕捉到,然后以事件流的形式推送给下游系统。

我习惯把CDC分成两种模式:

  • 基于日志的CDC:直接读取数据库的事务日志(比如MySQL的binlog、PostgreSQL的WAL、Oracle的Redo Log)。这种方式对业务库几乎零侵入,性能最好。
  • 基于查询的CDC:通过轮询表上的时间戳或版本号来发现变更。实现简单,但延迟高,还会给数据库增加查询压力。

核心观点:生产环境我强烈推荐基于日志的CDC。原因很简单——不打扰业务。我在项目中见过太多因为轮询查询把主库拖垮的案例了。

嗯,这里要注意:基于日志的CDC需要数据库开启相关配置。比如MySQL要开启binlog,并且设置成ROW格式。我见过有人用STATEMENT格式,结果捕获到的SQL语句根本没法还原数据变更——这是个坑,后面章节我会详细讲。

1.2 为什么需要CDC

你可能会问:传统的数据同步方式有什么不好?

我列个表,你一看就明白了:

同步方式 延迟 对源库影响 数据一致性 适用场景
全量定时同步 小时级 高(全表扫描) 差(窗口期不一致) 离线分析
增量定时同步 分钟级 中(轮询查询) 中(可能丢数据) 轻度实时
CDC实时同步 秒级/毫秒级 低(读日志) 高(Exactly-Once) 实时流处理

看到差距了吧?CDC的优势非常明显:

  • 低延迟:变更发生即捕获,毫秒级延迟
  • 低侵入:不修改业务代码,不增加表结构
  • 高一致性:基于事务日志,保证不丢不重
  • 全量+增量一体化:先做快照,再持续捕获增量

我的经验:曾经有个金融客户,要求数据同步延迟不超过5秒,而且不能影响核心交易库。全量同步肯定不行,轮询查询又怕锁表。最后我们用Debezium读binlog,配合Kafka,延迟稳定在1秒以内。客户很满意,我也松了口气。

1.3 CDC的典型应用场景

CDC能做的事情太多了。我挑三个最常见的场景聊聊。

场景一:数据库同步

这是CDC最基础的应用。比如:

  • 主库到从库的实时备份
  • 异构数据库之间的数据迁移(MySQL → PostgreSQL)
  • 多地多活的数据复制

我记得有个项目,需要把Oracle的数据实时同步到MySQL。Oracle的GoldenGate太贵,而且配置复杂。我们用Debezium + Kafka Connect,两周就搞定了。说白了,CDC让数据库同步变得像搭积木一样简单。

场景二:数据仓库

传统的数据仓库用ETL,每天凌晨跑批。但业务方越来越不能忍受T+1的延迟。

CDC可以做到:

  • 实时捕获业务库的变更
  • 流式写入数据湖或数仓
  • 支持实时报表和即席查询

举个例子:某电商平台需要实时分析用户行为。订单创建、支付成功、退款申请,这些事件都要在秒级进入数仓。用CDC + Kafka + Flink,整个链路延迟不到3秒。

场景三:实时流处理

这是CDC最酷的应用。把数据库的变更事件当成数据流,然后做各种处理:

  • 更新搜索引擎的索引
  • 失效缓存(比如Redis)
  • 触发业务告警
  • 构建事件驱动架构

我曾经帮一个社交平台做过:用户修改头像后,需要同步更新CDN、清除缓存、通知好友。如果用传统方式,业务代码里要写一堆逻辑。用CDC之后,数据库变更自动触发后续流程,业务代码只需要关注写数据库就行。

避坑指南:CDC不是银弹。我曾经遇到一个场景,业务库每秒有10万次写入,binlog流量巨大。如果直接用CDC工具消费,Kafka都扛不住。这时候需要做数据过滤和聚合下推——只捕获真正需要的表,或者把多条变更合并成一条。这个后面会详细讲。

1.4 CDC技术生态全景

为了让你对CDC有个整体认识,我画了一张图:

CDC技术生态全景图 数据源层 MySQL (binlog) PostgreSQL (WAL) Oracle (Redo Log) SQL Server (TLog) CDC工具层 Debezium Canal / Maxwell Oracle GoldenGate 消息中间件层 Apache Kafka Pulsar / RabbitMQ 消费端层 实时数仓 搜索引擎 缓存失效 事件驱动 更多...

从这张图你能看到,CDC的完整链路是:数据源 → CDC工具 → 消息中间件 → 消费端。每一层都有多种选择,具体怎么选,后面章节我会结合项目经验给你讲透。

1.5 小结

这一章我们聊了:

  • CDC是什么——捕获数据库变更事件的技术
  • 为什么需要CDC——低延迟、低侵入、高一致性
  • 典型应用场景——数据库同步、数据仓库、实时流处理
  • 技术生态全景——从数据源到消费端的完整链路

我个人觉得,CDC是数据工程师必须掌握的核心技能。不管你是做数仓、做实时计算,还是做微服务架构,CDC都能帮你解决很多实际问题。