先看清状态后端把状态放在哪
做 Flink 实时计算，作业跑到一定规模后，state backend 选型就会成为一个绕不开的问题。HashMapStateBackend 和 EmbeddedRocksDBStateBackend 的核心区别，不是简单的“内存后端”和“磁盘后端”二选一，而是状态访问路径、内存模型和 checkpoint 流程都不一样。
HashMapStateBackend 把状态对象直接放到 TaskManager 的 JVM 堆内存中。算子读写 keyed state 时，访问的是内存中的 Java 对象，路径短、开销小。EmbeddedRocksDBStateBackend 则把每条状态序列化成字节，写入当前 TaskManager 本地磁盘上的 RocksDB 实例，内存主要用来做 block cache 和写入缓冲。所以前者的状态规模被堆内存限制，后者用磁盘空间换取更大的状态容量，但每次读写都要多经历一次序列化和反序列化。
本地 RocksDB 文件不是最终备份。状态真正可靠，依赖的是 checkpoint/savepoint 被写入远端持久存储；恢复时使用的也是这份快照，而不是 TaskManager 本地散落的 RocksDB 文件。
状态可靠性和状态后端其实是两件事
很多人会把状态后端和 checkpoint 存储混在一起，实际上它们解决的问题不同。state.backend 描述任务运行时状态怎么组织、checkpoint 快照如何从运行时状态生成；state.checkpoint-storage 描述快照最终写到哪里。HashMapStateBackend 配合 HDFS 或 S3 checkpoint storage，状态完全可以持久化；EmbeddedRocksDBStateBackend 不配置远端存储，也不能因为本地有文件就认为状态安全。
如果你看过 Flink 1.13 之前的资料，还会碰到 MemoryStateBackend、FsStateBackend 这些旧名字。它们在新版本中已被标记弃用，并逐渐归入 HashMapStateBackend 的语义范畴。讨论问题时，最好以当前版本的状态后端为准，否则很容易被旧术语带偏。
HashMap 与 RocksDB 在生产环境中的差别
两个后端都暴露同一套 Keyed State API，业务代码可以不变，但生产表现有明显边界。
| 对比维度 | HashMapStateBackend | EmbeddedRocksDBStateBackend |
|---|---|---|
| 状态存放 | TaskManager 堆内存 | 本地磁盘上的 RocksDB 文件 |
| 状态规模 | 受单 TM 堆内存限制 | 可超过内存，扩展到磁盘 |
| 读写路径 | 直接对象访问，吞吐高 | 多一次序列化/反序列化 |
| 内存占用 | 堆内存内部 | managed memory 中的缓存和写缓冲 |
| checkpoint | 大状态时序列化开销明显 | 可基于本地文件做增量处理 |
| 主要风险 | OOM、Full GC、checkpoint 超时 | 磁盘不足、CPU 高、RocksDB 调参复杂 |
| 适合场景 | 状态可控的中小作业 | 大状态、希望降低堆内存压力 |
还有一个容易被忽视的点：RocksDB 适合大状态的核心原因是，它在 LSM-tree 结构下会按 key-group 组织数据，checkpoint 可以基于本地文件做增量处理，而不是每轮把整份状态重新序列化一遍。所以状态越大，HashMap 的 checkpoint 成本增长越快，RocksDB 的优势才越明显。
换到 RocksDB 之后为什么可能更慢
RocksDB backend 不是“更高级”的状态后端，它的定位是让状态可以超过内存边界。因此，在一个状态只有 1GB、访问又很频繁的作业里，HashMap 的原始对象访问一定比 RocksDB 的序列化路径更有优势。相反，如果状态达到 20GB，HashMap 已经很难安全运行，RocksDB 反而是可维护的选择。
- HashMap 下状态超过内存预算，Full GC 频繁，checkpoint 处理时间越来越长。
- RocksDB 下高频更新 keyed state，反序列化和 LSM 写入让 CPU 成为新瓶颈。
- 只改了 state.backend，没调 managed memory，容器内存仍然被顶高，甚至被系统杀掉。
- 换到 RocksDB 后 checkpoint 快了，但本地磁盘写满，任务 failover 时恢复更慢。
实际项目里，很多作业不是因为状态过大才改用 RocksDB，而是听说它更适合大状态就切过去。切完发现单个 key 的 ValueState 每秒更新几千次，序列化成本叠加 LSM 写入，CPU 使用率上去了，吞吐反而降了。这种情况回到 HashMap 可能更合理。
这里还要强调一句：RocksDB 的内存并没有“消失”。block cache、write buffer 等结构仍然占用 TaskManager 的 managed memory，需要和 heap size 放在一起做预算。它能把大状态从堆中挪走，但不会让整个作业几乎不占内存。
生产配置参考
选型不建议只停留在代码评论里。生产环境通常通过 flink-conf.yaml 或提交作业时指定配置，让作业按自身状态规模使用不同后端。
# 状态规模小、追求吞吐，且堆内存可控时
state.backend: hashmap
state.checkpoint-storage: filesystem
state.checkpoints.dir: s3://your-bucket/checkpoints
execution.checkpointing.interval: 5min
# 大状态场景，切到 RocksDB
state.backend: rocksdb
state.checkpoint-storage: filesystem
state.checkpoints.dir: s3://your-bucket/checkpoints
state.backend.rocksdb.memory.managed: true上面的配置只是一个起点。RocksDB 真正落地时，还要关注 state.backend.rocksdb.memory.managed 的占比、block cache 大小、并行写文件的线程数，以及 checkpoint 并发数。不同版本 Flink 的默认行为也有差异，升级版本后最好做一次回归验证。
切换状态后端，安全路径是 savepoint
如果作业已经在生产运行，想从 HashMap 切到 RocksDB，建议先停止作业并触发 savepoint。保存完成之后，再把状态后端改成目标配置，从 savepoint 恢复。这个过程中 operator UID 和 serializer 必须保持稳定，否则状态映射可能出现问题。
直接用旧 checkpoint 跨后端恢复是一种风险更高的做法。虽然个别场景能跑通，但 Flink 对跨状态后端的 checkpoint 兼容性没有给出一张“随便换”的保证书。现实中常见的失败是状态恢复时报反序列化异常，或者恢复出的状态内容不符合预期。
选型框架和落地建议
如果你正在设计新的 Flink 作业，可以先按下面这个顺序做判断，而不是凭印象选后端。
- 估算状态体量。先算单个 key 的状态大小乘以预期 key 数量，再乘并行度，看是否落在 TaskManager 堆内存预算中。
- 看访问模式。高频随机更新的状态优先考虑 HashMap；大状态、冷热分明、需要做增量 checkpoint 的场景优先考虑 RocksDB。
- 评估运维成本。RocksDB 给作业带来更多磁盘和调参变量；如果团队没有处理 LSM 文件、列族、block cache 的经验，HashMap 的简单性也是价值。
最后，不要把状态后端当成一个“过完就忘”的配置。它是作业资源模型的一部分，应该随着状态规模变化重新评估。好的做法是让作业状态足够小：合理设置 state TTL、减少无必要的大 key、避免在 value 里塞整张大表。后端选型能兜底，但状态设计才是真正决定 Flink 作业能不能长期稳定运行的长期因素。
原创文章，作者：fudengji，如若转载，请注明出处：https://fudengji.cn/article/1046/