zk集群运行进程中，处事器推举的源码分解

上面说过QuorumPeer检测到当前处事器的状态是LOOKING的时辰，就会举办新一轮的推举，通过setCurrentVote(makeLEStrategy().lookForLeader());也就是FastLeaderElection的lookForLeader来举办初始选择,实现的方法也很简朴，首要的逻辑在FastLeaderElection.lookForLeader中实现：

根基流程先声名一下：

• QuorumPeer会轮询搜查当前处事器状态，假如发明State是LOOKING，挪用Election的lookForLeader来开始新一轮的推举
• FastLeaderElection会起首将logicallock++,暗示新的一轮推举开始了
• 结构初始的选票，Vote的内容就是选本身，然后关照zk集群中的其他呆板
• FastLeaderElection会一向轮询查状态，只要是LOOKING态，就会从recvqueue中获取其他处事器同步的选票信息，为了利便声名，记录为n
• 按照n的票选信息状态，做相干的操纵

LOOKING: 都处于无Leader态，较量一下选票的是非，看是否更新本身的选票，假如更新了就同时关照给其他处事器

FOLLOWING、LEADING:声名集群中已经有Leader存在，更新一下本身的状态，竣事本轮投票

OBSERVING：这票没什么卵用，直接舍弃(OBSERVER是不参加投票的)

按照上面的流程，能够声名一下FasterLeaderElection确定选票更优的计策：

• 假如外部投票中被推选的Leader处事器推举轮次大于自身的轮次，那么就更新选票
• 假如推举轮次同等，就比拟两者的ZXID，ZAB协议中ZXID越大的留存的信息也越多，因此假如ZXID大于本身的，那么就更新选票
• 假如ZXID也同等，比拟两者的SID，SID大，则优先级高

总结：

以上就是zk的默认选票流程，凭证ZAB协议的两种状态说明：

• 初始化的时辰，处于统一轮次举办投票直到投票选择出一个Leader
• 瓦解规复阶段：

Leader处事器挂了，那么经验的和初始化流程相同的进程，选择Leader

Follower处事器挂了，那么本身在执行推举的进程中，会收到其他处事器给的Leader选票信息，也可以确定Leader所属

【编辑保举】

1. 深入分解 Web 处事器与 PHP 应用的通讯机制 - 把握 CGI 和 FastCGI 协议的运行道理
2. 企业级 Linux 处事器 10 大安详防护要点
3. 从四种场景出发，具体解读无处事器架构的落地应用
4. HBase的处事器系统架构
5. 搭建文件分享处事器，着实也可以很简朴-HFS

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!