Flink JobManager 高可用（High Availability）原理、组件、数据生命周期与 JobResultStore 实战

1、JobManager HA 解决的是什么问题？

1.1 默认部署的风险：SPOF

• 单 JobManager = 单点故障
• JobManager 崩溃会导致集群在控制面不可用（提交、调度、恢复都受影响）

1.2 HA 的目标

开启 JobManager HA 后，Flink 能在 JobManager 故障后恢复领导权，并尽快让作业继续执行，从而消除 SPOF。

2、HA 的核心思想：Leader + Standby 架构

HA 的基本架构是：

• 任意时刻只有一个Leader JobManager
• 同时存在多个Standby JobManagers（热备）
• Leader 挂了，Standby 通过选举接管成为新 Leader

这意味着：

• JobManager 不再是单点
• 作业可以在新的 Leader 产生后继续推进

3、HA 服务（High Availability Services）到底提供了什么能力？

Flink 的 HA 并不是“启动多个 JM 就完了”，关键在于需要一套外部/底层的 HA 服务来保证一致性与可恢复性。HA 服务封装了 3 件事：

1. Leader election（领导者选举）
   在 n 个候选 JobManager 中选出唯一 Leader

2. Service discovery（服务发现）
   让所有组件能找到“当前 Leader 的地址”（例如客户端提交作业、TM 汇报等）

3. State persistence（状态持久化）
   持久化 Leader 需要的关键状态，确保继任者接管后能恢复执行，例如：

   • JobGraphs
   • 用户代码 jars
   • 已完成 checkpoints（元信息）

可以把它理解为：Leader 负责运行“控制面逻辑”，HA 服务负责保证“控制面可以被接管且能继续”。

4、Flink 内置两种 HA 实现：ZooKeeper vs Kubernetes

Flink 官方内置两种 HA 服务实现：

4.1 ZooKeeper HA

• 适用于几乎所有 Flink 部署模式
• 依赖：需要一个运行中的 ZooKeeper quorum
• 特点：通用、经典、跨环境（Standalone / YARN / Mesos 等场景历史上更常用）

4.2 Kubernetes HA

• 仅当 Flink 运行在 Kubernetes 上时可用
• 特点：更“云原生”，避免额外维护 ZK（但依赖 K8s 体系）

怎么选：

• 你在 K8s 上：优先考虑 Kubernetes HA
• 你在非 K8s 或混合环境：ZooKeeper HA 更通用

5、HA 数据生命周期：什么时候存？什么时候删？

为了能恢复“已提交的作业”，Flink 会持久化：

• HA 元数据（存在 HA 服务里）
• 作业相关 artifacts（如 jar、JobGraph、完成的 checkpoint 信息等）

这些 HA 数据会一直保留，直到对应作业进入全局终态（globally-terminal state）：

• 成功（finished）
• 被取消（cancelled）
• 终止性失败（failed terminally）

一旦进入这些终态，Flink 会删除该作业对应的 HA 数据（包括 HA 服务中的元数据）。

这点对运维很重要：
HA 目录里“长期残留的大量 job 数据”通常意味着作业没有被正确清理或集群恢复过程中存在异常，需要结合 JobResultStore 看 dirty 记录。

6、JobResultStore：终态结果归档与“脏数据清理”机制

6.1 JobResultStore 是干什么的？

当作业到达终态（finished/cancelled/failed）后，Flink 会把最终结果做归档，写到一个文件系统路径里：

• job-result-store.storage-path

它的意义是：
即使作业结束了，也能保留“最终结果信息”，并支撑恢复/清理流程。

6.2 dirty entries：为什么会出现“脏条目”？

如果一个终态作业没有被正确清理（例如 HA artifacts 还在high-availability.storageDir的 job 子目录下），对应的 JobResultStore 记录会被标记为dirty。

dirty 的含义很直白：
“这个 job 的清理还没彻底完成，可能需要补清理”。

6.3 dirty entries 如何被清理？

dirty 条目会被纳入清理机制：

• Flink 当下就会尝试清理
• 或在一次恢复（recovery）过程中被捡起来清理

只要清理成功，dirty 条目就会被删除。

6.4 你需要关注的两个路径关系

• job-result-store.storage-path：终态结果归档位置
• high-availability.storageDir：HA artifacts（含 job 子目录）

dirty 条目通常意味着：在high-availability.storageDir下还能找到该 job 的 artifacts 子目录。

7、生产实践建议（偏运维视角）

• HA 不只是“多起几个 JM”：必须配套 HA 服务（选举/发现/持久化）
• 明确 HA 数据清理策略：定期关注high-availability.storageDir是否出现异常堆积
• 关注 JobResultStore dirty：dirty 多且长期存在，往往说明清理链路有问题或恢复过程异常
• 把 HA 存储放到可靠文件系统：HA 的 state persistence 依赖可用性（对象存储/分布式文件系统更常见）、