考察点
Checkpoint 是 Flink 容错的核心，也是区分「用过」和「懂原理」的分水岭。面试官想听的是一次 Checkpoint 从头到尾发生了什么、barrier 为什么要对齐、对齐慢意味着什么。追问会往 Checkpoint 超时排查、Exactly-Once 的依赖条件走。
参考答案
思想来源：Chandy-Lamport
Flink 的 Checkpoint 实现的是经典的 Chandy-Lamport 分布式快照算法。难点在于：流式作业的数据一直在流动，没有「全世界停下来拍张照」的时刻。算法的巧思是在数据流里插入特殊标记（barrier），用标记把数据流切成「属于这次快照的数据」和「属于下次快照的数据」，各算子各自拍快照，拼起来就是全局一致性快照。
一次 Checkpoint 的完整流程
JobManager 的 CheckpointCoordinator 周期性（比如 1 分钟）发起一次 Checkpoint，给所有 source 算子发指令。Source 记录当前消费位置（Kafka offset），然后向所有输出分区广播 barrier n。barrier 和数据一样在流里流动，严格保序。
算子收到 barrier n 后做两件事：先拍自己当前的算子状态（keyed state、operator state），异步写到状态后端（HDFS/S3），然后把 barrier 继续往下游广播。快照完成后向 JobManager 汇报「我完成了，状态句柄在这」。当所有算子都汇报完毕，这次 Checkpoint 才算完成，JobManager 记录元数据。恢复时反向操作：所有算子从最近一次完成的 Checkpoint 读回状态，source 从记录的 offset 重新消费。
barrier 对齐：多输入的麻烦
关键在有多路输入的算子（keyBy 之后的算子、双流 Join、union）。算子从输入通道 1 收到了 barrier n，但通道 2 的 barrier n 还没到——如果立刻拍快照，快照里就混进了通道 2 里「本该属于下次快照」的数据，状态就不一致了。解决办法是对齐：先到的通道暂停消费（数据进输入缓冲），等其他通道的 barrier n 都到齐，再拍快照、放行。
对齐期间，先到的通道相当于被堵住，数据积在缓冲里，下游也饿着——这就是对齐的代价：输入速率不均时，对齐时间会拉长，表现为 Checkpoint 耗时久甚至超时。
状态写入是异步增量的
拍快照不是停机拷贝。Heap 状态后端做快照时先复制引用再异步序列化，RocksDB 利用 LSM 树的不可变性直接对当前 sst 文件打快照，开启增量 Checkpoint 后每次只上传新增/变更的 sst 文件，状态量 100G 的作业单次增量上传可能只有几百 MB。这就是为什么生产上状态大就必须用 RocksDB + 增量。
工程经验
Checkpoint 间隔不是越小越好，两次 Checkpoint 之间要留缓冲（minPauseBetweenCheckpoints），同时跑的 Checkpoint 最多 1 个。对齐时长是健康度最重要的指标之一：持续对齐慢，八成是数据倾斜或反压，先查这两个，别急着调超时时间。
可能的追问
- Checkpoint 超时的排查思路？——看 Web UI 里卡在哪个算子：对齐时间长→倾斜或反压；快照写入慢→状态后端 IO 瓶颈；source 迟迟不发 barrier→source 端反压。
- barrier 会阻塞数据处理吗？——单输入算子不会，barrier 随流穿过；只有多输入对齐时会暂停先到通道，这是对齐 Checkpoint 的固有代价。
- 恢复时数据会重复吗？——source 从记录的 offset 重放，Checkpoint 完成之后又处理过的数据会被重新处理，所以端到端 Exactly-Once 还需要 sink 配合（两阶段提交或幂等），单靠 Checkpoint 只是内部状态一致。