Question

Zookeeper选主过程，理论和源码结合，看这一篇足够了

Answer 1

【共4239字，阅读需要15分钟】

Zookeeper作为Dubbo生态的默认注册中心，得到了非常的普遍的应用，虽然后来阿里又出了nacos，但是不可否认的是ZK仍然是一款非常优秀的开源产品，非常优秀的注册中心备选方案。

ZK有很多特性，本篇文章主要介绍ZK的选主过程（后宫佳丽三千，我就独宠你一人）

要说选主的过程，我们首先得了解ZK到底有哪些节点，这些节点充当得角色是什么？

ZK本身得节点主要分为三类：

Leader：主要是负责数据的写入，如果超过半数同意，那么就广播进行写入；

Follower：主要负责查询请求并将写入请求发送给leader，参与选举和写入投票；

Observe：也是负责查询请求并将写入请求发送给leader，不参加投票，只被动接收结果

获取半数投票以上的节点成为leader节点。

万事万物都有一个准则，好的比较坏的，坏的比较更坏的，世上本没有痛苦，痛苦都是自己寻找的结果，海燕你可长点心吧，哎呀跑偏了。

ZK比较的时候有三个指标或者三个维度：

（1）任期

（2）事务ID（ZK中的事务ID）

（3）节点编号（集群中每个节点的编号）

根据以上三个指标就可以说出最终的结论了：选择任期大的，任期一样选择事务ID大的，前两个都一样，选择节点编号大的。

就这么简单？是的。规则就是这么简单，但是源码还是有那么一丢丢的绕。

源码看着相对比较枯燥，但是作为一个手艺人，怎么能不去了解怎么做的呢，我们先来梳理一下代码的流程，方便更好的看第四部分内容。

节点先投自己一票，然后进行广播

节点内部循环进行消息接收

收到消息后

如果消息为空，就进行重新发送消息或者建立连接

如果消息不为空，且消息接收者和投票的leader都是合法节点就进行下边步骤。

如果节点为looking节点

根据当前节点的投票和接收到的投票进行比较来决定是否需要再次发送投票并且记录投票的结果

每次都判断记录的票数，如果过半就进行节点状态的设置

选主的逻辑是在lookForLeader开始的，像金字塔的第一块砖一样，我们先看ZK选主的第一块砖lookForLeader，第一次看源码得时候一定要把握主线，忽略从线，等主线完全理清楚了之后才去处理从线，要不会陷入迷宫之中。

下边就是主要的投票代码，看里边的注释：

更新投票或者投票的方法为：

发送通知的方法为：

待到山花烂漫时，她在丛中笑，消息都已经发完了，肯定就到了接收到选票的时候应该怎么操作了，接收选票的代码也是在lookForLeader中：

接上代码继续讨论，校验发送投票节点的状态，我们从本文的第一章节知道Observe节点是不参与投票的，只是转发写请求和被动接收数据，负责查询请求，所以从代码中我们也可以看出来：

当发送投票的节点状态是FOLLOWING和LEADING时，代表发送节点已经选举完成，所以处理方法的逻辑都是一样滴，这部分限于篇幅太长，暂时就不深入讨论了，感兴趣的朋友可以私信我或者加我微信号M_P_E_D进行交流和沟通。

终于到重头戏了，咱们看看LOOKING状态时的代码：
我们先把totalOrderPredicate方法放前边，这个其实就是选举leader的规则的实现。

道阻且长，行则将至，行而不辍，未来可期，加油。