前言

本文隶属于专栏《1000个问题搞定大数据技术体系》,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢!

本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系

正文

在这里插入图片描述

选举机制的简介

ZooKeeper 为了保证各节点的协同工作,在工作时需要一个 Leader 角色,而 ZooKeeper 默认采用 FastLeaderElection 算法,且投票数大于半数则胜出的机制。

在介绍选举机制前,首先了解选举涉及的相关概念。

服务器 ID

这是在配置集群时设置的 myid 参数文件,且参数分别表示为服务器 1 、服务器 2 和服务器 3 ,编号越大在 FastLeaderElection 算法中的权重越大。

选举状态

在选举过程中, ZooKeeper 服务器有 4 种状态,它们分别为

  1. 竞选状态( LOOKING )
  2. 随从状态( FOLLOWING ,同步 leader 状态,参与投票 )
  3. 观察状态( OBSERVING ,同步 leader 状态,不参与投票 )
  4. 领导者状态( LEADING )。

数据 ID

这是服务器中存放的最新数据版本号,该值越大说明数据越新,在选举过程中数据越新权重越大。

逻辑时钟

通俗地讲,逻辑时钟被称为投票次数,同一轮投票过程中的逻辑时钟值是相同的,逻辑时钟起始值为 0 ,每投完一次票,这个数据就会增加。

然后,与接收到其他服务器返回的投票信息中的数值相比较,根据不同的值做出不同的判断。

如果某台机器宕机,那么这台机器不会参与投票,因此逻辑时钟也会比其他的低。

选举机制的类型

ZooKeeper 选举机制有两种类型,分别为全新集群选举和非全新集群选举,下面分别对两种类型进行详细讲解。

全新集群选举

全新集群选举是新搭建起来的,没有数据 1D 和逻辑时钟来影响集群的选举。
假设,目前有 5 台服务器,它们的编号分别是 1 ~ 5 ,按编号依次启动 ZooKeeper 服务。

全新集群选举的过程

  1. 服务器 1 启动,首先,会给自己投票;其次,发投票信息,由于其他机器还没有启动所以它无法接收到投票的反馈信息,因此服务器 1 的状态一直属于 LOOKING 状态。
  2. 服务器 2 启动,首先,会给自己投票;其次,在集群中启动 ZooKeeper 服务的机器发起投票对比,这时它会与服务器 1 交换结果,由于服务器 2 的编号大,所以服务器 2 胜出,此时服务器 1 会将票投给服务器 2 ,但此时服务器 2 的投票数并没有大于集群半数( 25 / 2 ),所以两个服务器的状态依然是 LOOKING 状态。
  3. 服务器 3 启动,首先,会给自己投票;其次,与之前启动的服务器 1 和服务器 2 交换信息,由于服务器 3 的编号最大所以服务器 3 胜出,那么服务器 1 和 2 会将票投给服务器 3 ,此时投票数正好大于半数( 3 > 5 / 2 ),所以服务器 3 成为领导者状态,服务器 1 和 2 成为追随者状态。
  4. 服务器 4 启动,首先,给自己投票;其次,与之前启动的服务器 1 、 2 和 3 交换信息,尽管服务器 4 的编号大,但是服务器 3 已经胜出。 所以服务器 4 只能成为追随者状态。
  5. 服务器 5 启动,同服务器 4 一样,均成为追随者状态。

非全新集群选举

对于正常运行的 ZooKeeper 集群,一且中途有服务器宕机,则需要重新选举时,选举的过程中就需要引入服务器 ID 、数据 ID 和逻辑时钟。

这是由于 ZooKeeper 集群已经运行过段时间,那么服务器中就会存在运行的数据。

非全新集群选举的过程

  1. 首先,统计逻辑时钟是否相同,逻辑时钟小,则说明途中可能存在宕机问题,因此数据不完整,那么该选举结果被忽略,重新投票选举;
  2. 其次,统一逻辑时钟后,对比数据ID值,数据ID反应数据的新旧程度,因此数据ID大的胜出;
  3. 如果逻辑时钟和数据ID都相同的情况下,那么比较服务器ID(编号),值大则胜出;
    简单地讲,非全新集群选举时是优中选优,保证 Leader 是 ZooKeeper 集群中数据最完整、最可靠的一台服务器。
上一篇 下一篇