考察点
这道题出自字节跳动大数据工程师一面，是 Flink 容错机制的硬核题。面试官想看你能否把抽象算法和工程实现对应起来：Chandy-Lamport 论文里讲的是"在不暂停系统的情况下记录全局一致状态"，Flink 的 barrier 就是这个思想的落地。追问常往"barrier 对齐为什么会卡、unaligned checkpoint 怎么解决"、"RocksDB 增量快照怎么做"、"savepoint 和 checkpoint 区别"走。
参考答案
Chandy-Lamport 要解决什么问题
分布式系统里做全局快照的难点在于：各节点状态在不同时间点记录，拼起来可能是一个"从未真实存在过"的状态。经典反例是转账：A 给 B 转 100 块，如果 A 的快照记在扣款后、B 的快照记在收款前，全局看这 100 块凭空消失了。Chandy-Lamport 算法（1985 年）的核心思想是：在通信信道里插入一个标记（marker），节点收到 marker 时记录本地状态，marker 之前的在途消息也计入快照，从而切割出一个全局一致的状态切面。关键性质是全程不需要暂停系统。
Flink 的四步实现
第一步，注入 barrier。JobManager 的 checkpoint coordinator 周期性（比如每 60 秒）触发一次 checkpoint，向所有 source 任务注入 barrier——一种随数据流流动的特殊记录，带 checkpoint id。barrier 把流切成两段：barrier 之前的数据属于本次快照，之后的属于下次。source 收到指令后先记录自己当前的消费位点（Kafka offset），然后向下游广播 barrier。
第二步，barrier 对齐。非 source 算子可能有多个输入通道。算子从某个通道收到 barrier 后，暂时阻塞这个通道的数据处理（缓冲起来），继续处理其他通道的数据，直到所有通道的 barrier 都到齐——这就是对齐（alignment）。对齐的意义是保证快照里"没有一条数据被算两次也没有漏算"：所有 barrier 之前的数据影响都进了状态，之后的都没进。
第三步，状态快照。对齐完成后，算子把当前状态快照到 state backend。内存后端（HashMapStateBackend）同步拷贝后异步写出；RocksDB 后端利用 LSM 的不可变特性做增量快照——只上传本次新增的 SST 文件，这是大状态（GB/TB 级）场景的关键优化。快照完成后算子向下游广播 barrier，恢复处理缓冲的数据。
第四步，确认。所有算子快照完成、sink 确认后，JobManager 收到全员的 ack，本次 checkpoint 标记为完成，元数据落盘。此后任何时刻故障，作业从最近一次完成的 checkpoint 恢复：source 重置到快照的 offset，所有算子状态回滚到快照值，重放数据——效果等价于恰好处理一次。
对齐的工程问题与非对齐 checkpoint
barrier 对齐在反压场景下会变成瓶颈：某个通道拥堵时，算子要等它的 barrier，等待期间其他通道的数据全在缓冲，对齐时间可能拖到几十秒甚至超时失败。线上表现就是"checkpoint duration 飙升、频繁超时"。
解法是 Flink 1.11 引入的 unaligned checkpoint：不等对齐，barrier 直接"插队"越过缓冲区里的数据，把缓冲区中在途数据也一并纳入快照（相当于把 Chandy-Lamport 里"信道中消息"显式存下来）。恢复时先恢复在途数据再恢复算子状态。代价是快照体积变大（多了在途数据），所以一般配置为：对齐超时阈值（alignment timeout，比如 30 秒）到了自动切换为非对齐，平时仍走对齐路径。
与恢复的联动细节
几个工程细节能体现真实经验。一是 checkpoint 的存储位置：生产上用 HDFS/S3 这类持久化存储（filesystem backend），JobManager 内存只存元数据指针。二是 retained 策略：RETAIN_ON_CANCELLATION 让作业取消后 checkpoint 不删，方便回滚重启。三是本地恢复（task-local recovery）：RocksDB 快照在本机留副本，机器没挂时恢复不用走网络拉全量。四是 checkpoint 间隔与超时时间要匹配业务：间隔太短影响吞吐（快照开销），太长则故障恢复要重放的数据多、端到端延迟毛刺大。
Savepoint 和 Checkpoint 的区别
这是几乎必追的问题。checkpoint 由框架自动触发、周期执行、面向故障恢复，生命周期归框架管，格式可能随版本变化；savepoint 由用户手动触发（或升级流程触发），面向运维操作——版本升级、扩缩容、作业迁移，格式有跨版本兼容性承诺。机制上两者是同一个东西（都是一致快照），区别在用途和生命周期。实操流程：升级前先 flink stop --savepointPath（或 cancel-with-savepoint），改完代码从 savepoint 启动，状态无缝衔接。
可能的追问
- checkpoint 失败最多的原因是什么？反压导致对齐超时、状态太大写出慢、HDFS/S3 抖动。排查顺序：先看 Web UI 的 alignment duration，再看 state size 增长曲线。
- 增量 checkpoint 为什么只有 RocksDB 能原生支持？RocksDB 的 SST 文件一旦落盘不可变，天然适合"只传增量文件"；内存后端的状态是可变哈希表，增量意味着要跟踪每次修改，成本高。
- exactly-once 和 checkpoint 什么关系？checkpoint 只保证 Flink 内部状态的一致性；端到端 exactly-once 还需要 sink 在 checkpoint 完成时两阶段提交输出，两者配合才成立。