Flink Working Directory（FLIP-198）稳定本地恢复、RocksDB 目录与进程重启“不丢缓存”的正确姿势

1. Working Directory 是什么

Flink 支持为JobManager/TaskManager 进程配置一个工作目录，用来存储进程重启后可复用的信息。前提是：

• 进程重启时“身份不变”（resource-id 不变）
• 重启后还能访问到同一个磁盘/卷（working dir 所在路径不变、可写）

工作目录结构：

• JM：<WORKING_DIR_BASE>/jm_<JM_RESOURCE_ID>
• TM：<WORKING_DIR_BASE>/tm_<TM_RESOURCE_ID>

其中<WORKING_DIR_BASE>由process.working-dir（或进程级别的process.jobmanager.working-dir/process.taskmanager.working-dir）控制。

2. Working Directory 里会放哪些东西（为什么它很关键）

Flink 进程会把这些工件放到 working directory：

• BlobServer / BlobCache 的 Blobs（用户 jar、依赖、分发工件）
• Local state（当你开启state.backend.local-recovery时）
• RocksDB 的工作目录（RocksDB 状态、sst、log 等本地文件）

它的核心价值在于：
当 TaskManager 进程崩了并被拉起时，如果 working dir 还在且 resource-id 一致，Flink 可以复用本地 state，减少从远端 checkpoint 拉取的成本。

3. 与 io.tmp.dirs 的关系：不要再让它“随机漂移”

如果你不显式配置process.working-dir，它默认会从io.tmp.dirs随机挑一个目录当 base。
这在开发环境无所谓，但生产上非常危险：

• io.tmp.dirs往往是多个路径（甚至是临时盘）
• “随机挑选”意味着重启后可能落到不同路径
• 本地可恢复工件不再可复用（等于没配）

结论：
生产上强烈建议显式设置process.working-dir（至少对 TM 设置），并确保它在稳定大盘上。

4. 最小可用配置：让本地恢复真正生效（FLIP-201）

要实现“跨进程重启的本地恢复”，你必须同时满足三点：

1）开启 local recovery

state.backend.local-recovery:true

2）TaskManager 的 resource-id 必须是确定的（不能每次启动都随机）

taskmanager.resource-id:TaskManager_1

3）TaskManager 重启后必须使用同一个 working directory（同路径同盘）

推荐配置模板（生产常用）：

# 1) 明确指定 working dir base（不要依赖 io.tmp.dirs 的随机选择）process.working-dir:/data/flink/working# 2) 分别指定 JM/TM（可选：更精细的磁盘规划）process.jobmanager.working-dir:/data/flink/workingprocess.taskmanager.working-dir:/data/flink/working# 3) 开启本地恢复state.backend.local-recovery:true# 4) TaskManager 固定身份（每个 TM 实例必须唯一）taskmanager.resource-id:tm-01

注意：taskmanager.resource-id的值必须对每个 TM 实例唯一，例如tm-01/tm-02/...。

5. 生产部署怎么保证 resource-id 唯一且“重启不变”

5.1 单机多 TM（同一台机器跑多个 TaskManager）

你需要为每个 TM 进程分配固定且不同的 resource-id，并且要保证它们的 working dir 不互相覆盖。最稳妥做法：

• 每个 TM 一个 systemd service（或 supervisor 配置）
• service 文件里注入不同的taskmanager.resource-id

示例思路（不贴 systemd 全文，重点是参数）：

• conf/flink-conf.yaml不写死taskmanager.resource-id

• 用启动命令动态注入：

  • ./bin/taskmanager.sh start -D taskmanager.resource-id=tm-01
  • ./bin/taskmanager.sh start -D taskmanager.resource-id=tm-02

5.2 多机每机一个 TM（最常见）

每台机器写一个固定值即可，比如用 hostname 映射：

• worker1：tm-worker1
• worker2：tm-worker2

同样推荐用启动脚本或服务文件注入，避免镜像/安装包复制后忘改。

6. 磁盘与目录规划：Working Dir 放哪最合理

Working Directory 里包含 RocksDB 工作目录与本地 state，I/O 压力不小。建议：

• 放在本地 SSD/NVMe（如果你用 RocksDB state backend）
• 单独挂载点：/data/flink/working
• 保障容量：取决于 state 大小与 local recovery 策略，一般至少预留 checkpoint state 的 1~2 倍空间（保守）

同时：

• io.tmp.dirs依然可以用于“普通临时文件”，但不要把可恢复工件的命运交给它的随机性。

7. 常见坑位与排查办法

坑 1：resource-id 没固定，local recovery 形同虚设

现象：TM 重启后恢复仍然从远端拉，耗时不变
检查：日志中是否出现“local state found/used”类似信息；目录下是否出现tm_<id>且 id 每次变化

坑 2：working-dir 在容器临时层或会被清理的目录

现象：重启后目录不存在
解决：挂载持久卷；K8s 用 hostPath 或 PVC；裸机用固定大盘路径

坑 3：同机多 TM resource-id 冲突

现象：目录覆盖、Blob 混乱、莫名其妙 classpath/依赖问题
解决：每个 TM 的taskmanager.resource-id唯一

坑 4：磁盘满导致 RocksDB/Blob 写失败

现象：checkpoint 失败、task 崩溃、不断重启
解决：监控磁盘；working-dir 与 tmp 分开；必要时开启清理策略与外部日志采集

8. 一句话总结

• process.working-dir是“可恢复本地工件”的基地

• 想要跨重启复用本地 state，必须同时做到：

  • state.backend.local-recovery: true
  • taskmanager.resource-id固定且唯一
  • 重启后 working dir 路径与数据仍然存在