考察点
经典的对比题，很多人会背「Checkpoint 自动、Savepoint 手动」，面试官要的不止这个：底层格式差在哪、为什么升级作业必须从 Savepoint 恢复、哪些操作 Checkpoint 顶替不了。追问常往 Savepoint 的实际运维流程和「能不能用 Checkpoint 恢复升级后的作业」走。
参考答案
四个维度的区别
触发与生命周期：Checkpoint 由 Flink 自动周期触发、自动管理，默认只保留最近一个（state.checkpoints.num-retained 可调），作业正常取消时默认删除；它是为「故障自愈」服务的内部机制。Savepoint 由用户手动触发（flink savepoint <jobId>）或在停止作业时显式生成，文件落在指定目录，生命周期完全归用户管；它是为「计划内变更」服务的运维工具。
所有权：Checkpoint 归 JobManager 管，Flink 可以随时清理；Savepoint 归用户管，删不删你说了算，这也是为什么敢拿它做升级的依据。
格式：这是最实质的区别。Checkpoint 追求快，存的是状态后端的原生格式——RocksDB 的 sst 文件、堆状态后端的私有序列化格式，和具体实现强绑定，还有增量文件间的引用依赖。Savepoint 是规范化的全量格式（canonical format），自包含、无增量依赖，跨状态后端迁移理论上可行，兼容性好得多。
用途：Checkpoint 管「意外」，机器挂了、作业崩了，自动从最近的 Checkpoint 恢复。Savepoint 管「计划」，版本升级、改代码、扩缩并行度、迁移集群、换状态后端。
为什么升级必须走 Savepoint
改代码重新部署时，算子结构可能变化，Flink 靠算子 ID（uid）把状态和算子对应起来。Savepoint 的规范格式加上用户显式指定的 uid，让恢复时能对上号；Checkpoint 的格式和恢复流程是面向「同一份作业原地重启」优化的，拿它做变更后的恢复不在保障范围内。经验法则：任何「人为主动让作业停下来做变更」的操作，标准动作是 flink stop --savepointPath（或先 savepoint 再 cancel），新作业 --fromSavepoint 启动。
典型的 Savepoint 运维场景
- 版本升级：停旧作业产 Savepoint → 部署新包 → 从 Savepoint 启动，业务状态（窗口、Join 状态、source offset）无缝接续。
- 扩缩容：并行度 8 改 32，从 Savepoint 启动，key-group 自动重分布。注意不能超过 maxParallelism。
- 状态迁移与清理：状态膨胀异常、想重置增量链，做一次 Savepoint 再恢复，等于把状态重新整理了一遍。
- 蓝绿验证：同一个 Savepoint 起两个版本对比输出，做 A/B 或回归验证。
工程细节
Savepoint 是全量快照，大状态作业做一次可能几十分钟，要提前规划窗口。触发时作业是正常运行的，不阻塞处理（和 Checkpoint 一样走 barrier 机制）。恢复时要保证源数据还在（Kafka 保留期覆盖了 Savepoint 的 offset），否则起不来只能允许跳过。另外从 Savepoint 启动后记得重新配 Checkpoint 目录，别让新旧作业的 Checkpoint 混在一个路径下。
可能的追问
- 作业挂了重启用的是哪个？——自动恢复走最近一次完成的 Checkpoint；如果是手动干预重启，也可以指定从 retained Checkpoint 恢复（
execution.savepoint.path指向 checkpoint 目录），但这属于高级用法。 - Savepoint 失败常见原因？——磁盘空间不足、状态后端 IO 慢导致超时、作业正处于反压导致 barrier 走得慢（和 Checkpoint 同理，可配合非对齐机制）。
- uid 忘了设会怎样？——Flink 会按算子拓扑自动生成 id，改了代码拓扑变了 id 就变，Savepoint 恢复时对不上号直接报错；所以生产代码里所有算子必须显式
uid()，这是血泪级规范。