Zookeeper源码分析之leader选举流程分析

1.为什么要进行leader选举？

众所周知，Zookeeper是一款分布式协调调度框架。生来就是为了解决分布式中有关问题的。而今天要说的leader选举，能帮我们解决分布式环境下的数据一致性问题。在集群模式下，Zookeeper集群的节点分为leader，follower，observer三种角色。

leader：集群中的决策者，只有产生一个，用来处理客户端的所有事务性请求，如create，delete等。

follower：leader的跟随者，可以有多个，只用来处理客户端的非事务性请求，如getChildren，isExists等。

observer：观察者，用来转发事务的请求，与follower区别不到，但是其不参与leader选举。

集群中，leader和follower分工明确，各司其职，让我们在分布式环境下的数据一致性得到了很好的保障。

2.什么时候会进行leader选举？

先了解一下各节点在集群的状态变化。在集群中，节点的状态有4种，分别是：looking，following，leading，observing。在没有选举出leader之前，每个节点的最初状态都是looking。还有一种情况是，当一个正常运行的集群突然由于网络等原因导致leader节点挂掉或者彼此之前无法通讯，此时会重新进行选举，所有的节点又会恢复到looking状态。当leader节点选举出来之后，所有的节点就会被更新成leading或者following。leader选举只会发生在looking状态之前，也就是集群启动时，或者leader节点挂掉后这两种情况。

3.leader选举的大致流程

• 先了解一下下面几个概念：

myid：每台服务器的id标识，在zoo.cfg配置集群模式会有体现，id越大，能力越强，成为leader的几率越大；

zxid：每台服务器标识数据的事务id，事务id越大，表示当前节点的数据越新，能力越强，成为leader的几率越大；

electionEpoch：逻辑时钟，用来判断各个服务器之间是否是同一轮leader选举，每进行一轮，会进行自增；

peerEpoch：每台服务器给出投票中被推举为leader的逻辑时钟，epoch越大，成为leader的几率越大；

这几个值，都会成为选举的重要参数，在选票PK时，会进行优选级的比较，最终选出最优秀的机器，推荐为leader。

• leader选举流程

1.在集群刚开始启动时，每个节点都会生成一个选票，默认最开始都是会推选自己为leader；

2.各服务器间通过建立socket连接，进行相互通讯，用来发送和接收选票，当然，这一步在集群启动的时候就会建立；此处有一个连接建立规则，只允许myid大的一方连接小的一方，如果小的连到了大的一方，会断开连接，转过身大的一方会主动与小的一方建立连接。这样做的目的是避免建立重复连接，解释不必要的网络IO开销。

3.各个服务器通过选票发送器会将自己的选票发送其他的节点上；

4.while循环进行获取，然后逐个跟自己的选票进行PK，此处有3处判断；

• 收到的选票的逻辑时钟大于当前节点，说明当前节点的选举已经落后，那么立即将当前节点的逻辑时钟更新为最新，清空自己的投票箱（收到的选票），然后再跟当前选票进行PK，选出最优者，更新自己的选票；
• 收到的选票的逻辑时钟小于当前节点，说明收到的投票不是最新，则直接忽略，不做任何操作；
• 两者的选票是同一届选举，此时进行PK，PK的优选条件如下：

1. 当前peerEpoch>currEpoch,那么收到的选票中的节点更优；
2. 如果选举的epoch一致，则比较zxid，zxid越大，则更优秀；
3. 如果zxid相等，则比较myid，id越大则表示更优秀；

• PK完后，把自己的选票更新成最新，然后通过选票发送器发送给其他的节点；

5.统计投票箱，判断当前被推选为leader的节点，是否已经有超过半数的节点投给了它，这就是zk中的过半机制；

6.当选举出leader后，每台机器会更改自己的节点状态，成为leader的节点更新为leading，其余为following。

4.leader选举示例分析

Server3,Server4,Server5的myid分别为3,4,5

Server3,Server4,Server5的zxid分别为9,8,8

1.首先Server3,Server4,Server5各自投自己一票，推选自己为leader，然后将选票发送给其他节点；

Server3收到的选票：（4,8）（5,8）--->自己的选票（3,9）

Server4收到的选票：（3,9）（5,8）--->自己的选票（4,8）

Server5收到的选票：（3,9）（4,8）--->自己的选票（5,8）

2.选票PK

Server3：3与4比较，3zxid大，获胜，3与5比较，3zxid大，获胜，还是最初的选票（3,9）；

Server4：4与3比较，3zxid大，获胜，3与5比较，3zxid大，获胜，变更选票为（3,9）；

Server5：5与3比较，3zxid大，获胜，3与4比较，3zxid大，获胜，变更选票为（3,9）；

3.将新的投票发送给其他的服务器节点；

Server3收到的选票：（3,9）（3,9）--->自己的选票（3,9）

Server4收到的选票：（3,9）（3,9）--->自己的选票（3,9）

Server5收到的选票：（3,9）（3,9）--->自己的选票（3,9）

4.统计投票箱，很明显此时选中Server3的投票已过半数，那么leader已选出；

5.更新状态，Server3更新为leading状态，Server4和Server5更新为following状态，该集群可以正常对外提供服务。

leader选举的大致流程就介绍到这了，这里着重介绍了在集群启动时的leader选举，运行期间leader挂掉后的leader选举跟这个流程大同小异，下一篇文章我将着重从源码介绍leader选举的实现原理，敬请期待！