第 198 题：状态过期清理，TTL与增量Checkpoint的权衡？
题目
状态过期清理，TTL与增量Checkpoint的权衡？
完整讲解
一、状态过期的需求
流处理中 keyed state（如 MapState、ValueState）会随 key 长期存在；若 key 对应会话、用户等有时效性，不清理会导致状态无限增长、 checkpoint 与恢复变慢、甚至 OOM。状态过期清理：对超过一定时间未更新的 key 做淘汰（TTL） 或压缩。
二、TTL（Time-To-Live）
- 含义：为 state 配置 TTL，每条 entry 或每个 key 在最后写入后经过 TTL 时间即视为过期，访问时清理或不可见。Flink 的 MapState/ValueState 等可配置 TTL（如 1 天），由状态后端在读写时检查并清理。
- 策略：通常按 last access 或 last update 计时；可选 OnCreateAndWrite / OnReadAndWrite。TTL 缩短可减小状态与 checkpoint，但可能把仍会到来的 key 提前清掉（如会话未结束），需按业务设定。
三、增量 Checkpoint 的权衡
- 全量 Checkpoint：每次把完整状态写出；状态大时 IO 与时长都大。增量 Checkpoint（RocksDB）：只写出相对上一次的增量，减小 IO、缩短 checkpoint 时间。
- 与 TTL 的关系：TTL 清理后状态变小，全量 checkpoint 也变小；增量 checkpoint 依赖 RocksDB 的 SST 增量，过期数据在 compaction 时被物理删除，增量文件会逐步变小。若 TTL 很短、状态轮转快，增量收益明显；若状态几乎只增不减，增量仍能减少单次 IO。
- 权衡：TTL 设太短可能误删、设太长状态大；增量 checkpoint 恢复时需合并多代增量，恢复可能略慢，但通常可接受。生产常见：开 TTL + RocksDB 增量 checkpoint，按业务调 TTL 与 checkpoint 间隔。
面试要点
- 能说明状态过期清理的必要性（防状态无限增长、OOM）；能解释 TTL 的含义与配置（按 last access/update）。
- 能对比全量与增量 Checkpoint；能说明 TTL 与增量 Checkpoint 的配合（状态变小、compaction 清理）。
- 能简述 TTL 与 checkpoint 间隔的调参权衡。
记忆要点
- 状态过期=TTL，超时未更新则清理；配置 last access/update。TTL 缩短减小状态与 checkpoint。
- 增量 Checkpoint（RocksDB）=只写增量，与 TTL 配合减小 IO；恢复需合并增量。