在 Hadoop YARN 的 ResourceManager (RM) 高可用（HA）架构中，ZooKeeper (ZK) 扮演着至关重要的“分布式协调者”角色。它的主要作用可以归结为以下四个核心方面：

1. 自动主备选举 (Leader Election)

在 HA 架构中，通常会有两个或多个 ResourceManager（一个 Active，其余 Standby）。但是同一时刻只能有一个 RM 处于 Active 状态对外提供服务。

• 实现机制：ResourceManager 内部内嵌了一个基于 ZooKeeper 的选举器（ActiveStandbyElector）。当 RM 启动时，它们都会尝试在 ZooKeeper 中创建一个特定的临时节点 (Ephemeral Node)（例如 /yarn-leader-election）。
• ZooKeeper 保证只有一个 RM 能够创建成功。创建成功的 RM 成为 Active 节点，创建失败的 RM 成为 Standby 节点。

2. 故障检测与自动故障转移 (Failure Detection & Auto-Failover)

ZooKeeper 负责实时监控 Active RM 的健康状态，并在其宕机时触发切换。

• 实现机制：Active RM 会与 ZooKeeper 保持一个长连接（Session）。只要 Active RM 正常运行，这个 Session 就一直存在，临时节点也就一直存在。
• 如果 Active RM 发生崩溃、断网或长时间假死（如 JVM Full GC），与 ZK 的 Session 会超时断开。
• ZooKeeper 会自动删除那个临时节点，并通过 Watcher 机制 立即通知处于 Standby 状态的 RM。Standby RM 收到通知后，会立即发起新一轮的选举，成功接管集群，从而实现自动故障转移。

3. 防止“脑裂”现象 (Split-Brain Fencing)

“脑裂”是指在网络分区或其他异常情况下，集群中同时出现了两个 Active RM，这会导致资源分配混乱和数据损坏。ZooKeeper 提供了强大的隔离（Fencing）机制来防止这种情况。

• 实现机制：YARN 使用了基于 ZooKeeper ACL（访问控制列表）的 Fencing 机制。
• 当一个新的 RM 被选举为 Active 时，它会获取对 ZooKeeper 中存储 RM 状态数据的目录（RMStateStore）的独占写权限。
• 如果旧的 Active RM（可能是网络延迟导致的假死）突然恢复，并试图向 ZK 写入状态数据时，ZooKeeper 会因为 ACL 权限不匹配而拒绝其写入操作。旧的 RM 在写入失败后，会意识到自己已经失去了领导权，从而自动降级为 Standby 或直接退出（Kill 掉自己），彻底杜绝脑裂。

4. 存储 RM 恢复状态数据 (RMStateStore)

为了让 Standby RM 在接管集群后能够无缝恢复工作（不丢失当前正在运行的作业），RM 需要将关键的状态信息持久化。ZooKeeper 通常被用作高可用的状态存储后端（ZKRMStateStore）。

• 存储内容：集群中应用程序的元数据（如 Application ID、提交信息）、AppAttempt 状态、安全 Token（Delegation Tokens）等。
• 工作流程：Active RM 在运行期间会持续将这些状态更新到 ZooKeeper 中。当发生故障转移时，新上任的 Active RM 会从 ZooKeeper 中读取这些状态数据，重建内存状态，从而保证正在运行的作业（Applications）不会因为 RM 切换而失败。

---

总结

在 YARN ResourceManager HA 中，ZooKeeper 是整个高可用机制的基石。它不仅负责选出谁是老大（主备选举），负责盯着老大是不是死了（故障检测），负责防止出现两个老大（防脑裂），还负责保管老大的核心账本（状态存储），从而确保了整个 YARN 集群的 7x24 小时稳定运行。