关于zookeeper:用大白话给你解释Zookeeper的选举机制

36次阅读

共计 3243 个字符,预计需要花费 9 分钟才能阅读完成。

Zookeeper 是一个分布式服务框架,次要是用来解决分布式应用中遇到的一些数据管理问题如:对立命名服务 状态同步服务 集群治理 分布式应用配置项的治理 等。

咱们能够简略把 Zookeeper 了解为分布式家庭的大管家,那么管家团队是如何选出 Leader 的呢?好奇吗,接下来率领大家一探到底。

人类选举的基本原理

解说 Zookeeper 选举过程前先来介绍一下人类的选举。

咱们每个人或多或少都经验过几次选举,在投票的过程中可能会遇到这样几种状况:

状况 1 :本人与几个候选人都比拟熟,你会将票投给你认为 能力比拟强的人

图片

状况 2 :本人也是候选人,并且与其余几个候选人都不熟,这个时候你必定想着要去拉票,因为感觉本人才是最厉害的人呀,所有人都应该把票投给我。然而遗憾的是在拉票的过程中,你 发现他人比你强,你开始自大了,最终还是把票投给了本人认为最强的人。

图片

所有人都投完票之后,最初从投票箱中进行统计,取得票数最多的人入选。

图片

在整个投票过程中咱们能够提炼出四个最外围的概念:

  • 候选人能力:投票的根本准则是选最强的人。
  • 遇强改投:如果前面发现更强的人能够改投票。
  • 投票箱:所有人的票都会放在投票箱。
  • 领导者:得票最多的人即为领导者。

从人类选举的原理咱们来简略推导一下 Zookeeper 的选举原理。

Zookeeper 选举的基本原理

留神如果 Zookeeper 是单机部署是不须要选举的,集群模式下才须要选举。

Zookeeper 的选举原理和人类选举的逻辑相似,套用一下人类选举的四个基本概念具体解释一下 Zookeeper。

  • 集体能力

如何掂量 Zookeeper 节点集体能力?答案是靠 数据是否够新,如果节点的数据越新就代表这个节点的集体能力越强,是不是感觉很奇怪,就是这么定的!

在 Zookeeper 中通常是以事务 id(前面简称zxid)来标识数据的新旧水平(版本),节点最新的 zxid 越大代表这个节点的数据越新,也就代表这个节点能力越强。

zxid 的全称是 ZooKeeper Transaction Id,即 Zookeeper 事务 id。

  • 遇强改投

在集群选举开始时,节点首先认为本人时最强的(即数据是最新的),而后在选票上写上本人的名字(包含 zxidsid),zxid 是事务 id,sid 惟一标识本人。

紧接着会将选票传递给其余节点,同时本人也会接管其余节点传过来的选票。每个节点接管到选票后会做比拟,这个人是不是比我强(zxid 比我大),如果比拟强,那我就须要 改票,明明他人比我强,我也不能厚着脸皮对吧。

  • 投票箱

与人类选举投票箱略微有点不一样,Zookeeper 集群会在每个节点的内存中保护一个投票箱。节点会将本人的选票以及其余节点的选票都放在这个投票箱中。因为选票时相互传阅的,所以最终每个节点投票箱中的选票会是一样的。

  • 领导者

在投票的过程中会去统计是否有超过一半的选票和本人抉择的是同一个节点,即都认为某个节点是最强的。一旦集群中有 超过半数 的节点都认为某个节点最强,那该节点就是领导者了,投票也宣告完结。

什么场景下 Zookeeper 须要选举?

当 Zookeeper 集群中的一台服务器呈现以下两种状况之一时,须要进入 Leader 选举

(1)服务器初始化启动。

(2)服务器运行期间 Leader 故障。

启动期间的 Leader 选举

假如一个 Zookeeper 集群中有 5 台服务器,id 从 1 到 5 编号,并且它们都是最新启动的,没有历史数据。

图片

假如服务器顺次启动,咱们来剖析一下选举过程:

(1)服务器 1 启动

发动一次选举,服务器 1 投本人一票,此时服务器 1 票数一票,不够半数以上(3 票),选举无奈实现。

投票后果:服务器 1 为 1 票。

服务器 1 状态放弃为LOOKING

(2)服务器 2 启动

发动一次选举,服务器 1 和 2 别离投本人一票,此时服务器 1 发现服务器 2 的 id 比本人大,更改选票投给服务器 2。

投票后果:服务器 1 为 0 票,服务器 2 为 2 票。

服务器 1,2 状态放弃LOOKING

(3)服务器 3 启动

发动一次选举,服务器 1、2、3 先投本人一票,而后因为服务器 3 的 id 最大,两者更改选票投给为服务器 3;

投票后果:服务器 1 为 0 票,服务器 2 为 0 票,服务器 3 为 3 票。此时服务器 3 的票数曾经超过半数(3 票),服务器 3 入选Leader

服务器 1,2 更改状态为FOLLOWING,服务器 3 更改状态为LEADING

(4)服务器 4 启动

发动一次选举,此时服务器 1,2,3 曾经不是 LOOKING 状态,不会更改选票信息。替换选票信息后果:服务器 3 为 3 票,服务器 4 为 1 票。此时服务器 4 遵从少数,更改选票信息为服务器 3。

服务器 4 并更改状态为FOLLOWING

(5)服务器 5 启动

与服务器 4 一样投票给 3,此时服务器 3 一共 5 票,服务器 5 为 0 票。

服务器 5 并更改状态为FOLLOWING

最终的后果

服务器 3 是 Leader,状态为 LEADING;其余服务器是 Follower,状态为 FOLLOWING

运行期间的 Leader 选举

在 Zookeeper 运行期间 Leader非 Leader 各司其职,当有非 Leader 服务器宕机或退出不会影响 Leader,然而一旦 Leader 服务器挂了,那么整个 Zookeeper 集群将暂停对外服务,会触发新一轮的选举。

初始状态下服务器 3 入选为Leader,假如当初服务器 3 故障宕机了,此时每个服务器上 zxid 可能都不一样,server1 为 99,server2 为 102,server4 为 100,server5 为 101

图片

运行期选举与初始状态投票过程根本相似,大抵能够分为以下几个步骤:

(1)状态变更。Leader 故障后,余下的 非 Observer 服务器都会将本人的服务器状态变更为LOOKING,而后开始进入Leader 选举过程

(2)每个 Server 会收回投票。

(3)接管来自各个服务器的投票,如果其余服务器的数据比本人的新会改投票。

(4)解决和统计投票,没一轮投票完结后都会统计投票,超过半数即可入选。

(5)扭转服务器的状态,发表入选。

话不多说先来一张图:

图片

(1)第一次投票,每台机器都会将票投给本人。

(2)接着每台机器都会将本人的投票发给其余机器,如果发现其余机器的 zxid 比本人大,那么就须要改投票从新投一次。比方 server1 收到了三张票,发现 server2 的 xzid 为 102,pk 一下发现自己输了,前面果决改投票选 server2 为老大。

选举机制中波及到的外围概念

敲黑板了,这些概念是面试必考的。

(1)Server id(或 sid):服务器 ID

比方有三台服务器,编号别离是 1,2,3。编号越大在抉择算法中的权重越大,比方初始化启动时就是依据服务器 ID 进行比拟。

(2)Zxid:事务 ID

服务器中寄存的数据的事务 ID,值越大阐明数据越新,在选举算法中数据越新权重越大。

(3)Epoch:逻辑时钟

也叫投票的次数,同一轮投票过程中的逻辑时钟值是雷同的,每投完一次票这个数据就会减少。

(4)Server 状态:选举状态

LOOKING,竞选状态。

FOLLOWING,随从状态,同步 leader 状态,参加投票。

OBSERVING,察看状态, 同步 leader 状态,不参加投票。

LEADING,领导者状态。

总结

(1)Zookeeper 选举会产生在服务器初始状态和运行状态下。

(2)初始状态下会依据服务器 sid 的编号比照,编号越大权值越大,投票过半数即可选出 Leader。

(3)Leader 故障会触发新一轮选举,zxid 代表数据越新,权值也就越大。

— END —

日常厚脸皮求赞:你好技术人,先赞后看,养成习惯,不要白嫖哟。

作者简介:
☕读过几年书:华中科技大学硕士毕业;\
???? 浪过几个大厂:华为、网易、百度……\
???? 始终深信技术能扭转生存,愿放弃初心,加油技术人!

微信搜寻公众号【爱笑的架构师】,关注这个对技术和生存有谋求的技术人。

最初举荐一个宝藏开源我的项目,github/JavaMap \
这里有 Java 技术栈最全的常识地图,如果你学习迷茫了,无妨看一下下一步该怎么学。\
看过的人都举荐!!!

正文完
 0