zk 为了实现Paxos算法的快速收敛,添加Leader选举算法,只有Leader角色才可以发起提案。为了熟悉并使用zk,近来也具体看了zk(3.4.8)部分代码,主要逻辑(集群模式)分析如下:
１. zk启动,zk启动脚本是zkServer.sh
调用 (org.apache.zookeeper.server.quorum.QuorumPeerMain) 的main方法 -> QuorumPeerConfig 加载配置文件 -> QuorumPeer 实例化相关网络连接服务 -> 启动 QuorumPeer
这里主要根据自己读取源码，分析一下QuorumPeer启动时 FastLeaderElection的选举实现。
２ Leader选举算法实现(FastLeaderElection)分析，网络上相关的文章比较多，具体就是每个 QuorumPeer 启动时,会尝试向其它节占发送Leader选举信息包(Notification),
主要实现代码逻辑在 FastLeaderElection.lookForLeader()方法中,具体就是每个peer分析收到的Notification，对比其中各个字段的值,看哪一个peer获得了大多数投票。
总体代码,我基本看了一下,网络收发包,本机分析。
问题:
如果在配置文件中,没有配置(或者都配置成一样)每个peer的 long leader, long zxid, long epoch，那么每个节占的会为其初始化一个 Long.MIN_VALUE值。
如何是否存在以下情况:
如果没有配置 long leader, long zxid, long epoch，(或者有多个节点,某个值设置的一样)每个节点按初始值进行发包 ,最终会进入
图 ２
然后每个节点都等待其它其它的消息,然后同时每个peer又同时修改自己的 long , long zxid, long epoch,这样是不是存在一定的活锁情况？（当然具体可能因为网络时延的时间,应该不是每个peer都这么一样，估计就不会出现这个情况）?
为此,是否需要在 QuorumPeerConfig 加载配置文件时,验证一下 每个peer不server.id不可相同,在图 2的while中每个节点,随机一下等待时间?
以上只是个人阅读源码的一点想法,可能还没有更深入的理解,先记在这儿,后续再研读！