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

yaml 复制代码

state.backend.local-recovery: true

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

yaml 复制代码

taskmanager.resource-id: TaskManager_1

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

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

yaml 复制代码

# 1) 明确指定 working dir base（不要依赖 io.tmp.dirs 的随机选择）
process.working-dir: /data/flink/working

# 2) 分别指定 JM/TM（可选：更精细的磁盘规划）
process.jobmanager.working-dir: /data/flink/working
process.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 路径与数据仍然存在