ZooKeeper 选举机制FasterLeaderElection详解

2024-04-01 14:38

本文主要是介绍ZooKeeper 选举机制FasterLeaderElection详解,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

    • 选举方式
    • 选举内容
    • 选举机制

ZooKeeper的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是选举模式同步模式。当服务启动或者在领导者崩溃后,Zab就进入了选举模式,当领导者被选举出来,且大多数Server完成了和leader的状态同步以后,选举模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

1. 选举方式

ZooKeeper提供三种选举方式,分别是

  • FasterLeaderElection
  • AuthFastLeaderElection
  • LeaderElection.

默认采用的是类似Fast Paxos算法的FasterLeaderElection

至于Fast Paxos算法见 分布式 了解Paxos和Fast Paxos算法

为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch,标识当前属于那个leader的统治时期。低32位用于递增计数。

2. 选举内容

  1. ServerId (zoo.cfg文件中server.x中的x和myid文件中的数字) Server编号,越大权重越大
  2. Zxid(运行时产生的数据id)存储最大的数据id,数值越大权重越大
  3. Epoch(数字时钟) 投票次数,用来标记当前选举
  4. 选举状态 有四种:

    • LOOKING:启动时状态 竞选状态
    • OBSERVING:观察状态 同步Leader状态 不参与投票
    • FOLLOWING:随从状态 同步Leader状态 参与投票
    • LEADING:领导状态

3. 选举机制

在了解选举机制之前我们先要知道几个概念

1.一个Server是如何知道其它的Server的?

在ZooKeeper集群中,Server的信息都在zoo.conf配置文件中,根据配置文件的信息就可以知道其它Server的信息。

2.成为Leader的必要条件?

Leader要具有最高的zxid,并且集群中的大多数机器(至少n/2+1)得到相应并且选举该Leader

3.如果所有zxid都相同(刚初始化时所有的Server的epoch和zxid都是相同的),此时有可能不能形成n/2+1个Server,怎么办?

ZooKeeper中每一个Server都有一个ID,这个ID是不重复的,如果遇到这样的情况时,ZooKeeper就推荐ID最大的哪个Server作为Leader。

4.ZooKeeper中Leader怎么知道Follwer还存活,Follwer怎么知道Leader还存活?

Leader定时向Follwer发ping消息,Follwer定时向Leader发ping消息,当发现Leader无法ping通时,就改变自己的状态(LOOKING),发起新的一轮选举。

接下来我们来看选举机制:

在FasterLeaderElection中一个内部类Messenger,其中有两个线程WorkerReceiver和WorkSender,功能就和名字一样,分别用来接收和发送选举信息。

synchronized(this){//逻辑时钟           logicalclock++;//getInitLastLoggedZxid(), getPeerEpoch()这里先不关心是什么,后面会讨论updateProposal(getInitId(), getInitLastLoggedZxid(), getPeerEpoch());
}//getInitId() 即是获取选谁,id就是myid里指定的那个数字,所以说一定要唯一
private long getInitId(){if(self.getQuorumVerifier().getVotingMembers().containsKey(self.getId()))       return self.getId();else return Long.MIN_VALUE;
}//发送选举信息,异步发送
sendNotifications();

当集群初始化时或者是Leader无法连通时,就需要进行新一轮的选举。首先集群中的每个节点,默认都是把票投给自己的,于是把选举信息(serverid,zxid和epoch)向其他节点广播,选举信息首先被放入WorkerSender内的一个队列中,之后从队列中取出选票交付给QuorumCnxManager发送

public void toSend(Long sid, ByteBuffer b) {if (self.getId() == sid) {b.position(0);addToRecvQueue(new Message(b.duplicate(), sid));} else {//发送给别的节点,判断之前是不是发送过if (!queueSendMap.containsKey(sid)) {//这个SEND_CAPACITY的大小是1,所以如果之前已经有一个还在等待发送,则会把之前的一个删除掉,发送新的ArrayBlockingQueue<ByteBuffer> bq = new ArrayBlockingQueue<ByteBuffer>(SEND_CAPACITY);queueSendMap.put(sid, bq);addToSendQueue(bq, b);} else {ArrayBlockingQueue<ByteBuffer> bq = queueSendMap.get(sid);if(bq != null){addToSendQueue(bq, b);} else {LOG.error("No queue for server " + sid);}}//这里是真正的发送逻辑了connectOne(sid);}}

connectOne就是真正发送了。在发送之前会先把自己的id和选举地址发送过去。然后判断要发送节点的id是不是比自己的id大,如果大则不发送了。如果要发送又是启动两个线程:SendWorker,RecvWorker(这种一个进程内许多不同种类的线程,各自干活的状态真的很难理解)。发送逻辑还算简单,就是从刚才放到那个queueSendMap里取出,然后发送。并且发送的时候将发送出去的东西放到一个lastMessageSent的map里,如果queueSendMap里是空的,就发送lastMessageSent里的东西,确保对方一定收到了。

接下来来看数据接收的逻辑,根据当前Server的状态分为LOOKING状态和其他状态两种情况

1.LOOKING状态

  • 首先判断接收到的选举信息的逻辑时钟epoch
    • 如果该epoch大于当前Server的epoch –> 当前数据过期 –> 更新当前epoch,同时清空选举数据,再判断是否需要更新选举情况
    • 如果该epoch小于当前Server的epoch –> 对方数据过期 –> 把本机数据(Leader.ServerId,Zxid,Epoch)发送给该Server
    • 如果该epoch等于当前Server的epoch –> 直接进入判断逻辑
  • epoch相等的情况下先判断zxid –> 大者获胜
  • zxid也相等的就判断ServerId –> 大者获胜

结果:
1. 接收到了所有Server的选举信息,根据选举信息决定当前Server的状态(Leading/Following),结束Looking状态,退出选举
2. 没有接收到所有的选举信息,判断投票数是否超过半数,设置当前Server状态

2.其他状态(FOLLOWING/LEADING)

  1. 如果逻辑时钟Epoch相同,将该数据保存到recvset,如果所接收服务器宣称自己是leader,那么将判断是不是有半数以上的服务器选举它,如果是则设置选举状态退出选举过程
  2. 否则这是一条与当前逻辑时钟不符合的消息,那么说明在另一个选举过程中已经有了选举结果,于是将该选举结果加入到outofelection集合中,再根据outofelection来判断是否可以结束选举,如果可以也是保存逻辑时钟,设置选举状态,退出选举过程。
protected boolean totalOrderPredicate(long newId, long newZxid, long newEpoch, long curId, long curZxid, long curEpoch) {return ((newEpoch > curEpoch) || ((newEpoch == curEpoch) &&((newZxid > curZxid) || ((newZxid == curZxid) && (newId > curId)))));}
private boolean termPredicate(HashMap<Long, Vote> votes,Vote vote) {HashSet<Long> set = new HashSet<Long>();//遍历已经收到的投票集合,将等于当前投票的集合取出放到set中for (Map.Entry<Long,Vote> entry : votes.entrySet()) {if (self.getQuorumVerifier().getVotingMembers().containsKey(entry.getKey())&& vote.equals(entry.getValue())){set.add(entry.getKey());}}//统计set,也就是投某个id的票数是否超过一半return self.getQuorumVerifier().containsQuorum(set);}public boolean containsQuorum(Set<Long> ackSet) {return (ackSet.size() > half);}

一个小问题 一个集群有3台机器,挂了一台后的影响是什么?挂了两台呢?

挂了一台:挂了一台后就是收不到其中一台的投票,但是有两台可以参与投票,按照上面的逻辑,它们开始都投给自己,后来按照选举的原则,两个人都投票给其中一个,那么就有一个节点获得的票等于2,2 > (3/2)=1 的,超过了半数,这个时候是能选出leader的。

挂了两台: 挂了两台后,怎么弄也只能获得一张票, 1 不大于 (3/2)=1的,这样就无法选出一个leader了

再看一个选举流程的实例:

目前有5台Server,每台Server均没有数据,它们的编号分别是1,2,3,4,5,按编号依次启动,它们的选择举过程如下:

  1. Server1启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反馈信息,Server1的状态一直属于Looking。
  2. Server2启动,给自己投票,同时与之前启动的Server1交换结果,由于Server2的编号大所以Server2胜出,但此时投票数没有大于半数,所以两个Server的状态依然是LOOKING。
  3. Server3启动,给自己投票,同时与之前启动的Server1,2交换信息,由于Server3的编号最大所以Server3胜出,此时投票数正好大于半数,所以Server3成为领导者,Server1,2成为小弟。
  4. Server4启动,给自己投票,同时与之前启动的Server1,2,3交换信息,尽管Server4的编号大,但之前Server3已经胜出,所以Server4只能成为小弟。
  5. Server5启动,后面的逻辑同Server4成为小弟。

这篇关于ZooKeeper 选举机制FasterLeaderElection详解的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/867416

相关文章

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

Zookeeper安装和配置说明

一、Zookeeper的搭建方式 Zookeeper安装方式有三种,单机模式和集群模式以及伪集群模式。 ■ 单机模式:Zookeeper只运行在一台服务器上,适合测试环境; ■ 伪集群模式:就是在一台物理机上运行多个Zookeeper 实例; ■ 集群模式:Zookeeper运行于一个集群上,适合生产环境,这个计算机集群被称为一个“集合体”(ensemble) Zookeeper通过复制来实现

OpenHarmony鸿蒙开发( Beta5.0)无感配网详解

1、简介 无感配网是指在设备联网过程中无需输入热点相关账号信息,即可快速实现设备配网,是一种兼顾高效性、可靠性和安全性的配网方式。 2、配网原理 2.1 通信原理 手机和智能设备之间的信息传递,利用特有的NAN协议实现。利用手机和智能设备之间的WiFi 感知订阅、发布能力,实现了数字管家应用和设备之间的发现。在完成设备间的认证和响应后,即可发送相关配网数据。同时还支持与常规Sof

搭建Kafka+zookeeper集群调度

前言 硬件环境 172.18.0.5        kafkazk1        Kafka+zookeeper                Kafka Broker集群 172.18.0.6        kafkazk2        Kafka+zookeeper                Kafka Broker集群 172.18.0.7        kafkazk3

6.1.数据结构-c/c++堆详解下篇(堆排序,TopK问题)

上篇:6.1.数据结构-c/c++模拟实现堆上篇(向下,上调整算法,建堆,增删数据)-CSDN博客 本章重点 1.使用堆来完成堆排序 2.使用堆解决TopK问题 目录 一.堆排序 1.1 思路 1.2 代码 1.3 简单测试 二.TopK问题 2.1 思路(求最小): 2.2 C语言代码(手写堆) 2.3 C++代码(使用优先级队列 priority_queue)

Java ArrayList扩容机制 (源码解读)

结论:初始长度为10,若所需长度小于1.5倍原长度,则按照1.5倍扩容。若不够用则按照所需长度扩容。 一. 明确类内部重要变量含义         1:数组默认长度         2:这是一个共享的空数组实例,用于明确创建长度为0时的ArrayList ,比如通过 new ArrayList<>(0),ArrayList 内部的数组 elementData 会指向这个 EMPTY_EL

K8S(Kubernetes)开源的容器编排平台安装步骤详解

K8S(Kubernetes)是一个开源的容器编排平台,用于自动化部署、扩展和管理容器化应用程序。以下是K8S容器编排平台的安装步骤、使用方式及特点的概述: 安装步骤: 安装Docker:K8S需要基于Docker来运行容器化应用程序。首先要在所有节点上安装Docker引擎。 安装Kubernetes Master:在集群中选择一台主机作为Master节点,安装K8S的控制平面组件,如AP

【编程底层思考】垃圾收集机制,GC算法,垃圾收集器类型概述

Java的垃圾收集(Garbage Collection,GC)机制是Java语言的一大特色,它负责自动管理内存的回收,释放不再使用的对象所占用的内存。以下是对Java垃圾收集机制的详细介绍: 一、垃圾收集机制概述: 对象存活判断:垃圾收集器定期检查堆内存中的对象,判断哪些对象是“垃圾”,即不再被任何引用链直接或间接引用的对象。内存回收:将判断为垃圾的对象占用的内存进行回收,以便重新使用。

【Tools】大模型中的自注意力机制

摇来摇去摇碎点点的金黄 伸手牵来一片梦的霞光 南方的小巷推开多情的门窗 年轻和我们歌唱 摇来摇去摇着温柔的阳光 轻轻托起一件梦的衣裳 古老的都市每天都改变模样                      🎵 方芳《摇太阳》 自注意力机制(Self-Attention)是一种在Transformer等大模型中经常使用的注意力机制。该机制通过对输入序列中的每个元素计算与其他元素之间的相似性,