6.2 高可用配置：给大脑配替身

6.2 高可用配置：给大脑配替身

本节摘要：TaskManager 挂了引擎能自动重拉任务，但 JobManager 挂了，作业图、检查点元数据、调度状态随进程烟消云散——除非做过高可用配置。本节拆解主备选举与元数据外置两大机制，讲清恢复时间由哪些环节构成，并给出一套可直接落地的 HA 配置与演练清单。

单点大脑的隐忧

第 2 章说过，JobManager 是集群的大脑：作业图在它手里、调度决策由它做、检查点元数据归它管。默认部署下这颗大脑是单点的——它所在进程或宿主机一挂，集群上所有作业集体失联，TaskManager 们拿着任务干等指挥。TaskManager 层的容错（第 4 章的恢复三步）逻辑上依然成立，但"谁来发起恢复"成了死结。高可用配置解决的正是这个死结：给大脑配替身，把大脑的记忆外置。

机制一：主备选举

HA 集群里同时运行多个 JobManager 实例，同一时刻只有一个主（Leader）干活，其余热备待命。"谁当主"由一个分布式协调服务裁决：候选人们去公共账本上抢一个编号，抢到者主政，其余监听该编号的存活心跳——心跳一断，幸存者们再抢一次。这套裁决机制在自建 ZooKeeper 部署里就是熟悉的 ZK 选举；在 Kubernetes 上由 Operator 内置的 HA 服务（KubernetesHAService，基于 ConfigMap 与 Lease 对象）承担同样职责，不必额外维护 ZK 集群。

选举只回答"谁干活"，不回答"新主凭什么接着干"——这就需要第二个机制。

机制二：元数据外置

新主接任时必须知道：集群里有哪些作业、每个作业的执行图长什么样、最近一次 checkpoint 的快照在哪。这些信息如果只存在老主的内存里，老主一挂就失传。HA 配置把它们外置到高可靠的分布式存储（HDFS 或对象存储）：提交作业时，Dispatcher 把作业的完整描述（作业图、依赖、配置）写进外置存储的作业目录；每次 checkpoint 完成后，元数据指针同步外置。新主上台，从外置存储读回全部真相，按最近的 checkpoint 元数据把作业从快照恢复——这正是第 4 章恢复三步的直接复用。

# 高可用总开关与集群 ID：同一 HA 集群的成员靠它互相认亲
high-availability: kubernetes
high-availability.cluster-id: flink-prod-01

# 元数据与恢复信息的外置居所：必须是高可靠分布式存储
high-availability.storageDir: hdfs://nn/ha/flink-prod-01

# 选举服务的依赖与根路径（ZooKeeper 部署形态）
high-availability.zookeeper.quorum: zk1:2181,zk2:2181,zk3:2181
high-availability.zookeeper.path.root: /flink
​

三个易错点随配置一并交代。其一，storageDir 必须独立于 Flink 集群本身的生存域——放在会随之俱焚的本地盘上等于没配。其二，cluster-id 是集群的身份指纹，多套环境（测试与生产）共用一套 HA 存储时绝不许撞号，否则两套集群互相选举、互相覆盖，是教科书级的事故。其三，HA 配置保护的是 JobManager 侧；TaskManager 的"高可用"不靠替身靠重拉——它挂了由 ResourceManager 重新申请容器、任务从 checkpoint 恢复，这套机制默认就有。

图 6-2 主备切换：一次接管的时间线

恢复时间：账要算到秒

业务方对 HA 的期待常是一句"挂了多久能好"，工程师要能把这个数拆开报账。一次完整的接管由五段时长构成：故障感知（心跳超时，通常十到三十秒）→ 选举完成（秒级）→ 读回元数据（对象存储一次读取，秒级）→ 作业恢复（重新调度任务、从 checkpoint 恢复状态，受状态大小支配，几秒到几分钟）→ 数据追平（从快照位点重放积压，受源吞吐支配）。五段里只有"作业恢复"这一段强烈依赖状态规模——HA 是编排能力，恢复速度是状态问题，把两件事混为一谈的团队常常白调选举超时，却对三个 GB 的去重状态束手无策。想把恢复时间压下来，正解回到第 4 章：增量 checkpoint、TTL 控制状态规模。

演练清单：HA 不是配出来的，是练出来的

配置合规不等于高可用成立，三个演练缺一不可。演练一：杀主。直接干掉主 JobManager 进程，验证备位接管、作业自动恢复、恢复时长记录在案。演练二：断存储。把外置存储临时摘除，验证告警清晰、行为可控（此场景允许失败，但必须知道会发生什么，而不是现场猜）。演练三：全重启。整集群重启，验证所有作业能从外置账本全部找回。三个演练跑通并写进预案，才算真的"敢睡"。

💡 关键直觉：HA 的价值不在日常，而在"大脑死亡的极端夜"。它保住的不是常态运行，而是元数据与恢复能力的生存权——毕竟 TaskManager 死了损失的是分钟，JobManager 死了损失的是全部真相。

本节要点

• JobManager 是单点大脑，HA 用两机制兜底：协调服务上的主备选举、元数据外置到分布式存储。
• 新主靠外置账本读取全部真相，按最近 checkpoint 元数据恢复作业——第 4 章恢复三步的直接复用。
• 恢复时间五段账：感知、选举、读元数据、恢复、追平；压恢复速度的正解在状态规模，不在选举超时。
• HA 三演练：杀主、断存储、全重启，练过的才是高可用，配过的只是配置。
• cluster-id 严禁跨环境撞号，storageDir 必须独立于集群生存域。

替身配好了，眼睛也该擦亮：下一节架起监控仪表盘，让异常在被业务方发现之前先被你看见。