1. CDC同步链路概述

大家好，我是老张。做数据库运维十几年，CDC（Change Data Capture）算是我接触过最"实在"的数据同步技术之一。今天咱们就来聊聊CDC到底是什么，它能干什么，以及一条完整的CDC同步链路里都有哪些关键角色。

1.1 什么是CDC

CDC，全称Change Data Capture，中文叫"变更数据捕获"。说白了，就是实时捕捉数据库里的数据变化——谁插入了新记录、谁修改了字段、谁删了一行数据，CDC都能第一时间感知到。

举个例子。你有个订单表，每天新增几十万条记录。如果用传统ETL每天凌晨跑一次全量同步，那白天产生的数据就得等到第二天才能用。CDC就不一样了——订单一落库，CDC立刻捕获这条新增记录，毫秒级推送到下游系统。

我记得刚接触CDC时，有个同事问我："这不就是数据库的binlog吗？"嗯，对，也不全对。binlog是底层机制，CDC是建立在它之上的数据同步方案。你可以把binlog看作"原材料"，CDC则是"加工流水线"。

1.2 CDC的应用场景

这些年我经手的CDC项目，应用场景大致可以归为以下几类：

场景	典型需求	我遇到过的坑
实时数仓	业务库→数仓，分钟级延迟	源库大事务导致延迟飙升
缓存同步	MySQL→Redis，秒级一致	缓存穿透+数据不一致
异构迁移	Oracle→MySQL，不停机迁移	数据类型映射踩过雷
微服务解耦	订单服务→消息队列→下游	消息重复消费处理
搜索索引	数据库→Elasticsearch	全量+增量衔接问题

你想想看，这些场景有一个共同点：数据产生速度和消费速度不匹配。业务库每秒写入几千条，但分析系统、搜索系统、缓存系统不可能都去直接查业务库。CDC就是中间的"数据搬运工"。

1.3 CDC同步链路的核心组件

一条完整的CDC同步链路，就像一条流水线。我习惯把它拆成四个环节：

1. 数据源——变化从哪里来
2. 捕获器——怎么抓变化
3. 传输通道——怎么传数据
4. 目标端——数据送到哪

下面这张图可以帮你快速建立整体认知：

1.3.1 数据源

数据源就是产生业务数据的数据库。我接触最多的是MySQL和Oracle，PG也有但相对少一些。

这里有个关键点：数据源必须开启日志功能。MySQL要开binlog，Oracle要开归档日志和补充日志。我曾经遇到一个项目，业务方说"数据库已经配好了"，结果一查binlog没开，白忙活半天。

1.3.2 捕获器

捕获器是CDC链路的"眼睛"。它负责读取数据库日志，解析出每一条变更记录。

常见的捕获方式有两种：

• 基于日志解析：比如MySQL的binlog、Oracle的LogMiner。性能好，对源库影响小。
• 基于触发器或API：在表上建触发器，或者轮询API。侵入性强，不推荐生产环境用。

我个人习惯用日志解析方式。原因很简单——不侵入业务。你想想看，在核心业务表上加触发器，万一触发器出问题，业务也跟着遭殃。日志解析就安全多了，数据库该干嘛干嘛，CDC在旁边"偷看"就行。

1.3.3 传输通道

捕获到的变更数据怎么送到目标端？这就靠传输通道了。

传输通道的选型，我总结了一个简单的对照表：

组件	适用场景	优点	缺点
Kafka	高吞吐、多消费者	持久化、可回溯	运维复杂
Canal	MySQL→其他	轻量、易部署	只支持MySQL
DTS	云上同步	开箱即用	厂商锁定
自研管道	定制化需求	灵活可控	开发成本高

这里我想多说一句：传输通道的可靠性直接决定CDC链路的稳定性。我见过太多案例，传输通道丢数据、乱序、重复，排查起来非常痛苦。所以选型时，优先考虑有持久化能力和断点续传机制的方案。

1.3.4 目标端

目标端就是数据最终要去的地方。常见的有：

• 数据仓库：Hive、ClickHouse、Doris
• 缓存：Redis、Memcached
• 搜索引擎：Elasticsearch
• 消息队列：Kafka（作为中间层）

目标端写入有个容易被忽略的问题——幂等性。CDC链路可能因为网络抖动、重启等原因重复推送同一条变更。如果目标端不支持幂等写入，就会出现数据重复。我在做缓存同步时就踩过这个坑，后来在写入逻辑里加了唯一键去重才解决。

小结

CDC同步链路，说白了就是一条"数据变化流水线"。源库产生变化，捕获器抓取变化，传输通道搬运变化，目标端消费变化。四个环节环环相扣，任何一个环节出问题，整条链路都会受影响。

嗯，这一章先到这里。后面的章节我们会深入每个环节，聊聊性能怎么诊断、延迟怎么优化。到时候我会把这些年踩过的坑、总结的经验都抖出来。