大厂技术大佬:用大白话给你解释Zookeeper的选举机制

bigdata 2021-01-22 10:48:29 ⋅ 205 阅读

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

我们可以简单把 Zookeeper 理解为分布式家庭的大管家,那么管家团队是如何选出Leader的呢?好奇吗,接下来带领大家一探究竟。

人类选举的基本原理

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

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

情况1:自己与几个候选人都比较熟,你会将票投给你认为能力比较强的人;

熟人选举

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

自己参与选举

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

思维导图

在整个投票过程中我们可以提炼出四个最核心的概念:

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

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

Zookeeper选举的基本原理

注意如果 Zookeeper 是单机部署是不需要选举的,集群模式下才需要选举。

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

  • 个人能力

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

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

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

  • 遇强改投

在集群选举开始时,节点首先认为自己是最强的(即数据是最新的),然后在选票上写上自己的名字(包括zxid和sid),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

集群 Leader 节点故障

运行期选举与初始状态投票过程基本类似,大致可以分为以下几个步骤:

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

(2)每个Server会发出投票。

(3)接收来自各个服务器的投票,如果其他服务器的数据比自己的新会改投票。

(4)处理和统计投票,每一轮投票结束后都会统计投票,超过半数即可当选。

(5)改变服务器的状态,宣布当选。

话不多说先来一张图:

运行器 Leader 故障后选举流程

(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 代表数据越新,权值也就越大。

(4)在运行期选举还可能会遇到脑裂的情况,大家可以自行学习。

 


全部评论: 0

    我有话说:

    为什么很多公司选择使用 Node.js 做 Web 后端?

      们问一下,为什么公司要Node.js 做web后端?并且Node 还要调用Java做数据落地?在网上看了一些帖子,发现很多厂都是这样做,我们公司项目也是这样,但是在开发

    【实战解析】基于HBase数据存储在京东应用场景

    作者就职于京东商城京麦平台组,从事京东商家开放平台相关开发工作。热爱技术,熟悉各种常开源框架,有丰富大型分布式系统、高并发系统开发经验。热衷于对数据研究,对Hadoop、HBase以及

    「轻阅读」阿里云-开放平台高级技术家教搭建微服务架构金刚利器

    孔凡勇,花名云狄,阿里云-开放平台高级技术家,对高并发、高性能、高可、可伸缩分布式系统架构设计有丰富经验,Cloud Native坚定拥护者,坚守开发一线打磨匠艺架构师。

    决战上海滩!美团or滴滴,谁是打车界""?/滴滴共享单车道路艰难:青桔单车投放当天再次被“ 收缴”/支付宝惨遭沃尔玛封杀..

    决战上海滩!美团or滴滴,谁是打车界""?;滴滴共享单车道路艰难:青桔单车投放当天再次被“ 收缴”;支付宝惨遭沃尔玛封杀!马爸爸,怎么看?

    京东技术:Sieve—Android 内存分析系统 | 解决内存溢出问题

    内存问题是个老大难,对用户来说,泄漏或者不合理内存使用最终会反映到性能和体验上,并且极易造成 OOM( Out Of Memories ) 而闪退, 而对开发者来说更为头疼......

    京东技术最小图片格式,打造最优用户体验

    DPG图片压缩技术能够有效减少图片大小50%,并且减少50%CDN带宽流量!

    京东到家订单中心系统mysql到es转化之路

    ,造成了订单数据读多写少情况。 我们把订单数...

    大家分享一款开源高性能api网关

    https://www.toutiao.com/i6890014207987679755 在当前互联网环境下,尤其是移动互联网时代,用户通过手机APP可访问很多应用,作为应用服务部分面对日益

    「轻阅读」最近程序员圈刷屏支付宝架构,分享大家

    支付宝架构到底有多牛逼!还没看完我就跪了

    微信小程序营销之转盘(二)

    第一个版本转盘都是图片做,奖品等信息都是不无法修改,说白了就是没啥实际用途,作者我就直接canvas撸了一个全手工绘制转盘分享大家

    「转载」蘑菇街消息系统上云实践

    小编又来啦~本周要推荐大家是一篇跟中间件上云相关技术文章,这里面详细记录了,蘑菇街自研消息系统上云全过程,也是市面上开放出来为数不多企业自研组件上云实践。有相关需求同学可以好好学习下

    生产技巧:如何不停机修改Zookeeper日志路径?

    咪咕Kafka及Zookeeper是分离部署(即:未使用Kafka本身自带Zkper),故而要想修改Zookeeper日志,需如下操作...

    转载:Kafka高可用,高吞吐量低延迟高并发特性背后实现机制

    1 概述 Kafka是最初由Linkedin公司开发,是一个分布式、分区、多副本、多订阅者,基于zookeeper协调分布式消息系统,Linkedin于2010年贡献了Apache基金会并

    Martian-cloud 4.0,跟注册中心拜拜了,基于传染机制分布式组件诞生

    这次真要跟注册中心讲拜拜了,微服务不再需要占用一套注册中心集群了,大大节约了运维成本 更新点如下 丢弃了一开始【生产者->注册中心->消费者】模型 采用传染机制,实现服务发现与

    蚂蚁宣布开源 KubeTEE:云原生集群化机密计算框架

    蚂蚁在上海外滩大会可信原生技术论坛上宣布开源 KubeTEE。 KubeTEE 是一个云原生大规模集群化机密计算框架,旨在解决在云原生环境中 TEE 可信执行环境技术特有从开发、部署到运维整体流程

    京东技术:如何实现靠谱分布式锁?(附SharkLock设计选择

    分布式锁,是来控制分布式系统中互斥访问共享资源一种手段,从而避免并行导致结果不可控。

    「轻阅读」移动端事件穿透原理与解决方案

    本文将带了解事件穿透及如何在实际项目中选择合适方案解决事件穿透问题。

    Apache ZooKeeper 3.7.0 发布,分布式服务框架

    Apache ZooKeeper 是 Apache 软件基金会一个软件项目,它为大型分布式计算提供开源分布式配置服务、同步服务和命名注册。ZooKeeper 曾经是 Hadoop 一个子项目

    8 种最坑 SQL 错误法,有没有踩过坑?

    编写复杂SQL语句要养成使用 WITH 语句习惯。简洁且思路清晰SQL语句也能减小数据库负担 。