分布式组件之zookeeper选举机制

试剑江湖
399 阅读7分钟

1. zookeeper集群

配置多个实例共同构成一个集群对外提供服务以达到水平扩展的目的，每个服务器上的数据是相同的，每一个服务器均可以对外提供读和写的服务，这点和redis是相同的，即对客户端来讲每个服务器都是平等的。

image.png

这篇主要分析leader的选择机制，zookeeper提供了三种方式：

  • LeaderElection  
  • AuthFastLeaderElection
  • FastLeaderElection （最新默认）

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

2. 选举流程简述

每个服务器启动后进入LOOKING状态，开始选举一个新的群首或查找已经存在的群首，如果群首已经存在，其他服务器就会通知这个新启动的服务器，告知哪个服务器是群首，与此同时，新的服务器会与群首建立连接，以确保自己的状态与群首一致。

如果集群中所有的服务器均处于LOOKING状态，这些服务器之间就会进行通信来选举一个群首，通过信息交换对群首选举达成共识的选择。在本次选举过程中胜出的服务器将进入LEADING状态，而集群中其他服务器将会进入FOLLOWING状态。

对于群首选举的消息，我们称之为群首选举通知消息（leader electionnotifications），或简单地称为通知（notifications）。该协议非常简单，当一个服务器进入LOOKING状态，就会发送向集群中每个服务器发送一个通知消息，该消息中包括该服务器的投票（vote）信息，投票中包含服务器标识符（sid）和最近执行的事务的zxid信息，比如，一个服务器所发送的投票信息为（1，5），表示该服务器的sid为1，最近执行的事务的zxid为5（出于群首选举的目的，zxid只有一个数字，而在其他协议中，zxid则有时间戳epoch和计数器组成）。

当一个服务器收到一个投票信息（sid,zxid），该服务器将会根据以下规则修改自己的投票信息：

  • 如果 zxid-1 > zxid-2,则以zxid-1的投票信息为主
  • 如果 zxid-1 = zxid-2 且 sid-1>sid-2,则以sid-1的投票信息为主

2.1 选举基本规则

  • Serverid：服务器ID：比如有三台服务器，编号分别是1,2,3。编号越大在选择算法中的权重越大。
  • Zxid：数据ID：服务器中存放的最大数据ID.值越大说明数据越新，在选举算法中数据越新权重越大。
  • Epoch：逻辑时钟：或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。
  • Server状态：选举状态
    • LOOKING，竞选状态。
    • FOLLOWING，随从状态，同步leader状态，参与投票。
    • OBSERVING，观察状态,同步leader状态，不参与投票。
    • LEADING，领导者状态。

选举分为两种

  • 服务启动时触发Leader选举
  • 某个节点宕机触发Leader选举

2.2 投票过程分析

image.png

服务启动选举流程

目前有3台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,按编号依次启动，它们的选择举过程如下：

  • 服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。
  • 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
  • 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。

由于ZK的过半原则，当达到（集群个数/2+1）台机器选择同一个机器作为Leader时，改机器会从Looking状态切换到Leader状态，而其他的机器则会切换到Follower的状态。

2.3 接收投票信息分析

（1）如果服务器B接收到服务器A的数据（服务器A处于选举状态(LOOKING 状态)

首先，判断逻辑时钟值：

  • 如果发送过来的逻辑时钟Epoch大于目前的逻辑时钟。首先，更新本逻辑时钟Epoch，同时清空本轮逻辑时钟收集到的来自其他server的选举数据。然后，判断是否需要更新当前自己的选举leader Serverid。判断规则rules judging：保存的zxid最大值和leader Serverid来进行判断的。先看数据zxid,数据zxid大者胜出;其次再判断leader Serverid,leader Serverid大者胜出；然后再将自身最新的选举结果(也就是上面提到的三种数据（leader Serverid，Zxid，Epoch）广播给其他server)
  • 如果发送过来的逻辑时钟Epoch小于目前的逻辑时钟。说明对方server在一个相对较早的Epoch中，这里只需要将本机的三种数据（leader Serverid，Zxid，Epoch）发送过去就行。
  • 如果发送过来的逻辑时钟Epoch等于目前的逻辑时钟。再根据上述判断规则rules judging来选举leader ，然后再将自身最新的选举结果(也就是上面提到的三种数据（leader  Serverid，Zxid，Epoch）广播给其他server)。

其次，判断服务器是不是已经收集到了所有服务器的选举状态：若是，根据选举结果设置自己的角色(FOLLOWING还是LEADER)，退出选举过程就是了。

最后，若没有收到没有收集到所有服务器的选举状态：也可以判断一下根据以上过程之后最新的选举leader是不是得到了超过半数以上服务器的支持,如果是,那么尝试在200ms内接收一下数据,如果没有新的数据到来,说明大家都已经默认了这个结果,同样也设置角色退出选举过程。

（2）如果所接收服务器A处在其它状态（FOLLOWING或者LEADING）。

  • 逻辑时钟Epoch等于目前的逻辑时钟，将该数据保存到recvset。此时Server已经处于LEADING状态，说明此时这个server已经投票选出结果。若此时这个接收服务器宣称自己是leader, 那么将判断是不是有半数以上的服务器选举它，如果是则设置选举状态退出选举过程。
  • 否则这是一条与当前逻辑时钟不符合的消息，那么说明在另一个选举过程中已经有了选举结果，于是将该选举结果加入到outofelection集合中，再根据outofelection来判断是否可以结束选举,如果可以也是保存逻辑时钟，设置选举状态，退出选举过程。

(3) 为什么推荐ZK集群个数为奇数个？

  1. 假设集群数量为4个，有一台Leader挂了，还剩3台Follower, 由于Leader选举的过半原则，需要(3/2+1)=2台Follower投票同一台机器才能成为Leader。
  2. 假设集群数量为3个，有一台Leader挂了，还剩2台Follower, 由于Leader选举的过半原则，需要(2/2+1)=2台Follower投票同一台机器才能成为Leader。
  3. 既然3台机器和4台机器的集群在Leader挂掉之后，都需要2台Follower投票同一台机器才能成为Leader，那为什么不节省一台机器的成本呢？

所以，总得来说，就是为了节省成本。

avatar
文章
阅读
粉丝