Flink以RocksDB为状态后端时TaskManager故障后的状态保持行为疑问

• 先破除你对RocksDB状态后端的认知误区：Flink集成的RocksDB从来不是只把状态存在TaskManager本地的孤立存储组件。它在Flink的架构定位是 本地内存+磁盘组成的热状态计算缓存层，只要你开启了Checkpoint功能，就会默认配套周期性快照机制——把本地的热状态异步备份到独立的持久化存储位置，不会把最终的状态副本只存在TaskManager本地。
• 你看到的“杀掉TaskManager后状态不丢”的完整流程根本不涉及原节点的本地数据：
  • 作业提交运行后，只要Checkpoint处于开启状态，JobManager内的Checkpoint协调器会周期性触发全链路状态快照。此时每个带状态的Task节点上，RocksDB会把当前的单词计数状态（不管是内存热数据还是本地磁盘的SST文件）打包成快照，异步上传到你配置的持久化存储地址——这个地址大概率是JobManager节点的本地磁盘，或者集群内三节点都能访问的共享路径，根本不会因为你杀掉某台TaskManager就失效。
  • 当你强制终止承载作业的TaskManager，JobManager会按照默认的作业故障重启策略，在剩下的那台可用TaskManager上重新拉起作业。新作业启动的第一步，就是从之前的持久化存储里拉取最近一次成功完成的Checkpoint对应的状态文件，在新节点上重新初始化RocksDB实例，全程不会尝试访问已经被终止的原TaskManager上的本地磁盘目录。
• 直接回应你的两个猜测：
  • Flink从来不会把全量计算状态长期存在JobManager的内存里。JobManager内存里仅存Checkpoint的元数据索引（比如Checkpoint ID、每个状态分片的存储路径、校验值），全量状态文件始终存在独立的持久化存储中，靠JobManager内存存全量状态在大状态场景下也根本不现实。
  • 不存在所谓的状态广播到JobManager的设计。JobManager既没有足够的内存容量承接所有用户作业的运行态状态，架构设计上也完全不承担用户作业的状态存储职责。
• 什么时候才会出现你原本预期的“TaskManager被杀后状态全丢”的效果：
  只有你完全关闭作业的Checkpoint功能，同时把RocksDB配置为无远程持久化的纯本地模式，此时RocksDB的状态仅存在当前TaskManager的本地目录中，一旦TaskManager被终止、本地磁盘无法被其他节点访问，作业重启后才会从初始计数开始重新计算。你测试时没复现这个场景，大概率是搭建集群时默认开启了Checkpoint，且把Checkpoint存储路径配在了不会随TaskManager终止失效的位置——毕竟你的架构里JobManager是独立运行的，只要JobManager不被kill，存在它本地路径上的Checkpoint文件就一直可以被新的TaskManager拉取。

内容的提问来源于stack exchange，提问作者Stefanos Kalogerakis