Flink 增量 Checkpoint 是怎么工作的？
面试怎么回答
Flink 的增量 Checkpoint 主要由 EmbeddedRocksDBStateBackend 支持。它利用 SST 文件不可变的特点，复用之前已上传的共享 SST，本次只上传新增文件和元数据引用。这样能减少 Checkpoint 上传量，但 UI 的 checkpointed size 只是增量，不是完整状态；恢复还要下载所引用文件，所以快慢取决于网络、IOPS、文件数和 Compaction。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
“增量 Checkpoint 只保存上一次之后变化的 Key。”
这句话方向没错，但实现并不是逐条比较 Key。EmbeddedRocksDBStateBackend 复用不可变 SST 文件，只上传新增文件和元数据，让多个 Checkpoint 共同引用已有状态文件。
Flink 增量 Checkpoint 通过复用 RocksDB 不可变 SST 文件，只上传新增状态文件与引用元数据；它降低单次上传量，但恢复、清理和指标解释更复杂。
基础是 RocksDB 的不可变文件
RocksDB 把状态写入 MemTable，Flush 后形成 SST。SST 一旦生成不会原地修改，后续 Compaction 会产生新 SST。这种不可变性让 Flink 可以判断哪些文件已被上一个完成 Checkpoint 上传，哪些是本次新增。
一次增量快照保存什么
Checkpoint Barrier 到达后，Backend 创建本地快照，复用已存在于远端存储的共享 SST，只上传新 SST、私有文件和描述引用关系的元数据。所谓“增量”是相对历史已上传文件的复用，不代表新 Checkpoint 能脱离历史引用独立存在。
历史不会无限形成长链
多个 Checkpoint 可以引用同一共享文件。随着 RocksDB Compaction 生成新 SST，旧文件不再被任何保留 Checkpoint 引用后才会清理。Flink 会维护引用关系，历史并不是简单永远追加 delta。
UI 里的大小容易被误读
启用增量 Checkpoint 后，Checkpointed Data Size 通常表示本次增量上传量，不等于完整可恢复状态总量。评估状态规模还要看 Full Size、共享文件、远端存储占用和恢复下载量，不能因为单次只有几 GB 就认为状态很小。
恢复不一定总比全量快
增量恢复可以直接下载 RocksDB 文件，避免从统一快照格式重建，CPU 或 IOPS 受限时可能更快；但它可能需要获取更多分散文件，网络和对象存储请求成为瓶颈时也可能更慢。扩缩容后的重分配与 Compaction 也会影响恢复。
什么时候值得启用
大状态、Checkpoint 上传时间长、远端带宽压力明显时优先考虑。上线后同时看 alignment、snapshot、upload、checkpointed size、full size 和 restore 指标；Savepoint 与普通增量 Checkpoint 的用途和格式边界也要分清。