变更数据捕获是什么
变更数据捕获（CDC）从数据库的日志里解析数据变更——MySQL 的 binlog、PostgreSQL 的逻辑复制槽、Oracle 的 redo——转换成事件流发布出去，让下游准实时同步，而不必在业务写入路径里额外插入发消息的代码。它把同步逻辑与业务逻辑解耦，也避免了双写不一致。代价是运维更复杂：初始化快照要与增量位点衔接、事件可能重复或乱序、DDL 变更可能直接打断解析管道。
基本信息
| 原理 | 解析 binlog / WAL / 逻辑复制槽等日志，输出变更事件 |
|---|---|
| 初始化 | 一致性快照 + 位点衔接，保证快照与增量不重不漏 |
| 消费语义 | 通常至少一次，下游按主键幂等落库，容忍重复与乱序 |
| 位点管理 | 记录消费位点，支持从指定时间点重放 |
| 变更防护 | DDL 评审纳入 CDC 管道影响评估，避免解析中断 |
典型使用场景
- 异库同步：把在线库变更同步到分析库或搜索索引，避免业务双写
- 缓存预热与失效：按变更事件精确刷新缓存，替代定时全量刷新
- 下游触发：订单状态变更后驱动通知、对账与风控等下游流程
- 数据入湖：按增量把业务表持续写入数据仓库，替代每日批量抽取
- 旧系统集成：老系统只提供数据库，通过 CDC 把变更暴露为事件
- 审计留痕：记录数据变更历史，支持事后追溯
落地要点
| 阶段 | 要点 | 常见故障 |
|---|---|---|
| 初始化 | 一致性快照 + 位点衔接，避免重复与丢失 | 快照与增量位点错位，数据整体偏移 |
| 运行 | 去重键、乱序处理与延迟监控 | 消费延迟无监控，积压数小时才被发现 |
| 变更防护 | DDL 评审纳入管道影响评估 | 加字段或改类型后解析失败，管道中断 |
| 恢复 | 位点可回溯，支持指定时间重放 | 只能全量重来，恢复窗口不可控 |
| 容量 | 日志保留时长与解析资源规划 | 日志被清理，位点失效只能重建 |
消费端处理要点
消费端处理要点
# 1 幂等：按主键做 upsert，重复事件覆盖结果一致
# 2 顺序：同一主键的事件走同一分区，按位点递增处理
# 3 位点：处理成功后提交 offset，失败不提交，重启后从断点继续
# 4 乱序容忍：携带变更时间戳，晚到事件按时间戳判断是否需要覆盖
# 5 删除语义：逻辑删除与物理删除要区分，下游按事件类型分别处理
# 6 观测：监控消费延迟、失败率与重放次数，超阈值告警DDL 变更会打断解析管道：给表加字段、改字段类型、重命名列都可能导致下游解析失败或数据错位，这类变更必须在上线前评估对 CDC 流的影响。
CDC 的位点与数据库日志保留期绑定：日志被清理后位点失效，只能重新初始化快照，因此日志保留时长要覆盖最长的故障恢复窗口。