1. 课程导入
在实时数仓、微服务解耦与异构数据同步场景中，CDC（Change Data Capture，变更数据捕获）已经成为数据链路的基础设施。它从数据库日志中捕获 INSERT、UPDATE、DELETE 事件，并将其投递到下游的消息队列、湖仓或检索系统中。然而，CDC 并不是"接上就能用"的银弹：只要链路中存在网络抖动、消费者重启、分区再均衡、并发写入或跨节点时钟差异，数据重复、乱序与幂等失效就会接踵而至。本课程的第一节，我们先建立全局认知，明确学习目标、核心挑战、知识框架与实战路线图。
一、学习目标：从"能同步"到"同步得准"
本课程不是泛泛介绍 CDC 工具的使用，而是聚焦于数据一致性治理这一硬核问题。完成学习后，你应当能够达成以下目标：
- 识别问题：准确判断一条 CDC 链路中重复、乱序、幂等失效分别发生在哪个环节，是源端、传输端还是消费端。
- 理解原理：掌握至少提交位点、事务边界、事件时间与处理时间、幂等键、去重窗口等核心机制的工作方式。
- 设计方案：能够针对不同业务场景，选择"精确一次""至少一次+幂等""去重表""版本号覆盖"等组合策略。
- 落地实战：能够编写可运行的 Flink、Kafka 或数据库侧治理代码，并通过监控指标验证治理效果。
- 复盘排障：面对线上数据错乱，能够按结构化路径定位根因，而不是盲目重启任务。
学习主线可以概括为一句话：先看清数据是怎么"坏"的，再决定用什么机制让它"好"起来。重复与乱序是现象，幂等与去重是手段，而端到端一致性才是最终目标。
二、核心挑战：三类问题为何总是同时出现
很多工程师第一次遇到 CDC 数据问题时，往往只看到"下游多了一条记录"或"金额被覆盖成旧值"。实际上，重复、乱序、幂等失效常常是同一根因的不同表现。下面这张图展示了 CDC 链路中三类问题的典型发生位置与传播关系。
从图中可以看到，重复主要来源于"重放与重试"，乱序主要来源于"多分区并行与网络延迟"，而幂等失效则往往发生在下游存储无法识别"同一条业务记录"时。三者叠加，就会造成下游数据比源端多、旧值覆盖新值、聚合结果偏大等典型故障。
| 问题类型 | 典型触发场景 | 常见表现 | 治理方向 |
|---|---|---|---|
| 数据重复 | 消费者重启、位点回退、任务失败重试 | 下游记录数大于源端、指标虚高 | 幂等写入、去重键、事务提交 |
| 数据乱序 | 多分区并行、跨机房传输、时钟漂移 | 旧值覆盖新值、状态回退 | 事件时间、水位线、版本号比较 |
| 幂等失效 | 无业务主键、主键生成不稳定、更新语义模糊 | 重复插入、更新丢失、删除复活 | 稳定幂等键、UPSERT、软删除标记 |
三、整体知识框架：四层治理模型
为了把零散的知识点组织成可操作的体系，本课程采用"四层治理模型"作为整体框架：
- 源端层：理解 binlog/WAL 的事务边界、GTID、SCN 等机制，明确变更事件的产生顺序与唯一标识。
- 传输层：掌握 Kafka 分区、位点提交、幂等生产者与事务生产者，理解"至少一次"与"精确一次"的边界。
- 计算层：使用 Flink 事件时间、水位线、状态后端与检查点，实现去重、排序与版本合并。
- 存储层：通过主键约束、UPSERT、MERGE、版本列与去重表，保证写入的幂等性与最终一致性。
记忆口诀：源端定顺序，传输保不丢，计算管乱序，存储做幂等。四层各司其职，任何一层缺失都会让端到端一致性破功。
四、实战路线图：从最小可复现到生产级治理
本课程后续章节将沿着一条渐进式路线展开，建议你按以下顺序动手实践：
阶段一：复现问题
1. 搭建 MySQL + Kafka + Flink 最小链路
2. 人为制造消费者重启，观察重复数据
3. 开启多分区并行，观察乱序现象
阶段二：单点治理
4. 在 Flink 中使用 KeyedProcessFunction 去重
5. 引入事件时间与水位线处理乱序
6. 在下游使用 UPSERT 实现幂等写入
阶段三：端到端一致性
7. 开启 Kafka 事务生产者与 Flink 检查点
8. 设计稳定幂等键与版本号合并策略
9. 建立重复率、延迟、乱序率监控指标
阶段四：生产复盘
10. 模拟位点回退、分区再均衡、跨机房延迟
11. 按故障树定位根因并沉淀治理预案五、常见误区与复盘提醒
误区一：认为开启"精确一次"就万事大吉。精确一次通常只覆盖"引擎内部状态"，一旦下游存储不支持事务或幂等，重复仍会写入。
误区二：只用处理时间做去重。处理时间无法反映事件真实顺序，遇到延迟数据会误判。
误区三：把去重窗口设得过大或过小。过大导致状态膨胀，过小导致迟到数据漏去重。
误区四：忽略删除事件。DELETE 在乱序场景下可能"复活"已删除记录，必须结合版本号或软删除标记处理。
误区二：只用处理时间做去重。处理时间无法反映事件真实顺序，遇到延迟数据会误判。
误区三：把去重窗口设得过大或过小。过大导致状态膨胀，过小导致迟到数据漏去重。
误区四：忽略删除事件。DELETE 在乱序场景下可能"复活"已删除记录，必须结合版本号或软删除标记处理。
请记住：CDC 数据治理不是一次性配置，而是一套需要持续观测、调参与复盘的工程能力。接下来的章节，我们将从源端事务边界开始，逐层拆解每一个治理环节，并配合可运行的代码与真实故障案例，帮助你把这套能力真正落到生产环境中。