前言
在分布式系统中，主从结构旨在保障数据一致性，主从复制使写入集中、读取分散，从而提升读取性能。通过心跳机制，若主节点出现短暂不可用，跟随节点会接管工作；但若主节点在恢复后两者都宣布自己是领导者，集群可能陷入冲突与混乱，因此需要明确、可靠的选举机制来决定领导者。
为此，大数据框架通常依赖一个统一的选举机制来确保集群的唯一领导者，避免重复领导导致的冲突。下面介绍 Zookeeper（以下简称 ZK）在选举方面的设计要点、实现方式以及在 Kafka、YARN 等场景中的应用要点。
Zookeeper 的选举与协调
Zookeeper 通过观察者模式实现对状态变化的通知与协同管理，提供对数据的集中存储、注册与变更通知等能力。当集群中的数据状态发生变化时，已注册的观察者会收到相应的反应指令，从而实现分布式服务的有序协同。
核心要点
- 集群只要有半数以上节点存活，服务就能继续提供。选举遵循奇数原则，推荐部署奇数台节点以避免并发冲突。
- 领导者由一个 Leader 与多个 FolloweR 组成，Leader 负责协调，Followers 负责数据同步与支持。
ZK 的选举机制
全新集群选举示例（五台服务器）
设有 SeRvice1 至 SeRvice5 的五台服务器，初始状态未有历史数据。若依次启动，选举过程大致如下：服务器1 启动并自投一票，未达到半数，进入 LOOKING 状态；服务器2 启动后交换选票，1、2 的投票信息相互影响，仍未达到半数，状态仍为 LOOKING。服务器3 启动后，所有节点对服务器3 投票，3 获得 3 票并成为 Leader，1、2 进入 FOLLOWING，4、5 继续按照新的投票结果进行状态转换。此过程体现了通过选举实现 Leader 的动态确定与状态同步的机制。
非全新集群选举
当运行中的集群出现节点宕机，需要重新选举时，选举过程会考虑数据 ID、服务器 ID 与逻辑时钟等因素，以确保新 Leader 的数据一致性与权威性。
逻辑时钟、数据 ID、服务器 ID
逻辑时钟从 0 开始，每次选举需保持一致；较小的选举结果被忽略，除非参与投票的节点完整。数据 ID 代表数据版本，版本更高者胜出；在数据版本相同的情况下，服务器 ID 较大者胜出，以实现权重分配与冲突避免。
Kafka 依赖 Zookeeper 做选举与协调
为什么 Kafka 需要 Zookeeper？通过协调服务，Kafka 能将生产者、消费者、Broker 等组件无状态地建立订阅关系，并实现高效的负载均衡与故障切换。
Kafka 的 Leader 维护与 ISR
Kafka Leader 维护一个动态的 in-sync Replica 集合（ISR），用于与 Leader 同步数据。当 ISR 中的 follower 超时未同步，可能会被剔出 ISR；Leader 故障时，会从 ISR 中选举新的 Leader。这一机制确保在多副本环境下的容错能力。
如果出现全部副本都不可用的情况，Kafka 将无法保证数据不丢失，需要等到 ISR 中任意一个节点恢复并接管 Leader。
ZK 及其局限性
虽然 Zookeeper 是一个强有力的协调工具，但在某些场景下需额外维护一套基础设施（如两套系统、运维复杂度上升）。在特定情况下，某些组件需要独立的高可用控制器来简化运维与故障处理。
附：为何有时会讨论放弃 ZK
将协调职责移出单一分布式系统，尽管能降低某些耦合，但也增加了系统之间的协作成本与运维复杂度，因此需要在实际场景中权衡取舍。
Hadoop 及相关组件中的高可用实现要点
HDFS 高可用
典型 HA 架构中，NameNode 在两台机器上对等运行，活动节点对外服务，备份节点仅在需要时接管。由于 NameNode 保存着集群元数据，HA 实现的核心就是确保在主节点故障时快速、可靠地切换，确保集群的持续可用性。
主备切换控制器与 ZK 的角色
ZKFailoverController（ZKFC）独立进程运行，监控 NameNode 的健康状况、实现自动主备切换。ZKFC 能及时检测节点健康，在主节点故障时通过 Zookeeper 实现自动的主备选举与切换，当前节点也支持不依赖 ZK 的手动切换模式。
原理简述
两台 NameNode 启动时，ZKFC 会在 ZK 上写入一个临时节点，并建立会话。一旦主节点失效，ZKFC 自动感知子节点变化，另一台节点接管并同步元数据，更新 FImage 等，确保集群元数据保持最新。当被接管的节点重新启动时，ZKFC 会重新进入接管状态，必要时切换回主节点。
ZKFC 的作用与工作机制
ZKFC 是 Zookeeper 客户端的一部分，负责监控和管理 NameNode 的状态。它通过健康监控、会话管理和排他锁等机制实现主备选举与切换，确保在集群出现故障时能够快速恢复服务。
YaRn 高可用概览
YARN ResourceManager 的高可用与 HDFS NameNode 的高可用类似，但 ResourcesManager 相对独立，状态信息可直接写入 Zookeeper，依赖 ZK 实现主备选举与切换。在 RM 的场景中，/yaRn-leadeR-election/yaRn1/ActiveBReadCRuMb 等临时节点用于实现 Leader 选举，最终只有一个 RM 成为 Active，其余为 Standby。
内部工作要点
Active RM 会将作业信息存放在 /RMsToRe 目录中，Active RM 负责处理心跳、作业提交等任务；当 Active RM 故障，Standby RM 通过 ZKFC 自动切换为 Active，并从 /RMsToRe 读取作业信息，重建状态并接管服务。
总结
在大数据领域，Zookeeper 的选举和协调机制被广泛应用于 HBase、Kudu、Impala 等集群的领导者选举与故障切换。核心思想是通过明确的 Leader 与 Followers、稳定的选举过程以及对数据版本与节点状态的管理，确保集群在部分节点失效时仍然能够高效、可靠地运行。
注释：本文梳理了 Zookeeper 选举与相关应用的核心要点，帮助读者理解分布式系统中领导者选举的设计思路与实际落地方式。[[[IMG_1]]][[[IMG_2]]][[[IMG_3]]]
