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:true2）TaskManager 的 resource-id 必须是确定的（不能每次启动都随机）
taskmanager.resource-id:TaskManager_13）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: truetaskmanager.resource-id固定且唯一- 重启后 working dir 路径与数据仍然存在
