zookeeper中的选举机制

选举机制发生的时间

  • 集群启动时

  • leader节点崩溃时

选举算法

zookeeper提供了三种方式:

  • LeaderElection

  • AuthFastLeaderElection

  • FastLeaderElection

    默认的算法是FastLeaderElection,所以主要分析它的选举机制。

选举中的概念

选举参与的参数

  • ZXID 事务id

    为了保证事务的顺序一致性,zk采用了递增的事务id号(zxid)来标识事务,所有的提议(proposal)都在被提出的时候加上了zxid,实现中zxid是一个64位的数字,他高32位是epoch,低32用于递增计数。

值越大说明数据月新,在选举算法中数据约新权重越大

  • myid 服务其id

    服务器id越大,选举的权重越大

  • epoch 逻辑时钟

    或者投票次数,同一轮投票过程中的逻辑时钟值是相同的,每一次投票完成 epoch就会+1,然后与接受到的其他服务器返回的投票信息中的数值相比,根据不同的值做出不同的判断

选举状态

  • LOOKING,竞选状态。

  • FOLLOWING,随从状态,同步leader状态,参与投票。

  • OBSERVING,观察状态,同步leader状态,不参与投票。

  • LEADING,领导者状态。

leader选举逻辑描述

启动时的leader选举

每个节点启动时的状态都是looking,处于 竞选状态,接下来就是开始进行选取leader的过程。

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

(1) : 每个server都发出一票,由于是初始情况,server1和 server2 都会先投自己,将自己作为leader,每次投票都包含 myid,zxid,epoch。假设 server1的信息为(1,0),server2的信息为(2,0)。然后将投票信息广播给其他机器。

(2): 接受来自各个服务器的投票信息。收到信息后,首先判断投票信息的有效性, 如检查是否是本轮投票(epoch),是否来自looking状态的服务器。

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

  • 优先检查zxid,zxid 比较大的服务器作为leader

  • 如果zxid相同,那么就比较myid,myid较大的作为leader。

(4): 统计投票,每次投票后,服务器都会统计投票信息,判断是否已经有过半机器接受到相同的投票信息,

(5): 改变服务服务器状态,一但完成选举,确定leader,每个服务器就会更新自己的状态,如果是follower 那么就变更为FOLLOWER,如果是leader 那就变更为LEADER

运行过程中的leader选举

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

(1) 状态变更,leader挂掉后,余下的非observer服务器都会将自己的服务器状态变更为LOOKING状态,然后开始选举过程

(2) 每个server会发出一个投票,在运行期间,每个服务器上的zxid可能不同,假设server1的zxid为123 ,server3的zxid为122,在第一轮的投票中,server1或server3都会投自己,产生投票信息(123,1),(3,123)。然后将各自投票发送给集群中所有机器,接受来自各个服务器的投票,与启动过程相同。

(3) 处理投票

(4) 统计投票

(5)选举成功,改变服务器状态


 

 

 

 

 

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐