在 Hadoop 高可用（HA）架构中，Leader 选举是保障集群稳定的核心机制 —— 我们常听说 Leader（主节点）和 Follower（从节点），但很少有人深入聊第三种关键角色：Observer（观察者）。

一、先理清：Hadoop 的 “角色分工” 依赖谁？

首先要明确一个关键前提：Hadoop 本身（HDFS、YARN）的 Leader 选举，核心依赖 ZooKeeper（ZK）集群。

Hadoop 的 NameNode（NN）、ResourceManager（RM）只是 “选手”，而 ZK 才是 “裁判 + 调度中心”——Leader、Follower、Observer 这三个角色，本质是 ZK 集群的节点角色，正是这三个角色的协同，才让 Hadoop 的 HA 选举能够快速、可靠地完成。

所以，我们聊的 “三个角色”，是 ZK 的角色，但其作用直接决定了 Hadoop 集群的高可用能力。

---

二、三个角色深度拆解：各有分工，缺一不可

1. Leader：集群的 “决策者”

核心职责：

• 唯一的写请求处理者：所有客户端的写操作（比如 Hadoop HA 中创建 “Active 锁”）都必须经过 Leader；
• 事务发起者：同步数据到所有从节点，保证集群数据一致性；
• 选举主导者：集群初始化或 Leader 故障时，主导新一轮选举。

形象比喻：

相当于公司的 “CEO”—— 拍板决策、处理核心业务，同时向所有员工同步公司战略。

在 Hadoop 中的作用：

当 Hadoop 集群启动时，Leader 节点会接收两个 NameNode 的 “锁竞争请求”，最终判定一个为 Active NN（主节点），另一个为 Standby NN（备节点），并将结果同步给整个集群。

2. Follower：集群的 “执行者 + 投票者”

核心职责：

• 参与 Leader 选举：Leader 故障时，和其他 Follower 一起竞争成为新 Leader；
• 处理读请求：分担 Leader 的读压力，提高集群响应速度；
• 同步 Leader 数据：接收 Leader 的事务指令，同步数据到本地，保证数据一致性；
• 投票确认：Leader 发起的事务（如数据更新），需要超过半数 Follower 确认后才生效（“过半机制”）。

形象比喻：

相当于公司的 “部门经理”—— 参与决策投票、执行 CEO 指令，同时处理日常业务。

在 Hadoop 中的作用：

Hadoop HA 集群中，ZK 的 Follower 节点会参与 “Active NN 选举” 的投票，确保选举结果的合法性；同时，Follower 会实时同步 Leader 存储的 “集群状态”（如哪个 NN 是 Active），当客户端查询时，Follower 可以直接返回结果，减轻 Leader 压力。

3. Observer：集群的 “旁观者 + 转播员”（被忽略的关键角色）

核心职责：

• 不参与 Leader 选举：无论 Leader 是否故障，Observer 都不会竞争 Leader 职位；
• 不参与投票：Leader 的事务不需要 Observer 确认，不影响 “过半机制”；
• 同步 Leader 数据：和 Follower 一样，实时从 Leader 同步数据，保持数据一致性；
• 处理读请求：专门分担读压力，尤其适合读多写少的场景。

形象比喻：

相当于公司的 “市场调研员”—— 不参与决策和投票，但会同步公司所有信息，同时处理外部咨询（读请求），减轻核心团队压力。

在 Hadoop 中的作用：

当 Hadoop 集群规模扩大（比如 10 + 个 DataNode），客户端读请求增多（如频繁查询 NN 状态、Hive 元数据）时，Observer 可以承接大量读请求，避免 Follower 因 “既要投票又要处理读请求” 导致的性能瓶颈。

比如我之前维护的一个 100 节点 Hadoop 集群，初期用 3 个 ZK 节点（1 Leader+2 Follower），随着业务增长，读请求 latency 从 10ms 飙升到 50ms，添加 2 个 Observer 后，latency 直接降到 15ms 以内 —— 这就是 Observer 的核心价值：扩容读性能，不影响选举稳定性。

---

三、三个角色核心区别对比表

表格

角色	参与选举	参与投票	同步数据	处理读请求	处理写请求	核心价值
Leader	✅ 主导	✅ 发起	✅ 发起	✅	✅ 唯一	决策 + 写操作处理
Follower	✅ 参与	✅ 参与	✅ 接收	✅	❌	投票 + 读操作分担 + 故障备用
Observer	❌	❌	✅ 接收	✅	❌	大规模读请求分担 + 不干扰选举

---

四、Hadoop 集群中，ZK 角色如何协同工作？

以 HDFS HA 的 Leader 选举为例，完整流程如下：

1. 集群初始化阶段

• ZK 集群启动：1 个 Leader、2 个 Follower、1 个 Observer（假设 4 节点 ZK 集群）；
• 两个 NameNode（NN1、NN2）向 ZK 发起 “创建临时节点” 请求（竞争 Active 锁）；
• Leader 接收请求后，判定 NN1 抢到锁，将其标记为 Active，NN2 为 Standby；
• Leader 将 “NN1=Active” 的状态同步给所有 Follower 和 Observer；
• 客户端查询 “哪个 NN 是 Active” 时，可直接从 Follower 或 Observer 获取结果，无需访问 Leader。

2. 主节点故障阶段

• Active NN1 宕机，ZK 上 NN1 的临时节点自动消失；
• Follower 通过 Watcher 感知到节点消失，触发新一轮选举；
• 两个 Follower 竞争成为新 Leader，选举出结果后，新 Leader 判定 NN2 为 Active；
• 新 Leader 将 “NN2=Active” 同步给所有 Follower 和 Observer；
• 整个过程中，Observer 始终同步数据，但不参与选举和投票，不影响切换速度。

3. 大规模读请求场景

• 当 Hive 客户端、Spark 作业频繁查询 HDFS 元数据时，大量读请求会被分流到 Observer 和 Follower；
• Leader 只需要处理 “NN 状态变更” 等核心写请求，避免因读请求过多导致选举延迟；
• 即使 Observer 节点故障，也不会影响集群的选举机制和数据一致性，容错性极高。

---

五、实际配置建议：不同规模 Hadoop 集群的 ZK 角色搭配

1. 小型集群（3-10 节点 Hadoop）

• ZK 集群规模：3 节点（1 Leader + 2 Follower）
• 适用场景：测试环境、小流量生产环境
• 理由：无需 Observer，Follower 足够处理读请求，3 节点满足 “过半机制”，部署简单。

2. 中型集群（10-50 节点 Hadoop）

• ZK 集群规模：4 节点（1 Leader + 2 Follower + 1 Observer）
• 适用场景：中等流量，读请求较多（如日常 ETL、报表查询）
• 理由：Observer 分担读压力，Follower 专注于选举和投票，平衡性能和稳定性。

3. 大型集群（50 + 节点 Hadoop）

• ZK 集群规模：5-7 节点（1 Leader + 3 Follower + 1-3 Observer）
• 适用场景：高并发读请求（如实时计算、多团队共享集群）
• 理由：多个 Observer 承接大量读请求，Follower 数量保证选举稳定性，避免 “过半机制” 因节点故障失效。

---

六、常见误区：这些错误认知要避开

误区 1：Observer 是多余的，Follower 足够用？

• 错！当读请求远大于写请求时，Follower 既要参与选举投票，又要处理读请求，会成为瓶颈；Observer 不干扰选举，专门扛读请求，是大规模集群的 “性能救星”。

误区 2：Observer 越多越好？

• 错！Observer 需要同步 Leader 数据，过多 Observer 会增加 Leader 的同步压力；建议 Observer 数量不超过 Follower 数量，根据读请求压力动态调整。

误区 3：Hadoop 的 NN/RM 有 Observer 角色？

• 错！Observer 是 ZK 的角色，Hadoop 的 NN/RM 只有 Active 和 Standby 两种状态；ZK 的 Observer 通过优化选举环境，间接提升 Hadoop 的 HA 性能。

---

七、总结：三个角色的核心价值

Hadoop 的高可用，本质是 ZK 集群的 “角色协同艺术”：

• Leader：保证决策唯一性，是集群的 “大脑”；
• Follower：保证选举合法性和数据一致性，是集群的 “骨架”；
• Observer：保证大规模读请求的性能，是集群的 “肌肉”。

很多工程师在搭建 Hadoop HA 时，只关注 Leader 和 Follower，却忽略了 Observer 的价值 —— 当集群规模扩大、读请求激增时，一个小小的 Observer 就能解决大问题。

如果觉得有收获，欢迎点赞、转发，也可以在评论区分享你的 Hadoop 集群搭建经验～