Flink CDC 机制精讲（二）：Checkpoint Barrier 如何形成一致快照【面试宝典】

核心结论：Checkpoint 不是把整个任务同时暂停，而是让 Barrier 沿数据流划分"快照之前"和"快照之后"的记录，并把 Source 位点、算子状态和外部提交边界协调到同一个恢复点。

一、为什么只保存算子内存还不够

假设任务是：

text 复制代码

Kafka Source → Keyed Process → JDBC Sink

如果只保存 Keyed Process 的 ValueState，却没有保存 Kafka Offset，恢复后就不知道从哪里重放；如果保存 Offset，却没有保存 Keyed State，旧事件可能重新被当成新事件；如果两者保存时间不一致，仍可能产生逻辑错乱。

一致快照必须同时回答：

Source 已经读到哪里；
每个有状态算子处理到哪一批输入；
输入通道里哪些数据属于快照前、哪些属于快照后；
Sink 是否已经把快照前的数据提交到外部系统。

Barrier 就是划分这条边界的标记。

二、一次 Checkpoint 的完整生命过程

Checkpoint Storage Sink Stateful Operator Source Checkpoint Coordinator Checkpoint Storage Sink Stateful Operator Source Checkpoint Coordinator #mermaid-svg-BNvPUfiUc85iWG6p{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-BNvPUfiUc85iWG6p .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-BNvPUfiUc85iWG6p .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-BNvPUfiUc85iWG6p .error-icon{fill:#552222;}#mermaid-svg-BNvPUfiUc85iWG6p .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-BNvPUfiUc85iWG6p .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-BNvPUfiUc85iWG6p .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-BNvPUfiUc85iWG6p .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-BNvPUfiUc85iWG6p .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-BNvPUfiUc85iWG6p .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-BNvPUfiUc85iWG6p .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-BNvPUfiUc85iWG6p .marker{fill:#333333;stroke:#333333;}#mermaid-svg-BNvPUfiUc85iWG6p .marker.cross{stroke:#333333;}#mermaid-svg-BNvPUfiUc85iWG6p svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-BNvPUfiUc85iWG6p p{margin:0;}#mermaid-svg-BNvPUfiUc85iWG6p .actor{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-BNvPUfiUc85iWG6p text.actor>tspan{fill:black;stroke:none;}#mermaid-svg-BNvPUfiUc85iWG6p .actor-line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-BNvPUfiUc85iWG6p .innerArc{stroke-width:1.5;stroke-dasharray:none;}#mermaid-svg-BNvPUfiUc85iWG6p .messageLine0{stroke-width:1.5;stroke-dasharray:none;stroke:#333;}#mermaid-svg-BNvPUfiUc85iWG6p .messageLine1{stroke-width:1.5;stroke-dasharray:2,2;stroke:#333;}#mermaid-svg-BNvPUfiUc85iWG6p #arrowhead path{fill:#333;stroke:#333;}#mermaid-svg-BNvPUfiUc85iWG6p .sequenceNumber{fill:white;}#mermaid-svg-BNvPUfiUc85iWG6p #sequencenumber{fill:#333;}#mermaid-svg-BNvPUfiUc85iWG6p #crosshead path{fill:#333;stroke:#333;}#mermaid-svg-BNvPUfiUc85iWG6p .messageText{fill:#333;stroke:none;}#mermaid-svg-BNvPUfiUc85iWG6p .labelBox{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-BNvPUfiUc85iWG6p .labelText,#mermaid-svg-BNvPUfiUc85iWG6p .labelText>tspan{fill:black;stroke:none;}#mermaid-svg-BNvPUfiUc85iWG6p .loopText,#mermaid-svg-BNvPUfiUc85iWG6p .loopText>tspan{fill:black;stroke:none;}#mermaid-svg-BNvPUfiUc85iWG6p .loopLine{stroke-width:2px;stroke-dasharray:2,2;stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-BNvPUfiUc85iWG6p .note{stroke:#aaaa33;fill:#fff5ad;}#mermaid-svg-BNvPUfiUc85iWG6p .noteText,#mermaid-svg-BNvPUfiUc85iWG6p .noteText>tspan{fill:black;stroke:none;}#mermaid-svg-BNvPUfiUc85iWG6p .activation0{fill:#f4f4f4;stroke:#666;}#mermaid-svg-BNvPUfiUc85iWG6p .activation1{fill:#f4f4f4;stroke:#666;}#mermaid-svg-BNvPUfiUc85iWG6p .activation2{fill:#f4f4f4;stroke:#666;}#mermaid-svg-BNvPUfiUc85iWG6p .actorPopupMenu{position:absolute;}#mermaid-svg-BNvPUfiUc85iWG6p .actorPopupMenuPanel{position:absolute;fill:#ECECFF;box-shadow:0px 8px 16px 0px rgba(0,0,0,0.2);filter:drop-shadow(3px 5px 2px rgb(0 0 0 / 0.4));}#mermaid-svg-BNvPUfiUc85iWG6p .actor-man line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-BNvPUfiUc85iWG6p .actor-man circle,#mermaid-svg-BNvPUfiUc85iWG6p line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;stroke-width:2px;}#mermaid-svg-BNvPUfiUc85iWG6p :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} Trigger checkpoint N 保存 Source 位点在数据流中注入 Barrier N 对齐输入并快照状态转发 Barrier N 异步持久化状态执行 checkpoint 回调/提交准备持久化 Sink 状态 ACK N ACK N ACK N 所有 ACK 到齐，Checkpoint N 完成

关键点是：Barrier 与普通数据走同一条通道，并保持通道内顺序。

text 复制代码

record A
record B
Barrier N
record C

算子看到 Barrier N 时，可以确定该通道中的 A、B 属于 Checkpoint N 之前，C 属于之后。

三、单输入算子为什么相对简单

单输入算子收到 Barrier 后：

触发自身状态快照；
将 Barrier 向下游转发；
继续处理后续记录；
状态数据通常异步写入持久化存储；
持久化成功后向 Coordinator ACK。

"异步写入"并不意味着状态可以随意继续变化。Flink 会先建立一个逻辑上一致的状态视图，再让持久化工作与数据处理尽量并行。

四、多输入算子为什么需要 Barrier Alignment

假设一个算子有两个输入：

text 复制代码

Input A：A1 A2 Barrier-N A3 A4
Input B：B1 B2 B3 B4 Barrier-N B5

Input A 的 Barrier 先到。如果算子继续消费 A3、A4，同时仍在消费 Barrier 前的 B3、B4，那么算子状态会混入两个 Checkpoint 区间的数据。

Aligned Checkpoint 的处理方式是：

text 复制代码

收到 Input A 的 Barrier N
        ↓
暂停继续消费 A 通道
        ↓
继续消费 B3、B4
        ↓
收到 Input B 的 Barrier N
        ↓
所有输入完成对齐
        ↓
快照算子状态并继续处理

这段等待就是 Barrier Alignment。它保证快照只包含所有输入通道在 Barrier N 之前的数据。

五、背压为什么会把 Checkpoint 拖得很慢

Barrier 不会瞬移，它排在数据 Buffer 后面。下游处理能力不足时：

text 复制代码

数据积压
   ↓
Barrier 排在积压数据后
   ↓
到达下游算子的时间延长
   ↓
Checkpoint Start Delay 增大

多输入算子某条通道更慢时：

text 复制代码

第一条通道 Barrier 已到
第二条通道 Barrier 迟迟不到
   ↓
Alignment Duration 增大

因此 Checkpoint 慢至少要拆成三段观察：

指标	表示什么	常见根因
Start Delay	Barrier 从触发到抵达 Subtask 的时间	上游背压、网络积压、长时间同步调用
Alignment Duration	第一个与最后一个输入 Barrier 的间隔	多输入速率不均、倾斜、局部背压
Async Duration	状态异步持久化耗时	状态过大、存储慢、网络或状态后端 I/O

只看 Checkpoint 总耗时，无法判断应该扩容算子、优化 JDBC、调整网络 Buffer，还是检查 HDFS。

六、Unaligned Checkpoint 改变了什么

Unaligned Checkpoint 不再等待所有通道完成传统对齐，而是把通道中尚未处理的 In-flight Data 一并纳入快照，使 Barrier 能更快向下游推进。

text 复制代码

Aligned：等待慢通道 → 快照算子状态
Unaligned：记录通道内数据 → Barrier 继续前进

它适合：

Checkpoint 主要慢在持续背压；
Start Delay/Alignment Duration 明显偏高；
状态存储有能力承担额外 Channel State I/O；
需要先提高故障恢复点的成功率。

它不适合被理解成"一键消除背压"。业务记录的端到端延迟仍然存在，瓶颈算子也没有变快。并且更多 In-flight Data 会增加 Checkpoint 大小和恢复读取量。

Flink 1.20 中启用 Unaligned Checkpoint 还要注意：

Checkpoint 模式必须为 Exactly Once；
最大并发 Checkpoint 数应为 1；
可以设置 Aligned Checkpoint Timeout，先尝试对齐，超过阈值再转为 Unaligned；
Savepoint 始终使用对齐方式，不能把 Unaligned 的经验直接套到 Savepoint。

七、Checkpoint 成功不等于端到端 Exactly Once

Checkpoint 首先保证的是 Flink 内部状态与可重放 Source 的一致恢复。

外部 Sink 必须再分类：

Sink 写法	故障后可能结果
无事务、无幂等	可能部分写入、重复甚至产生脏结果
单次 JDBC 事务 + Upsert	一次 Flush 原子；恢复重放后业务结果可幂等
Kafka Exactly Once Sink	由 Checkpoint 协调 Kafka 事务提交
真正两阶段提交 Sink	可把外部事务纳入 Checkpoint 提交协议

普通 JDBC commit() 不受 Checkpoint Coordinator 两阶段控制。数据库 Commit 成功但 Checkpoint 失败时，恢复会重放这批记录，所以准确语义仍是：

text 复制代码

At-least-once + target-side idempotence

八、当前项目为什么在 snapshotState() 中强制 Flush

项目的 AbstractJdbcCdcSink 实现了 CheckpointedFunction：

java 复制代码

@Override
public final void snapshotState(FunctionSnapshotContext context) throws Exception {
    runtime.flushGuard.flushForCheckpoint();
}

它没有把 JDBC Buffer 保存为 Operator State，而是要求 Checkpoint 成功前先把 Buffer 写入目标库。

否则可能出现：

text 复制代码

Kafka 记录已进入 JDBC 内存 Buffer
        ↓
Checkpoint 保存了 Kafka Source Offset
        ↓
Buffer 没有落库，也没有进入 Checkpoint State
        ↓
任务故障
        ↓
恢复后 Offset 已前进，内存 Buffer 消失
        ↓
数据永久丢失

所以 Flush 失败必须让 snapshotState() 抛错，从而让本次 Checkpoint 失败，不能只打印日志。

九、Checkpoint 卡住时的排查顺序

第一步：确认卡在哪个 Subtask

在 Flink Web UI 中比较各算子的 Start Delay、Alignment Duration、Async Duration 和 Checkpointed Data Size。

第二步：沿反压方向向上找

如果 Sink 长时间阻塞 JDBC 写入，背压会向 Kafka Source 传播。Source 看起来 Checkpoint 很慢，根因可能仍在目标数据库。

第三步：检查同步阻塞点

当前项目重点检查：

JDBC 获取连接耗时；
Batch SQL 执行与 Commit 耗时；
snapshotState() 中 Flush 耗时；
Redis/配置库是否在处理路径重复查询；
某张热点表是否独占一个超大 Buffer；
HDFS Checkpoint 目录是否可写且延迟稳定。

第四步：再决定调参还是改瓶颈

text 复制代码

Alignment 高：先找背压、倾斜和慢通道
Async 高：检查状态大小和存储 I/O
Start Delay 高：检查上游积压和同步阻塞
JDBC Flush 高：优化目标库、Batch、连接和 SQL

直接把 Timeout 从 10 分钟改成 30 分钟，只是允许问题存在得更久。

十、验证实验

正常负载下记录 10 次 Checkpoint 的三段耗时；
人为降低 JDBC Sink 吞吐，制造稳定背压；
比较 Source、Process、Sink 的 Start Delay；
构造双输入或数据倾斜场景，观察 Alignment Duration；
开启 Unaligned Checkpoint 后比较完成时间和 Checkpoint Size；
让 HDFS/状态存储变慢，确认 Async Duration 上升；
在 JDBC Flush 中注入异常，确认 Checkpoint 失败而不是 SUCCESS；
从上一个成功 Checkpoint 恢复，校验目标业务结果。

验收结论不能只写"Checkpoint 成功"，而应能回答：

text 复制代码

Barrier 卡在哪里？
慢的是传播、对齐还是持久化？
Unaligned 是否只是掩盖背压？
Sink 的外部提交语义是什么？
恢复后是否出现重复业务结果？

十一、一句话总结

text 复制代码

Barrier 划分数据边界
Alignment 保证多输入一致
Checkpoint 保存 Source 与算子恢复状态
Unaligned 用 Channel State 换取 Barrier 快速通过
外部 Sink 仍需独立分析事务与幂等

Flink CDC 机制精讲（二）：Checkpoint Barrier 如何形成一致快照 【面试宝典】

一、为什么只保存算子内存还不够

二、一次 Checkpoint 的完整生命过程

三、单输入算子为什么相对简单

四、多输入算子为什么需要 Barrier Alignment

五、背压为什么会把 Checkpoint 拖得很慢

六、Unaligned Checkpoint 改变了什么

七、Checkpoint 成功不等于端到端 Exactly Once

八、当前项目为什么在 snapshotState() 中强制 Flush

九、Checkpoint 卡住时的排查顺序

第一步：确认卡在哪个 Subtask

第二步：沿反压方向向上找

第三步：检查同步阻塞点

第四步：再决定调参还是改瓶颈

十、验证实验

十一、一句话总结

参考资料

Flink CDC 机制精讲（二）：Checkpoint Barrier 如何形成一致快照【面试宝典】