Flink State TTL 怎么配置？为什么数据不会立即删除？
面试怎么回答
State TTL 配在 StateDescriptor 上，需要明确过期时长、何时刷新 TTL 和过期值可见性。过期通常先是逻辑不可见，物理删除可能在访问、增量清理、Full Snapshot 或 RocksDB Compaction 时发生，所以磁盘不会到点立即下降。TTL 不是精确定时器，业务超时动作应使用 Timer，并分别验证逻辑读取和物理存储指标。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
状态 TTL 设成一天，两天后 RocksDB 目录却没有立刻缩小。
这不一定是配置失效：TTL 首先定义逻辑过期，物理清理依赖访问、快照或后台 Compaction 等具体机制。
State TTL 通过状态描述符定义过期时间、刷新策略和过期可见性；逻辑过期后不一定立即释放存储，需要选择并验证清理策略。
TTL 配在 StateDescriptor 上
创建 StateTtlConfig 后，将它启用到 ValueState、MapState 等状态描述符。核心配置包括过期时长、仅创建和写入时刷新还是读写都刷新，以及过期值是否允许返回。它是状态级语义，不是给整个作业设置一个统一删除时间。
刷新策略改变的是活跃定义
OnCreateAndWrite 表示只有创建或更新状态才延长寿命，适合“最后一次业务变化”；OnReadAndWrite 连读取也续期，适合“最近一次访问”。选择错误会让高频读取但从不更新的 Key 永不过期，或让仍在使用的状态被提前清掉。
过期先表现为逻辑不可见
运行时访问状态时会检查时间戳，已过期值按配置返回空或在特定读取场景暂时可见。这个检查并不意味着底层文件中的旧键值立即被擦除，所以业务侧看不到数据，磁盘占用仍可能暂时不变。
物理清理有多条路径
可以在 Full Snapshot 时过滤过期状态，可以在记录访问过程中做增量清理，也可以让 RocksDB Compaction Filter 在后台合并 SST 时清除。每种方式的触发频率和 CPU、I/O 成本不同，生产上要结合 Backend、Checkpoint 类型和访问模式配置。
TTL 不是精确定时器
它不保证某个 Key 在过期那一毫秒触发回调，也不适合表达需要准时执行业务动作的超时逻辑。若要在超时点发送告警、关闭会话，应使用 Timer；TTL 更适合限制长期不再使用状态的保留。
验证要看逻辑与物理两套指标
构造少量 Key，停止更新并等待超过 TTL，先验证 get 是否返回空；再观察状态条目、Checkpoint 大小、RocksDB 文件和 Compaction 指标。升级或从 Savepoint 恢复时还要关注 TTL 配置兼容性，避免把配置变化当成普通参数修改。
参考资料
- Flink Working with State：https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/