考察点
状态是 Flink 区别于无状态流处理的核心能力，这道题考的是状态分类的清晰度和状态后端的选型判断力。面试官想听到：你知不知道状态放哪、快照怎么做、状态大了怎么办。追问会往 RocksDB 调优、状态 TTL、状态过大恢复慢走。
参考答案
状态的分类
两个维度先分清。按归属分：Keyed State 绑定在 key 上，keyBy 之后每个 key 一份，窗口、聚合、Join 用的都是它，具体类型有 ValueState、ListState、MapState、ReducingState、AggregatingState；Operator State 绑定在算子实例上，和 key 无关，最典型的是 Kafka source 记录每个分区的消费 offset。按管理方式分：Managed State 由 Flink 托管，自动快照恢复、自动重分布，开发只用这一种；Raw State 自己序列化自己管，基本被淘汰。
Keyed State 的物理分布值得展开：key 被哈希到 key-group（类似一致性哈希的槽位），key-group 是状态重分布的单位。改并行度恢复时，Flink 把 key-group 重新分配给新的算子实例，所以并行度上限由 maxParallelism（key-group 总数）决定，默认 128，大状态作业要提前调大，否则以后并行度加不上去。
三种状态后端
HashMapStateBackend（老的 MemoryStateBackend 的继承者，运行态叫 heap backend）：状态直接放 TaskManager 堆内存，访问快，快照时序列化到外部存储。适合状态小的作业（几百 MB 以内）、低延迟场景。状态一大，GC 压力和堆内存上限就是天花板。
EmbeddedRocksDBStateBackend：状态存在本地磁盘的 RocksDB 实例里，每 slot 一个 RocksDB，读写走 JNI，性能依赖 Block Cache 和磁盘 IO。唯一支持超大状态（单任务 TB 级）的选择，也是唯一支持增量 Checkpoint 的后端。代价是单点读写性能比堆内存差一两个量级，序列化开销大。
FileSystemStateBackend 已并入新体系，老代码里见到知道就行：运行态在堆、快照到文件系统。
RocksDB 增量快照
RocksDB 的 LSM 树结构里，数据落在不可变的 sst 文件上。做 Checkpoint 时，对当前文件集合打个硬链接式快照，然后只上传「相对上次 Checkpoint 新增或变化的 sst 文件」，已上传的文件通过句柄引用复用。状态 500G 的作业，每分钟增量上传可能只有几百 MB 到几 GB，这让大状态高频 Checkpoint 变得可行。
代价是恢复时要下载并合并多个增量文件，且 RocksDB compaction 会让文件引用关系复杂化，历史上 checkpoint 文件膨胀（sst 反复合并产生新文件）是个已知运维点，必要时可以定期做一次 Savepoint 重置增量链。
工程配置要点
生产大状态作业的典型配置组合：RocksDB + 增量 Checkpoint + 状态 TTL（StateTtlConfig，比如 Join 状态保留 3 天）+ RocksDB 托管内存（state.backend.rocksdb.memory.managed=true，让 Flink 统一分配 Block Cache/Write Buffer，避免手动调一堆参数）+ SSD 本地盘。还要监控 RocksDB 的实际磁盘占用和 compaction 压力，磁盘写满会让整个 TaskManager 挂掉。
可能的追问
- 状态 TTL 和窗口清理什么关系？——窗口状态由窗口生命周期管理，触发后清理；TTL 是 ProcessFunction/Join 这类手动状态的过期兜底。TTL 设短了会清掉还有用的状态，设长了状态膨胀，按业务回溯窗口定。
- 大状态作业恢复慢怎么办？——状态本地下载是瓶颈，可以开 local recovery（优先用本地快照副本）、提高恢复并行度、减少单次恢复的状态量；极端场景考虑把状态外置（如查外部 KV）换小状态。
- Heap 和 RocksDB 能混用吗？——一个作业一个后端，不能按算子选；想要混合效果只能拆作业或把热点小状态放内存缓存层自己维护。