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）选举成功，改变服务器状态

​