码迷,mamicode.com
首页 > 编程语言 > 详细

第四章 Leader选举算法分析

时间:2016-08-31 02:06:15      阅读:555      评论:0      收藏:0      [点我收藏+]

标签:

  Leader选举

  学习leader选举算法,主要是从选举概述,算法分析与源码分析(后续章节写)三个方面进行。

 

  Leader选举概述

  服务器启动时期的Leader选举

  选举的隐式条件便是ZooKeeper的集群规模至少是2台机器,以3台机器组成的服务器集群为例。在服务器集群初始化阶段,当有一台服务器(myid为1,称为Server1)启动的时候,无法完成Leader选举。第二台机器(myid为2,称其为Server2)也启动后,此时这两台机器已经能够进行互相通信,每台机器都试图找到一个Leader,干是便进入了 Leader选举流程。

  1.每个Server会发出一个投票。

  初试启动时,Serverl和Server2都选举自己为leader,每次投票包含的最基本的元素包括:所推举的服务器的myid和ZXID,以(myid, ZX1D)的形式来表示。即Serverl的投票为(1, 0), Server2的投票为(2, 0),然后各自将这个投票发给集群中其他所有机器。

  2. 接收来自各个服务器的投票。

  集群中的每个服务器在接收到投票后,首先会判断该投票的有效性,包括检查是否是本轮投票、是否来自LOOKING状态的服务器。

  3. 处理投票。

  针对收到的每一张选票,都需要将別人的投票和自己的投票进行PK, PK的规则如下:

    a.首先比较ZXID。 ZXID大的选票胜出。

    b.当ZXID相同时,myid大的选票胜出。
  对于Server1来说,初试投票是(1,0) ,接收到的投票为(2,0)。两者的ZXID都是0,对比两者的myid, Server1接收到的投票中的myid是2,大于自己,于是就会更新自己的投票为(2,0),然后重新将投票发出去。对于Server2来说,不需要更新自己的投票信息,只是再一次向集群中所有机器发出上一次投票信息。
  4. 统计投票。
  每次投票后,服务器都会统计所有投票,如果一台机器收到超过半数的相同的投票,那么这个投票对应的SID机器即成为Leader。对于Server1和Server2服务器来说,都统计收到(2, 0)这个投票信息两票。

  5. 改变服务器状态。

  服务器运行期间的Leader选举

  当leader所在的机器挂了,整个集群将暂时无法对外提供服务,集群进入新一轮的leader选举。服务器运行期间的Leader选举和启动时期的Leader选举基本过程是一致。假设当前正在运行的ZooKeeper服务器由3台机器组成,分别是Server1、 Server2和Server3,当前的Leader是Server2,在某一个瞬间, Leader挂了。

  1.变更状态

  Follower将状态变更为LOOKING

  2.每个Server发出一个投票    

  假定Served的ZXID为123 ,而Server3的ZXID为122。在第一轮投票中, Server1和Server3都会投自己,即分别产生投票(1,123)和(3, 122),然后各自将这个投票发给集群中所有机器。

  3. 接收来自各个服务器的投票。

  4.处理投票

  根据选票PK规则,server1的投票胜出。Server3将自己的选票变更为(1,123)重新投出。

  5.统计投票

  6.改变服务器状态

 

  算法分析

  在ZooKeeper中,提供了三种Leader选举的算法,分别是LeaderElection‘、UDP版本的FastLeaderElection 和 TCP 版本的 FastLeaderElection,可以通过在配置文件 zoo.cfg中使用electionAlg属性来指定,分别使用数字0~3来表示。0代表LeaderElection,这是一种纯UDP实现的Leader选举算法;1代表UDP版本的FastLeaderElection,并且是非授权模式; 2也代表UDP版本的FastLeaderElection,但使用授权模式;3代表TCP版本的FastLeaderElection。从3.4.0版本开始, ZooKeeper废弃了 0、1和2这三种Leader选举算法,只保留了 TCP版本的FastLeaderElection选举算法。

 

  关于进入Leader选举

  当ZooKeeper集群中的一台服务器出现以下两种情况之一时,就会开始进人Leader选举。
    a.服务器初始化启动。
    b.服务器运行期间无法和Leader保持连接。
  当一台机器进人Leader选举流程时,当前集群也可能会处于以下两种状态。
    a.集群中本来就已经存在一个Leader。
    b.集群中确实不存在Leader。

  第一种已经存在Leader的情况通常是集群中的某一台机器启动比较晚,在它启动之前,集群已经可以正常工作,即已经存在了一台Leader服务器。针

对这种情况,当该机器试图去选举Leader的时候,会被告知当前服务器的Leader信息,对于该机器来说,仅仅需要和Leader机器建立起连接,并进行状态同步即可。

  

  关于变更选票

  集群中的每台机器发出自己的投票后,也会接收到来自集群中其他机器的投票。每台机器都会根据一定的规则,来处理收到的其他机器的投票,并以此来决定是否需要变更自己的投票。这个规则也成为了整个Leader选举算法的核心所在。

  • vote_sid:接收到的投票中所推举Leader服务器的SID。
  • vote_zxid:接收到的投票中所推举Leader服务器的ZXID。
  • self_sid:当前服务器自己的SID。
  • self_zxid:当前服务器自己的ZXID。
  每次对干收到的投票的处理,都是一个对(vote_sid, vote_zxid)和(self_sid,self_zxid)对比的过程。
  • 规 则 1 : 如 果 vote_zxid大于self_zxid,认可当前收到的投票,并再次将该投票发送出去。
  • 规 则 2 : 如 果 vote_zxid小于self_zxid,那么就坚持自己的投票,不做任何变更。
  • 规 则 3 : 如 果 vote_zxid等于self_zxid,那么就对比两者的SID。如果vote_sid大于self_sid,那么就认可当前接收到的投票,并再次将该投票发送出去。
  • 规 则 4 : 如 果 vote_zxid等于self_zxid, 并 且 vote_sid小于self_sid,那么同样坚持自己的投票,不做变更。

 

第四章 Leader选举算法分析

标签:

原文地址:http://www.cnblogs.com/jian-xiao/p/5824328.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!