美文网首页
zookeeper的实现原理(下)

zookeeper的实现原理(下)

作者: yxktiming | 来源:发表于2018-08-30 17:48 被阅读0次

    leader 选举

    Leader选举会分两个过程:启动的时候的leader选举、 leader崩溃的时候的的选举

    服务器启动时的 leader 选举 

    每个节点启动的时候状态都是 LOOKING,处于观望状态, 接下来就开始进行选主流程。

    进行Leader选举,至少需要两台机器 ,我们选取3台机器组成的服务器集群为例。在集群初始化阶段,当有一台服务器Server1启动时,它本身是无法进行和完成Leader选举,当第二台服务器Server2启动时,这个时候两台机器可以相互通信,每台机器都试图找到Leader,于是进入Leader选举过程。选举过程如下 

    (1) 每个Server发出一个投票。由于是初始情况,Server1 和 Server2 都会将自己作为Leader服务器来进行投票,每次投票会包含所推举的服务器的myid和ZXID、 epoch,使用(myid, ZXID,epoch)来表示,此时Server1 的投票为(1, 0),Server2的投票为(2, 0),然后各自将 这个投票发给集群中其他机器。 

    (2) 接受来自各个服务器的投票。集群的每个服务器收到 投票后,首先判断该投票的有效性,如检查是否是本 轮投票 (epoch)、是否来自LOOKING状态的服务器。 

    (3) 处理投票。针对每一个投票,服务器都需要将别人的 投票和自己的投票进行PK,PK规则如下 

    i. 优先检查 ZXID。ZXID 比较大的服务器优先作为 Leader。

    ii. 如果ZXID相同,那么就比较myid。myid较大的服务器作为Leader服务器。 对于Server1 而言,它的投票是(1, 0),接收Server2 的投票为(2, 0),首先会比较两者的ZXID,均为0,再比较myid,此Server2的myid最大,于是更新自己的投票为(2, 0),然后重新投票,对于Server2而言, 它不需要更新自己的投票,只是再次向集群中所有机器发出上一次投票信息即可。

     (4) 统计投票。每次投票后,服务器都会统计投票信息, 判断是否已经有过半机器接受到相同的投票信息,对 于Server1、Server2而言,都统计出集群中已经有两台机器接受了(2, 0)的投票信息,此时便认为已经选出 了Leader。

     (5) 改变服务器状态。一旦确定了Leader,每个服务器就会更新自己的状态,如果是Follower,那么就变更为FOLLOWING,如果是Leader,就变更为LEADING。

    运行过程中的leader选举

    当集群中的leader 服务器出现宕机或者不可用的情况时,那么整个集群将无法对外提供服务,而是进入新一轮的Leader 选举,服务器运行期间的Leader 选举和启动时期的Leader选举基本过程是一致的。

    (1) 变更状态。Leader挂后,余下的非Observer服务器都会将自己的服务器状态变更为LOOKING,然后开始进入Leader选举过程。 

    (2) 每个Server会发出一个投票。在运行期间,每个服务器上的ZXID可能不同,此时假定Server1的ZXID为123,Server3的ZXID为122;在第一轮投票中,Server1和Server3都会投自己,产生投票(1, 123),(3, 122), 然后各自将投票发送给集群中所有机器。接收来自各个服务器的投票。与启动时过程相同。 

    (3) 处理投票。与启动时过程相同,此时,Server1将会成为Leader。

    (4) 统计投票。与启动时过程相同。 

    (5) 改变服务器的状态。与启动时过程相同

    相关文章

      网友评论

          本文标题:zookeeper的实现原理(下)

          本文链接:https://www.haomeiwen.com/subject/coafwftx.html