zookeeper 节点leader选举逻辑

ZooKeeper 三节点集群中“第二个节点成为 Leader并非固定规则而是‌按顺序冷启动且初始数据为空时‌因‌myid 较大且率先满足过半票数‌导致的选举结果 。‌‌核心原因‌启动时机关键‌仅当节点 1 先启动无法选举‌节点 2 紧接着启动‌并与节点 1 通信时两者完成第一轮投票此时节点 3 尚未加入2 票即满足3 节点集群过半数1.5”条件直接当选。‌比较规则决胜‌初始状态下所有节点 ZXID事务 ID均为 0选举算法优先比较 ZXID相同次级比较‌myid‌服务器 IDmyid 大的节点胜出故节点 2 优于节点 1。‌后续节点跟随‌节点 3 启动时集群已有 Leader直接转为 Follower 同步数据不再参与选举 。‌‌选举逻辑流程按序启动场景‌节点 1 启动‌状态为 LOOKING自投一票 (zxid0, myid1)因无其他节点通信无法过半维持选举中。‌节点 2 启动‌自投一票 (zxid0, myid2)与节点 1 交换投票节点 1 收到节点 2 投票后因 myid(2)myid(1) 改投节点 2。‌票数统计‌节点 1 和节点 2 均投票给节点 2得票数为 2超过集群总数 3 的半数2 1.5‌节点 2 立即当选 Leader‌。‌节点 3 启动‌发现 Leader 已存在直接加入为 Follower选举结束 。‌‌重要补充‌非绝对规律‌若启动顺序改变如先启节点 3则 myid 最大的节点 3 会成为 Leader若集群运行中 Leader 宕机重选则依据‌ZXID 数据新旧‌优先myid 仅作为平局打破条件 。‌核心优先级‌正式选举比较顺序为 ‌Epoch轮次 ZXID数据新度 myid编号‌仅在全新空集群且同轮次时myid 才起决定作用 。‌‌