Hadoop 的 Leader 选举，核心是靠 ZooKeeper（ZK） 做 “裁判”，保证同一时间只有一个主节点（Active）对外提供服务，另一个做备节点（Standby）随时待命。下面分核心组件和完整流程讲清楚。

一、Hadoop 里谁需要选 Leader？

Hadoop 集群有两个 “大脑”，都要做 Leader 选举：

组件	角色	选举目的
NameNode（NN）	HDFS 主节点	管理文件目录、元数据，保证只有一个 Active NN 读写 HDFS
ResourceManager（RM）	YARN 主节点	管理资源调度、作业提交，保证只有一个 Active RM 分配资源

---

二、核心依赖：ZooKeeper（ZK）

ZK 是分布式协调中心，提供三个关键能力支撑选举：

1. 临时节点（Ephemeral ZNode）：主节点创建，挂了自动消失，备节点实时监控
2. 选举锁：竞争唯一锁，谁抢到谁变 Active
3. Watcher 监听：主节点挂了，备节点秒级感知，自动触发选举

---

三、完整选举流程（以 NameNode HA 为例）

1. 初始化启动阶段

集群第一次启动时，所有 NN 节点（主备）都处于 Standby 状态，同时向 ZK 发起选举：

1. 每个 NN 向 ZK 的 /hadoop-ha/ns1 路径创建临时节点（比如 /hadoop-ha/ns1/ActiveStandbyElectorLock）
2. 只有第一个成功创建节点的 NN，会被选为 Active 主节点，状态转为 Active 并对外提供服务
3. 其他 NN 创建失败，自动转为 Standby 备节点，并对 ZK 上的临时节点加 Watcher 监听

2. 运行阶段：主节点故障触发选举

当 Active NN 挂了（进程崩 / 网络断 / 宕机），ZK 上的临时节点自动消失：

1. 备节点的 Watcher 立刻感知到节点消失
2. 备节点立即重新竞争创建临时节点，抢到锁的瞬间变 Active
3. 旧主节点恢复后，会发现自己没抢到锁，自动转为 Standby，不影响集群

3. 选举核心规则（ZK 底层）

投票时按优先级排序，先比数据新，再比节点 ID：

1. Epoch（逻辑时钟）：选举轮次，越大越优先
2. ZXID（事务 ID）：数据更新版本，越大越新
3. MyID（节点 ID）：ZK 配置的唯一编号，越大越优先

---

四、ResourceManager 选举流程

和 NameNode 几乎一样，只是 ZK 路径不同（/yarn-leader-election/rm1）：

1. 多个 RM 启动时，竞争 ZK 上的主节点锁
2. 抢到锁的 RM 变 Active，负责资源调度
3. 其他 RM 做 Standby，监听锁状态，主节点挂了自动上位

---

五、关键细节（避坑必看）

1. 必须开启 ZK 集群：至少 3 节点，保证高可用
2. HA 配置必填项：
   • HDFS：dfs.ha.namenodes.ns1、dfs.namenode.shared.edits.dir（指向 ZK）
   • YARN：yarn.resourcemanager.ha.enabled、yarn.resourcemanager.zk-address
3. Failover Controller（FC）：每个 NN/RM 都有 FC，负责监控和自动切换，不用人工干预
4. 脑裂防护：ZK 临时节点机制，保证同一时间只有一个 Active 节点，不会出现双主

---

六、通俗总结

• ZK = 裁判 + 锁：负责定主、防双主、秒级切换
• NN/RM = 选手：抢锁变 Active，挂了自动被替补
• 流程 = 抢锁→主节点→监听→锁消失→重新抢锁

这样配置后，Hadoop 集群就实现了零停机高可用，主节点挂了，备节点秒级上位，业务不中断。