摘要
Change Data Capture（CDC）是实现实时数据同步、事件驱动架构和数据管道的关键技术。本文从 CDC 概念与典型场景出发，详解 TiDB CDC 的架构设计、下游对接能力、与其他数据同步方案的对比，以及生产环境最佳实践。本文适合数据架构师、DBA、数据工程师及负责构建实时数据管道的技术负责人阅读。
一、CDC 概念与应用场景
1.1 什么是 CDC
Change Data Capture（变更数据捕获）是一种持续监控数据库变更（INSERT、UPDATE、DELETE）并以流式方式将变更事件推送到下游系统的技术。CDC 的核心价值在于：
- 实时性：毫秒级延迟的变更捕获，而非批量同步
- 低侵入性：不修改业务代码，在数据库层自动捕获变更
- 完整审计：记录每一行数据的每一次变更历史
1.2 典型应用场景
| 场景 | 说明 | 典型延迟要求 |
|---|---|---|
| 缓存同步 | 数据库变更实时同步到 Redis/Elasticsearch | < 1 秒 |
| 搜索引擎更新 | 商品/文章数据变更同步到搜索索引 | < 5 秒 |
| 数据仓库入湖 | 业务数据实时同步到数据仓库（Snowflake/BigQuery） | 秒级-分钟级 |
| 微服务数据共享 | 跨微服务的数据最终一致性保障 | 秒级 |
| 事件驱动架构 | 变更事件驱动业务流程（如订单状态变更触发通知） | 毫秒级 |
| 审计与合规 | 数据变更日志记录，满足金融/医疗合规要求 | 秒级 |
二、TiDB CDC 架构
2.1 整体架构
TiDB 的 CDC 方案由 TiCDC 组件实现，是一个分布式、高可用的变更数据捕获服务：
TiDB Cluster
├── TiDB Server ── SQL 写入
├── TiKV ── 数据存储（Raft 多副本）
│ └── Raft Log（变更日志来源）
└── PD ── 元数据管理
│
▼
TiCDC（CDC Server 集群）
├── Changefeed 1 ──► Kafka
├── Changefeed 2 ──► MySQL
├── Changefeed 3 ──► Elasticsearch
└── Changefeed 4 ──► 对象存储（S3/GCS）
2.2 TiCDC 核心特性
| 特性 | 说明 |
|---|---|
| 分布式架构 | 多节点部署，自动故障转移 |
| 高可用 | 任意节点故障不影响 CDC 数据交付 |
| 断点续传 | 自动记录同步位点（Checkpoint），重启后从断点继续 |
| 事务保序 | 保证事务内变更的顺序和完整性 |
| Schema 变更同步 | DDL 变更自动同步到下游 |
2.3 下游对接能力
TiCDC 原生支持以下下游系统：
| 下游类型 | 协议/格式 | 典型用途 |
|---|---|---|
| Kafka | Canal JSON / Avro / Debezium | 流处理平台（Flink/Spark） |
| MySQL | 原生 MySQL 协议 | 异构数据库同步 |
| Elasticsearch | REST API | 搜索索引实时更新 |
| 对象存储 | CSV / Parquet / Canal JSON | 数据湖（S3/GCS/OSS） |
三、CDC vs ETL vs 物化视图对比
3.1 三种数据同步方案对比
| 维度 | CDC | 传统 ETL | 物化视图 |
|---|---|---|---|
| 数据新鲜度 | 毫秒-秒级 | 分钟-小时级 | 取决于刷新策略 |
| 实现方式 | 基于日志捕获 | 批量查询+写入 | 自动维护 |
| 对源库影响 | 极低（读日志） | 高（全量/增量查询） | 中等（额外计算） |
| 数据完整性 | 行级变更，精确到字段 | 通常整行覆盖 | 取决于视图定义 |
| 下游系统 | Kafka/MySQL/ES/对象存储 | 数据仓库 | 同库内表 |
| 运维复杂度 | 中等（需维护 CDC 链路） | 高（调度/监控） | 低（数据库自动维护） |
| 适用场景 | 实时同步 | 历史数据集成 | 复杂查询加速 |
3.2 何时选择 CDC
- 下游需要近实时的数据新鲜度（< 10 秒延迟）
- 需要精确到字段级别的变更信息
- 源库负载敏感，不能承受额外的查询压力
- 需要将同一份数据变更同步到多个异构下游
3.3 TiCDC 在数据管道中的角色
数据源层 传输层 消费层
┌──────────┐ ┌──────────────┐ ┌──────────────────┐
│ TiDB │──►│ TiCDC │──►│ Kafka → Flink │
│ (OLTP) │ │ (Changefeed)│ │ (实时计算) │
└──────────┘ └──────────────┘ └──────────────────┘
│ ┌──────────────────┐
├────────────────►│ MySQL (数据同步) │
│ └──────────────────┘
│ ┌──────────────────┐
├────────────────►│ ES (搜索索引) │
│ └──────────────────┘
│ ┌──────────────────┐
└────────────────►│ S3 (数据湖) │
└──────────────────┘
四、TiDB CDC 最佳实践
4.1 创建 Changefeed
# 创建同步到 Kafka 的 Changefeed
tiup cdc cli changefeed create \
--pd=http://10.0.1.1:2379 \
--sink-uri="kafka://10.0.2.1:9092/topic-name?protocol=canal-json" \
--changefeed-id="order-sync" \
--sort-engine="unified" \
--config-file=changefeed-config.toml
4.2 配置过滤规则
# changefeed-config.toml
[filter]
# 按表过滤
rules = ["orders.*", "products.*"]
# 按事件类型过滤
ignore-txn-start-ts = [1, 2]
# 排除特定表
filter-event-type = ["INSERT", "UPDATE"]
[scheduler]
# 按 TSkey 分散到不同 TiCDC 实例
tp-bucket = 3
4.3 同步到 MySQL 示例
# 创建同步到 MySQL 的 Changefeed
tiup cdc cli changefeed create \
--pd=http://10.0.1.1:2379 \
--sink-uri="mysql://user:password@10.0.3.1:3306/target_db" \
--changefeed-id="mysql-sync" \
--sort-engine="unified"
4.4 断点续传与监控
# 查看 Changefeed 状态
tiup cdc cli changefeed list --pd=http://10.0.1.1:2379
# 查看 Changefeed 详细信息（含 Checkpoint）
tiup cdc cli changefeed info --changefeed-id="order-sync" --pd=http://10.0.1.1:2379
# 暂停/恢复 Changefeed
tiup cdc cli changefeed pause --changefeed-id="order-sync" --pd=http://10.0.1.1:2379
tiup cdc cli changefeed resume --changefeed-id="order-sync" --pd=http://10.0.1.1:2379
4.5 生产环境建议
| 实践 | 说明 |
|---|---|
| 多 Changefeed 分区 | 按业务模块创建独立 Changefeed，避免单点瓶颈 |
| Kafka 分区策略 | 使用表名或主键作为分区键，保证同一行变更的顺序 |
| 监控同步延迟 | 关注 Checkpoint lag，设置告警阈值（如 > 10 秒） |
| 资源隔离 | TiCDC 节点与 TiDB/TiKV 节点分开部署 |
| 版本兼容 | 确保 TiCDC 版本与 TiDB 版本匹配 |
五、总结
CDC 是构建现代实时数据管道的基础设施。TiDB CDC（TiCDC）基于 Raft 日志实现变更捕获，提供了分布式、高可用、支持多种下游的完整方案。与传统 ETL 相比，TiCDC 在实时性、对源库影响和数据完整性方面具有显著优势。对于需要实时数据同步、事件驱动架构或数据湖入湖的企业，TiDB CDC 是一项值得投入的核心能力。
下一步行动
- 试用 TiDB CDC：TiDB Cloud 免费试用 — 创建 TiDB Cloud 集群，体验一键配置 CDC 同步
- 获取数据同步方案：联系 PingCAP 专家 — 咨询 PingCAP 技术团队，获取定制化数据同步架构方案
- 阅读 TiCDC 官方文档：TiCDC 技术文档 — 完整技术文档与配置参考
常见问题（FAQ）
Q1：TiCDC 的同步延迟通常是多少？
在正常负载下，TiCDC 的同步延迟通常在百毫秒到几秒之间。延迟受源库写入速率、下游写入能力、网络带宽等因素影响。通过合理配置 Sort Worker 数量和下游并发度，可以将延迟控制在 1 秒以内。
Q2：TiCDC 如何处理 DDL 变更？
TiCDC 支持自动同步大部分 DDL 变更（CREATE TABLE、ALTER TABLE、DROP TABLE 等）到下游。对于 MySQL 下游，DDL 会直接执行；对于 Kafka 下游，DDL 事件以 Schema 变更消息的形式发送。建议在业务低峰期执行 DDL 操作。
Q3：如果下游系统暂时不可用，数据会丢失吗？
不会。TiCDC 基于 TiKV 的 Raft Log 进行变更捕获，只要 TiKV 的日志未被 GC 清除，变更数据就不会丢失。下游恢复后，TiCDC 从上次 Checkpoint 位置继续同步。默认 GC 保留时间为 10 分钟，生产环境建议适当增大。
Q4：TiCDC 和 Debezium 有什么区别？
TiCDC 是 TiDB 专用的 CDC 工具，基于 TiKV Raft Log 实现；Debezium 是通用的 CDC 平台，基于数据库 binlog/redo log 实现。TiCDC 与 TiDB 深度集成，性能更优、功能更完整。如需将 TiDB 数据通过 Debezium 同步，可使用 TiCDC 输出 Debezium 格式的消息到 Kafka。
Q5：一个 TiDB 集群支持多少个 Changefeed？
TiDB 6.1+ 支持数百个 Changefeed。每个 Changefeed 可独立配置下游、过滤规则和同步策略。建议将不同业务模块的数据变更分配到独立 Changefeed，便于独立监控和管理。