Zookeeper选举

我们知道Zookeeper主要用于分布式协调，在Dubbo、Hadoop、Kafka都有使用。
Zookeeper集群分为Leader、Follower、Observer三种节点，正常情况下，集群中只能存在一个Leader节点。

• Leader节点负责处理读写请求、数据复制同步到Follower节点及Observer节点
• Follower节点参与Leader选举，只处理读请求，写请求会转发给Leader节点
• Observer节点不参与Leader选举，只处理读请求，写请求会转发给Leader节点，用于提升集群读能力

Zookeeper集群的每个节点之间会建立连接，客户端会与Zookeeper集群中的一个节点建立连接

Leader选举

什么情况下会触发选举Leader呢？

• 集群启动时，还没有Leader节点，所有节点都是Follower
• 集群运行过程中，Leader节点因为网络中断、奔溃退出、重启等原因与大多数节点不能正常通信

当Zookeeper集群有新节点加入或Follower节点下线，并不会重新选举Leader，新加入的节点会识别Leader节点，并从Leader节点同步数据

介绍选举过程前，先了解几个概念：

• sid，节点id，唯一标识每个节点，与myid值一致
• epoch，Leader周期，每次Leader选举，Leader周期会递增1
• zxid，事务id，64位数字，高32位代表Leader周期，低32位递增计数器；在一个Leader周期，针对每个客户端请求，当Leader生成唯一的zxid时，会对递增计数器自动加1；在一个新的Leader周期，会对递增计数器置为0
• 节点状态，Looking状态，代表Leader选举阶段；Following，代表Follower节点与Leader节点保持同步状态；Leading，代表Leader节点作为主进程领导状态

当集群刚启动时，集群中并不存在Leader，因此需要在集群中选举Leader，选举过程分以下几个阶段

• 投票阶段
  每个节点都是Follower，每个节点向其它节点发出投票（myid，zxid)，每个节点投票给自己
• 接收投票
  接收各个服务器发过来的投票
• 处理投票
  对接收到的每个投票，与自己的投票进行PK:
  首先比较zxid，zxid大的节点优先成为Leader；
  如果zxid相同，比较myid，myid大的节点优先成为Leader
  PK失败，更新自己的投票为收到的投票，然后重新将投票发出去
  PK成功，不需要更新投票，只是把自己的投票信息再次发给集群所有节点
• 统计投票
  每次投票后，节点会统计所有投票，判断是否过半节点接受了相同投票信息

• 改变服务器状态
  一旦确定了Leader，节点会更新自己的状态，Follower节点更新为Following状态，Leader节点更新为Leading状态

  
  投票过程

集群运行过程中，Leader节点挂了，同样需要重新选举Leader，选举过程与集群启动时的选举过程基本相同，唯一不同的是所有非Leader节点会首先更新自己的状态为Looking