1. CDC 概念与架构：从零理解实时同步

大家好，我是老赵。做数据架构十几年，CDC 这个概念我几乎每天都在打交道。说白了，CDC 就是「Change Data Capture」——捕获数据变更。你想想看，业务系统每天都在产生数据，怎么把这些变化实时同步到数仓、缓存或者搜索引擎里？CDC 就是干这个的。

我记得刚入行那会儿，做数据同步全靠定时任务跑批。凌晨两点跑一次，数据延迟至少几个小时。有一次线上活动，用户下单后半小时在报表里都看不到，运营直接炸了。嗯，从那以后我就开始认真研究 CDC 了。

1.1 什么是 CDC

CDC 的核心思想很简单：监听并捕获数据源的增量变更，然后实时推送给下游。它不像传统 ETL 那样全量拉取，而是只关注「变化」本身。

举个例子。你在 MySQL 里执行了一条 UPDATE，CDC 工具会捕获这条变更，解析成 JSON 或 Avro 格式，然后发送到 Kafka。下游的消费者拿到这条消息，就知道「某行数据变了」，直接更新自己的缓存或索引。

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

• 基于日志的 CDC：读取数据库的事务日志（如 MySQL binlog、PostgreSQL WAL）。性能好，对业务无侵入。
• 基于查询的 CDC：定期轮询业务表的时间戳或版本号字段。实现简单，但延迟高，还会给数据库增加压力。

我在项目中遇到过不少团队，一开始图省事用查询模式，结果业务量一上来，数据库直接被轮询拖垮。所以我的建议是：生产环境优先用日志模式。

1.2 CDC 的应用场景

CDC 能解决什么问题？我列几个最常见的：

1. 实时数仓同步：业务库（MySQL/PostgreSQL）→ Kafka → 数仓（ClickHouse/Doris）。延迟控制在秒级。
2. 缓存刷新：数据库变更后，自动更新 Redis 或 Elasticsearch。避免缓存与数据库不一致。
3. 微服务解耦：一个服务的数据变更，通过 CDC 广播给其他服务。不用改接口，不用加 MQ 消息。
4. 异地灾备：主库到从库的实时复制，保证数据不丢。
5. 审计与溯源：记录所有数据变更历史，方便回溯。

1.3 CDC 主流方案对比

市面上 CDC 工具不少，我挑三个最常用的：Canal、Debezium、DataX。它们各有侧重，我直接上表格对比。

特性	Canal	Debezium	DataX
数据源	MySQL（主要）	MySQL、PostgreSQL、MongoDB、Oracle 等	MySQL、Oracle、HDFS、Hive 等
同步模式	日志解析（binlog）	日志解析（binlog/WAL）	查询模式（select）
输出端	Kafka、RocketMQ、自定义	Kafka（强绑定）	多种存储
延迟	毫秒级	毫秒级	秒级到分钟级
部署复杂度	中等	较高（依赖 Kafka）	低
社区活跃度	高（阿里开源）	高（Red Hat 维护）	中等（阿里开源）

简单总结一下：

• Canal：如果你只用 MySQL，而且不想引入 Kafka 之外的中间件，Canal 很合适。我早期很多项目都用它。
• Debezium：如果你需要多数据源支持，或者已经在用 Kafka，Debezium 是首选。它把变更事件标准化了，下游处理起来很舒服。
• DataX：适合离线批量同步，或者数据源和目标端种类特别多的情况。但实时性一般，别拿它做秒级同步。

1.4 CDC 系统整体架构设计

一个完整的 CDC 系统，通常包含四个层次。我画了一张图，方便你理解。

这张图我解释一下：

• 数据源层：你的业务数据库。MySQL 最常见，但 PostgreSQL、MongoDB 也越来越多。
• CDC 采集层：核心组件。Canal 或 Debezium 在这里解析日志，把变更转成事件。
• 消息中间件层：事件缓冲和分发。Kafka 是标配，因为它能保证顺序和持久化。
• 消费端：下游系统。数仓、缓存、搜索引擎……想接多少接多少。

1.5 架构设计的关键考量

搭建 CDC 系统时，有几个点你必须想清楚：

1. 数据一致性：CDC 是「至少一次」还是「精确一次」？Debezium 配合 Kafka 可以做到精确一次，但需要处理好 offset 提交。
2. 延迟要求：秒级还是毫秒级？日志模式通常毫秒级，查询模式至少秒级。
3. Schema 变更：业务表加字段怎么办？Canal 和 Debezium 都支持自动感知，但下游消费端要能兼容。
4. 全量+增量：首次同步需要全量，后续增量。Debezium 有 Snapshot 机制，Canal 需要自己实现。
5. 高可用：CDC 组件不能单点。Canal 有 HA 模式，Debezium 依赖 Kafka Connect 的分布式能力。