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