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 件事：
Leader election（领导者选举）
在 n 个候选 JobManager 中选出唯一 LeaderService discovery（服务发现）
让所有组件能找到“当前 Leader 的地址”（例如客户端提交作业、TM 汇报等）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 依赖可用性（对象存储/分布式文件系统更常见）、
