1. 初始化选举到底在解决什么问题从零构建集群的第一步做分布式系统的人大概率都绕不开 ZooKeeper。不管你是搭 Hadoop、Kafka、Doris 还是其他分布式中间件ZooKeeper 经常是那个地基角色。但很多人用 ZooKeeper 用得很熟配置文件背得滚瓜烂熟真到集群启动那一刻节点之间是怎么推选出第一个 Leader 的反而说不太清楚。这篇文章就聚焦一个场景集群从零初始化时Leader 选举的全过程。先说清楚一个概念ZooKeeper 的 Leader 选举其实分两种触发时机。一种是集群运行过程中 Leader 宕机、网络分区导致的重新选举这在生产环境里比较常见网上资料也多。另一种是集群第一次启动所有节点都是全新状态没有任何历史数据这时候也需要选出一个 Leader而且这个选举结果会决定整个集群的初始格局。标题里强调从零构建集群核心指的就是这个初始化阶段——它比运行中的重新选举更基础也更适合用来理解 ZooKeeper 选举机制的本质。我见过不少刚入门的朋友第一次搭三节点 ZooKeeper 集群启动后直接懵了三个进程都起来了日志也不报错但客户端就是连不上或者连上了报ConnectionLoss。其实你仔细去看日志大概率是卡在了初始化选举这一步。所以理解这个过程不只是为了应付面试而是真的能帮你在集群起不来的时候快速定位问题。ZooKeeper 为什么连第一次启动都要选 Leader这得从它的架构说起。ZooKeeper 是一个高可用的分布式协调服务它采用主从架构所有的写请求必须经过 Leader 处理然后同步给半数以上的 Follower 才算提交成功。读请求虽然可以由任意节点处理但底层的 ZAB 协议ZooKeeper Atomic Broadcast依然要求集群必须有一个明确的 Leader 来管理事务广播。换句话说没有 Leader就没有写能力没有写能力ZooKeeper 就失去了存在的意义。所以集群从启动那一刻起第一件事就是选 Leader这一点没有任何商量余地。这里要顺便提一个很多人误解的点ZooKeeper 的选举不是谁先启动谁当 Leader也不是管理员手动指定的而是通过一套协议自动完成。初始化选举用的算法是 Fast Leader ElectionFLE它从 ZAB 协议里演化出来专门解决多个节点各自为政、最终收敛到唯一 Leader的问题。后面所有的分析都会围绕 FLE 展开。2. 选举机制的核心概念状态、选票、zxid 与 myid2.1 五类节点状态与三张选票的含义要理解选举过程先得搞清楚 ZooKeeper 节点在选举中会处于什么状态。FLE 算法里定义了五种状态LOOKING正在寻找 Leader也就是选举进行中。所有刚启动的节点第一状态都是它。FOLLOWING已经成为 Follower接受 Leader 的同步。LEADING已经成为 Leader负责处理事务。OBSERVING观察者不参与选举也不参与投票只同步数据。另外还有一个状态叫 LOOKING 之后可能短暂出现的不参与投票状态但在初始化阶段我们只需要关注前三者。每个参与选举的节点会向集群中的其他节点发送选票也会收到别人的选票。每张选票包含三个关键信息提议的 Leader 节点 ID即 myid、该节点的事务 IDzxid、以及当前选举的轮次epoch。注意这里有个细节实际代码里选票还包含逻辑时钟logicClock和状态信息但对外表现上我们只需要记住三个值(proposedLeader, proposedZxid, proposalEpoch)。这个三元组的比较规则是选举的核心逻辑后面章节会具体讲。2.2 myid、zxid、epoch 分别代表什么myid 是 ZooKeeper 节点的唯一标识一个整数配置在data/myid文件里。它是选举中最基本的身份属性。三节点集群就是 1、2、3五节点就是 1 到 5。同一个集群里 myid 不能重复否则选举逻辑会混乱。很多人初始化集群时忘了配 myid 或者配了重复值节点启动后日志能刷出一堆网络异常就是这个问题。zxidZooKeeper Transaction ID表示节点上最近一次事务的 ID它是一个 64 位长整数高 32 位是 epoch低 32 位是事务计数。事务每次增加zxid 也会递增。在初始化阶段所有节点都是全新状态zxid 基本都是 0所以单靠 zxid 无法区分谁更有资历。这也是为什么初始化选举和运行中重新选举的结果往往不同——运行中 zxid 最大的节点应该当 Leader因为它拥有最新的数据初始化时所有节点数据都为空zxid 没差别只能靠 myid 或者其他策略来定。epoch 这里要区分两个概念。一个是选票里的提案 epoch表示这是第几轮选举另一个是 zxid 高 32 位的事务 epoch表示当前 Leader 的任期。两者都叫 epoch但作用完全不同。选举轮次里的 epoch 用于隔离不同轮次的选票防止旧轮次的选票干扰新选举事务 epoch 则用于标记数据的新旧。在初始化选举中两个 epoch 通常都是 0 或 1但算法对它们的处理是分开的。2.3 超过半数原则为什么是三节点选二、五节点选三ZooKeeper 的选举结果必须被超过半数的节点认可这个超半数不是可选项而是硬性条件。原因在于 ZooKeeper 的一致性保证任何一笔事务要提交必须复制到超过半数的节点上。这样即使发生网络分区任意两个分区里最多只有一个分区拥有超过半数的节点也就最多只有一个分区能选出一个合法的 Leader从根源上避免脑裂。这个原则直接决定了集群容错能力和部署数量的关系。三节点集群允许挂一个节点否则无法达成多数派五节点集群允许挂两个。很多人问为什么不用偶数节点原因是偶数节点在故障容错上效率不如奇数。四节点集群和五节点集群容错能力一样都允许挂两个但五节点多了一个数据副本网络开销更大。所以生产环境里最常见的部署是三个节点或五个节点三节点用于大多数场景五节点用于对可用性要求更高的场景。初始化选举时超过半数体现在选票统计上每个节点收到一张新选票后会统计当前投票箱里是否已经有超过半数的节点支持同一个 Leader。如果达到该节点就认为选举完成。对于三节点集群这个数是 2五节点是 3。3. Fast Leader Election三节点集群初始化选举完整流程拆解3.1 选举启动条件端口、配置与初始状态初始化选举发生的场景就是三台服务器第一次启动 ZooKeeper。这里我们假设一个最标准的设置三台机器myid 分别为 1、2、3每台机器的zoo.cfg都配置了三个节点的地址和端口tickTime2000 initLimit10 syncLimit5 dataDir/data/zookeeper clientPort2181 server.1zk1:2888:3888 server.2zk2:2888:3888 server.3zk3:2888:3888配置里有三个端口很多人搞不清。2181 是客户端连接端口2888 是 Leader 与 Follower 之间同步数据的端口3888 是选举期间节点间互相通信的端口。注意选举投票走的是 3888不是 2888。如果你在云服务器上部署安全组只开了 2181 没开 3888节点之间根本没法完成选举客户端也永远连不上。这是初始化集群时最容易踩的坑后面问题排查章节还会详细说。节点启动后会先读取 myid 和配置。此时所有节点都处于 LOOKING 状态各自的投票箱VoteSet为空逻辑时钟初始化为 0。每个节点会先给自己投一张票然后通过 3888 端口把这张票广播出去同时开始监听其他节点的投票消息。3.2 从发起投票到选出 Leader 的完整时序现在走一遍三节点集群的完整选举过程。为了好理解我们假设三台机器几乎同时启动实际上 ZooKeeper 允许不同时启动启动早的节点会一直等直到能和集群里其他节点建立连接。第一步节点 1 启动它处于 LOOKING先投自己一票。此时的选票内容是(epoch0, zxid0, myid1)提议的 Leader 是节点 1。节点 1 会把这张票发给节点 2 和节点 3。但它发出去之后发现节点 2 和 3 还没启动或者还没来得及建立连接所以它的票暂时没人能收到。节点 1 继续等待。第二步节点 2 启动同样投自己一票发给节点 1 和节点 3。此时节点 1 收到了节点 2 的选票开始进入比较逻辑。第三步是关键。节点 1 收到节点 2 的选票(epoch0, zxid0, myid2)后会和自己当前投出的选票(epoch0, zxid0, myid1)做比较。比较规则如下先比较选举轮次 epoch。谁的 epoch 大说明谁的选举更新采用 epoch 大的选票。epoch 相同的情况下比较 zxid。zxid 越大说明节点数据越新采用 zxid 大的选票。epoch 和 zxid 都相同的情况下比较 myid。myid 越大优先级越高。当前两票都是epoch0, zxid0所以进入第三步myid 2 大于 myid 1节点 1 决定把票改投给节点 2。此时节点 1 的投票箱里有两张票一张是自己原来的投给节点 1一张是新收到的投给节点 2但自己当前的对外选票已经更新成了投给节点 2。节点 1 会把更新后的选票再次广播给节点 2 和节点 3。同一时刻节点 2 也收到了节点 1 的选票。它发现节点 1 的myid1小于自己的myid2所以节点 2 不会投给节点 1继续保持自己的选票不变。到这里节点 1 和节点 2 都已经把票投给了节点 2。节点 1 统计投票箱发现有两张票都投给了节点 2超过了三节点集群的多数派阈值 2于是节点 1 认为选举完成Leader 是节点 2。节点 2 自己也统计发现自己的一票加上节点 1 的一票也是 2 票同样认为选举完成。第四步节点 3 启动。它处于 LOOKING先投自己一票发给节点 1 和节点 2。节点 1 和节点 2 这时已经处于 FOLLOWING 状态了收到节点 3 的选票后会直接回复自己当前已经选定的 Leader 信息即节点 2同时通知节点 3不要再选了Leader 已经确定。节点 3 收到回复后发现已经存在一个达到多数派的 Leader节点 2 已经有了 2 票于是也承认这个结果把自己的状态切换为 FOLLOWING。至此三节点集群完成初始化选举Leader 为 myid2 的节点。整个过程如果画成时间线会很直观但这里不画图用文字描述就是先启动的节点互相比较、快速收敛到某个候选者达到多数派后启动的节点直接接受既成事实。3.3 为什么选票比较要按 epoch、zxid、myid 的顺序理解这个优先级顺序是理解整个选举算法的一把钥匙。epoch 排第一因为它代表着选举轮次的新旧。设想一个场景集群运行中一轮选举已经完成Leader 是节点 2大家各就各位了。这时候如果某个节点因为网络抖动没收到选举结果通知它还在 LOOKING还在发旧轮次的选票。如果其他节点用一个旧轮次的票去覆盖新轮次的结果整个集群的一致性就崩了。所以 zooKeeper 规定任何节点的选票如果它的 epoch 小于当前节点记录的 epoch直接忽略。只有 epoch 更大的选票才能覆盖当前选票代表一轮新的选举开始了。zxid 排第二因为它代表数据新旧。Leader 最重要的职责之一就是拥有最新的数据这样才能在数据同步时把最新状态同步给 Follower。如果让一个 zxid 较小的节点当选它的数据是旧的同步时就得从别的节点拉数据逻辑上就颠倒过来了。初始化时所有节点 zxid 都是 0无法区分所以走到了第三层。myid 排第三它纯粹是打破平局的最后手段。因为 zxid 可能相同尤其是初始化阶段但 myid 是集群里强制唯一的。myid 大的优先这个规则简单、无歧义、所有节点都可以独立计算不需要额外通信就能达成一致。不过 myid 大不代表节点性能好这只是一个约定俗成的规则不是最优策略。如果你希望某个节点当 Leader可以把它的 myid 配大一点或者让它第一个启动并在它启动后再启动其他节点。当然这不是官方推荐做法但确实有人这么干。这里还要注意一点在 ZAB 协议的新版实现中选票比较引入了提议的 epoch和当前节点的 epoch两层判断实际逻辑比上面三步要稍微复杂一点。但本质思想不变先保证选举轮次正确再比较数据新旧最后用 ID 打破平局。理解了这个主线看源码时就不会被各种分支绕晕。4. 选举完成后的数据同步与集群对外可用4.1 Learner 连接 Leader 并进入 FOLLOWER 状态选举结果出来之后集群并不能立刻对外提供服务。Leader 确定了但每个 Follower 都还需要和 Leader 建立连接、同步数据、确认彼此状态一致然后整个集群才真正可用。这个环节在 ZooKeeper 里叫 Learner 注册与数据同步。Leader 和 Follower 之间的数据同步走 2888 端口。选举完成后Follower 会向 Leader 发起一个连接请求带上自己的 myid 和当前最新 zxid。Leader 收到请求后会把 Follower 的信息记录到自己的 Learner 列表里然后根据 Follower 的 zxid 与自己的 zxid 的关系决定采用哪种同步策略。在初始化场景下所有节点的 zxid 都是 0没有任何历史事务。这个情况下实际采用的同步策略是同步全部快照——但快照也为空所以 Leader 实际上只是发送一个空的快照信息然后告诉 Follower 现在可以开始接收后续事务了。整个过程非常快几乎是在毫秒级别完成。这也是为什么三节点集群启动后几秒钟就能对外提供服务。同步完成后Leader 会给 Follower 发送一个确认成为 Follower的消息Follower 状态从 LOOKING 切换为 FOLLOWING。集群的写能力就此生效客户端可以开始创建节点、监听事件、存取数据了。4.2 初始化场景下的三种数据同步方式很多人以为所有 Follower 都是从 Leader 拉全量数据其实不对。ZooKeeper 的数据同步根据 Follower 与 Leader 的数据差异程度分为三种方式直接同步DIFFFollower 的 zxid 和 Leader 的 zxid 差别不大Leader 只需把 Follower 缺失的事务增量delta发送给它。这是运行中最常见的方式。回滚同步TRUNCFollower 的 zxid 比 Leader 的还大说明 Follower 上存在一些 Leader 没有的事务比如上一个 Leader 已经广播了一部分事务但未提交就挂了。此时必须把 Follower 上多出来的事务回滚掉再执行直接同步。重新同步SNAPFollower 的 zxid 落后太多或者 Follower 没有历史事务比如初始化场景Leader 直接把当前全量快照发送给 Follower然后 Follower 应用快照再开始接收增量事务。初始化选举属于第三种。由于三节点都是空数据Leader 发送的空快照瞬间就能同步完成。这也是为什么初始化阶段集群从启动到可用非常快的原因。这里有一个容易忽略的细节初始化同步完成后Leader 的 zxid 会从 0 开始递增吗并不是。ZooKeeper 在初始化启动时会生成一个初始的 epoch当前实现是 1zxid 的高 32 位就是这个 epoch。所以你在初始化之后的新节点上创建第一个事务看到的 zxid 不是 1而是像0x100000001这样的值。高位的 1 就是 epoch表示这是第一个 Leader 任期内的第一个事务。这个细节在排查数据一致性问题时偶尔会用到了解一下没坏处。4.3 从节点启动到对外可用的完整路径总结整个初始化的完整路径是每个节点读取配置和 myid进入 LOOKING 状态。节点通过 3888 端口广播选票比较 epoch、zxid、myid。某个节点获得超过半数的选票成为 Leader进入 LEADING 状态。其余节点接受选举结果进入 FOLLOWING 状态。Follower 通过 2888 端口连接 Leader进行数据同步。Leader 确认所有 Learner 状态一致后集群对外可用。这六步每步都可能出问题。有的问题在日志里表现很明显比如节点一直 LOOKING有的问题很隐蔽比如集群能启动但时不时报错。下面重点讲一讲我在实操中遇到过的典型问题。5. 初始化选举中的常见问题与排查经验5.1 集群一直卡在 LOOKING 状态先查端口和 myid这是初始化集群时最常见的现象三台机器都启动成功了日志也没有致命报错但 ZooKeeper 进程就是一直处于 LOOKING客户端连不上。遇到这种情况我建议按顺序排查第一确认三个节点的 3888 端口能互相访问。不要只看本机端口是否在监听还要从另外两台机器 telnet 一下。很多云服务器安全组默认只放行了 2181没放行 2888 和 3888结果就是客户端能连第一台机器但集群内部完全不通。用telnet zk2 3888测一下就知道。第二确认dataDir目录下的 myid 文件内容正确。常见错误包括myid 文件不存在、文件内容是 1 带空格、或者文件权限不对导致 ZooKeeper 读不到。ZooKeeper 启动时会检查 myid 文件如果读不到或者内容非法会直接报错退出不会处于 LOOKING。所以如果进程还在但卡在 LOOKINGmyid 文件大概率是好的重点还是网络问题。第三确认三台机器的zoo.cfg一致。尤其是 server 列表的写法server.1zk1:2888:3888这里的主机名必须能被 DNS 或 hosts 解析否则节点之间无法找到对方。建议在/etc/hosts里显式写好三个节点的 IP 和主机名映射不要依赖外部 DNS。还有一个小技巧看 ZooKeeper 的日志输出。初始化选举失败时日志里通常会出现Notification time out或Cannot open channel to X之类的字样前者说明节点在等待其他节点的投票消息后者说明节点压根连不上对端。这两种错误指向的排查方向完全不同前者查 3888 端口后者查主机名解析和网络连通性。5.2 选出的 Leader 不是我以为的那个节点理解默认策略另一个常见情况是三个节点都起来了集群也正常但选出来的 Leader 不是管理员设想的那台机器。如果初始化时没有配置 Leader 偏好ZooKeeper 会默认按规则选出 zxid 最新初始化时大家都一样且 myid 最大的节点。也就是说myid 为 3 的节点大概率会成为 Leader——前提是它正常参与了投票。但有时你会发现 Leader 不是 myid 最大的节点而是 myid 第二大的甚至是第一个启动的节点。为什么因为选举是一个动态过程。如果节点 3 启动得特别晚节点 1 和节点 2 在它启动之前已经完成了选举选出了 myid 最大的即节点 2作为 Leader。等节点 3 启动时它只能接受既成事实。所以初始化顺序会影响选举结果。如果你想让某个指定的节点当 Leader比较实用的做法是在zoo.cfg里给该节点配置server.3...并让它的 myid 最大同时先启动它让它和其他节点建立通信后再启动其余节点。但这不是一个绝对可控的方法只是提高了概率。真正需要严格指定 Leader 的场景应该用 Observer、Quorum 之类的机制做更精细的控制初始化场景下一般不需要纠结这个。5.3 集群启动后频繁 Leader 切换检查心跳超时参数还有一种情况集群初始化成功了但过一会儿日志里出现LEADER ELECTION FAILED或者Time To Pay之类的错误Leader 切换了。这通常不是初始化选举本身的问题而是心跳超时配置不合理。ZooKeeper 的tickTime是基础时间单元initLimit是 Follower 初始连接和同步的时间上限syncLimit是 Leader 与 Follower 之间正常通信的请求和响应超时上限。如果syncLimit设置得太小比如 2而网络延迟稍微高一点Follower 就会认为 Leader 失联触发新一轮选举。三节点集群如果频繁进入选举客户端会出现间歇性连接失败非常难排查。一个经验值在虚拟机或云服务器上部署时tickTime2000、initLimit10、syncLimit5是比较常见的组合。如果网络环境不好可以把syncLimit调大到 10 甚至 15。注意initLimit和syncLimit的单位是 tick 数不是秒。所以syncLimit5表示 5 个 tick即 10 秒。5.4 网络分区与脑裂超过半数原则的实际意义最后说一个概念性的问题脑裂。ZooKeeper 的选举机制是如何避免初始化阶段出现两个 Leader 的假设三节点集群节点 1 和节点 2 在一个机房节点 3 在另一个机房两个机房之间的网络中断了。这种场景下节点 1 和节点 2 还能互相通信它们之间可以完成选举选出一个 Leader比如节点 2。节点 3 孤身一人在另一个机房它虽然也能给自己投票但只有一票永远无法达到超过半数的 2 票阈值所以它会一直保持在 LOOKING 状态不会对外提供写服务。这就避免了两个机房各选出一个 Leader、各自为政的脑裂情况。这个原理说起来简单但很多人实际部署时容易忽略多数派的物理分布。比如你把三个节点部署在同一台物理机的三个 Docker 容器里看起来是高可用实际上一台机器挂了整个集群就全挂了。真要做跨机房容灾至少要把节点分散到两个以上的故障域里确保任意一个故障域失效后剩下的节点仍然能凑够多数派。我在实际工作中见过一个比较极端的例子某个团队把五节点集群部署在两个机房3 个在一个机房2 个在另一个机房。结果做主备切换演练时切断了两个机房间的网络3 节点的机房正常选举出 Leader2 节点的机房因为达不到多数派所有客户端全部连接失败。这其实是符合预期的行为但业务方一开始不了解以为集群故障了。所以理解多数派原则不只是技术问题还涉及到容灾方案的预期管理。6. 一些实操心得与建议写到这里初始化选举的机制和常见问题基本都覆盖了。最后分享几点我个人在实际操作中的体会。第一个心得初始化选举的过程不要只看最终结果要看过程。ZooKeeper 的选举日志其实很有信息量启动时加上-Dzookeeper.log.levelDEBUG可以看到每个节点收到选票、更新选票、达成共识的完整过程。第一次搭集群时建议用这个级别跑一遍把日志留好。后面出了问题对照正常日志排查会快很多。第二个心得部署 ZooKeeper 时最好用一个统一的启动脚本同时控制三个节点的启动顺序和启动间隔。不要手动一台一台敲命令容易漏掉某个节点的配置或者记错启动顺序。我习惯写一个简单的脚本先检查所有节点的 myid 和配置文件再依次启动最后统一检查 2181 端口是否监听、集群状态是否正常。这个过程本身不复杂但能避免很多低级错误。第三个心得如果你同时接触过多套分布式中间件比如 Kafka、HDFS、Doris会发现它们的很多设计思路是相通的。Kafka 的 Controller 选举、HDFS 的 NameNode 切换都借鉴了类似 ZooKeeper 的多数派思想。把 ZooKeeper 的初始化选举理解透了再去学其他中间件的主节点选举往往能举一反三。ZooKeeper 的初始化选举只是它整个运行机制的一个入口。等集群稳定运行之后还有数据同步、会话管理、Watcher 通知、ACL 权限等一系列机制在背后支撑。但从从零构建集群核心这个目标来看弄明白初始化选举你就算真正迈过第一道坎了。现在再回头看那些让你头疼的启动日志是不是觉得没之前那么神秘了