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中每个节点,随机一下等待时间?

 

　　　　　　　　　　　　　以上只是个人阅读源码的一点想法,可能还没有更深入的理解,先记在这儿,后续再研读！