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 件事Leader election领导者选举在 n 个候选 JobManager 中选出唯一 LeaderService discovery服务发现让所有组件能找到“当前 Leader 的地址”例如客户端提交作业、TM 汇报等State persistence状态持久化持久化 Leader 需要的关键状态确保继任者接管后能恢复执行例如JobGraphs用户代码 jars已完成 checkpoints元信息可以把它理解为Leader 负责运行“控制面逻辑”HA 服务负责保证“控制面可以被接管且能继续”。4、Flink 内置两种 HA 实现ZooKeeper vs KubernetesFlink 官方内置两种 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.storageDirHA artifacts含 job 子目录dirty 条目通常意味着在high-availability.storageDir下还能找到该 job 的 artifacts 子目录。7、生产实践建议偏运维视角HA 不只是“多起几个 JM”必须配套 HA 服务选举/发现/持久化明确 HA 数据清理策略定期关注high-availability.storageDir是否出现异常堆积关注 JobResultStore dirtydirty 多且长期存在往往说明清理链路有问题或恢复过程异常把 HA 存储放到可靠文件系统HA 的 state persistence 依赖可用性对象存储/分布式文件系统更常见、
