Zookeeper：Zookeeper的主从选举机制

news2024/10/6 22:18:42

ZAB 协议，全称 Zookeeper Atomic Broadcast（Zookeeper 原子广播协议），是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的一致性协议。基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。当 Zookeeper 集群中的一台服务器出现以下两种情况之一时，需要进入 Leader 选举：（1）服务器初始化启动；（2）服务器运行期间 Leader 故障。

～

本篇内容包括：关于 ZAB 协议、Zookeeper 选主时机、Zookeeper 选主机制。

文章目录

    • 一、关于 ZAB 协议
        • 1、ZAB 协议简述
        • 2、ZooKeeper 集群中的三个服务器角色
    • 二、Zookeeper 选主时机
        • 1、ZooKeeper 服务器的工作状态
        • 2、Zookeeper 选主时机
        • 3、FOLLOWING 状态节点（Follower）的主流程
        • 4、LOOKING 状态节点的主流程
        • 5、LEADING 状态节点（Leader）的主流程
    • 三、Zookeeper 选主机制
        • 1、涉及到的相关概念
        • 2、Zookeeper 选举流程
        • 3、集团初始选举
        • 4、集群重新选举
        • 5、选举流程总结

一、关于 ZAB 协议

1、ZAB 协议简述

ZAB 协议，全称 Zookeeper Atomic Broadcast（Zookeeper 原子广播协议），是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的一致性协议。基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。

作为分布式共识算法的一员，Zab 算法构成了著名的 ZooKeeper 的基石。与赫赫有名的 Paxos、Raft 一样，Zab 算法也提供了强一致性的保证。

从设计上看，ZAB 协议和 Raft 很类似。ZooKeeper 集群中，只有一个 Leader 节点，其余均为 Follower 节点。

2、ZooKeeper 集群中的三个服务器角色

Zookeeper 集群中的机器分为以下三种角色：

  • Leader：①、整个 Zookeeper 集群工作机制中的核心，过选举产生的集群领导者，提供读写服务；②、一个 Zookeeper 集群中同一时间只能有一个实际工作的 Leader，它用来维护各个 Follow 与 Observer 之间的心跳；③、Leader 是事务请求的唯一调度和处理者，Follow 接收到事务请求会将请求转发给 Leader 处理。
  • Follow：①、Follow 只提供读服务，即只处理非事务请求，它接收到事务请求会转发给 Leader 服务器；②、它参与 Leader 的选举，参与事务请求 Proposal 的投票；③、一个 Zookeeper 集群同时可以有多个 Follow。
  • Observer：①、功能和 Follow 基本一致，提供读服务，即只处理非事务请求，唯一的差别是不参与任何投票（包括事务请求 Proposal 和 Leader 的选举）；②、Observer 的作用主要就是在不影响集群事务处理前提下提升集群的非事务处理。

二、Zookeeper 选主时机

1、ZooKeeper 服务器的工作状态

ZooKeeper 服务器有四种工作状态：

  1. LOOKING：竞选状态，寻找 Leader。当服务器处于该状态时，它会认为当前服务器没有 Leader，因此需要进入 Leader 选举状态。

  2. FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。

  3. LEADING：领导者状态。表明当前服务器角色是 Leader。

  4. OBSERVING：观察者状态。表明当前服务器角色是 Observer。

2、Zookeeper 选主时机

当 Zookeeper 集群中的一台服务器出现以下两种情况之一时，需要进入 Leader 选举：（1）服务器初始化启动；（2）服务器运行期间 Leader 故障。

  1. 服务器初始化启动：每个节点启动的时候状态都是 LOOKING，处于观望状态，接下来就是要进行选主了。
  2. 服务器运行期间 Leader 故障：Leader 节点运行后会周期性地向 Follower 发送心跳信息（称之为 ping）
    1. 如果一个 Follower 未收到 Leader 节点的心跳信息，Follower 节点的状态会从 FOLLOWING 转变为 LOOKING；
    2. Leader 节点也会检测 Follower 节点的状态，如果多数 Follower 节点不再响应 Leader 节点（可能是 Leader 节点与 Follower 节点之间产生了网络分区），那么 Leader 节点可能此时也不再是合法的 Leader 了，也必须要进行一次新的选主。

3、FOLLOWING 状态节点（Follower）的主流程

FOLLOWING 状态节点（Follower）的主流程：

void followLeader() throws InterruptedException {
try {
    ......
    while (this.isRunning()) {
        readPacket(qp);
        processPacket(qp);
    }
    // 如果上面的 while 循环内出现异常
    // Ps：长时间没有收到 Leader 的消息也是异常
} catch (Exception e) {
    // 出现异常就退出了 while 循环
    // 也就结束了 Follower 的处理流程
}

4、LOOKING 状态节点的主流程

LOOKING 状态节点的主流程：

public void run() {
    while (running) {
        switch (getPeerState()) {
        case FOLLOWING:
            try {
                setFollower(makeFollower(logFactory));
                follower.followLeader();
            } catch (Exception e) {
                ......
            } finally {
                follower.shutdown();
                setFollower(null);
                // 状态更新为 LOOKING
                updateServerState();
            }
            break;
            ......
    }
}

5、LEADING 状态节点（Leader）的主流程

在 Leader 节点的主循环流程中，会判断多数派节点的消息状态，如下：

void lead() throws IOException, InterruptedException {
    ......
    while (true) {
        ......
        // 判断每个每个 Follower 节点的状态
        // 是否与 Leader 保持同步
        for (LearnerHandler f : getLearners()) {
            if (f.synced()) {   
                syncedAckSet.addAck(f.getSid());
            }
        }
        ......
    }
    if (!tickSkip && !syncedAckSet.hasAllQuorums()) {
        // 如果失去了大多数 Follower 节点的认可，就跳出 Leader 主循环，进入选主流程
        break;
    }
    ......
}

// LearnerHandler::synced() 逻辑
// 即判断当前是否已经过了期望得到的 Follower 的下一个消息的期限：tickOfNextAckDeadline
public boolean synced() {
    return isAlive() && leader.self.tick.get() <= tickOfNextAckDeadline;
}

三、Zookeeper 选主机制

1、涉及到的相关概念

# Server id（myid 或 sid）：服务器 ID

比如有三台服务器，编号分别是 1,2,3。编号越大在选择算法中的权重越大，比如初始化启动时就是根据服务器 ID 进行比较。

# Zxid：事务ID

服务器中存放的数据的事务 ID，值越大说明数据越新，在选举算法中数据越新权重越大。

zxid 有两部分组成：高 32位 是 epoch，低 32位 是 epoch 内的自增 id，由 0 开始。每次选出新的 Leader，epoch 会递增，同时 zxid 的低 32 位清 0

# Epoch：逻辑时钟

也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的，每投完一次票这个数据就会增加。

2、Zookeeper 选举流程

选举大致流程：

  • 初始投票：服务器启动后，每个 Server 都会给自己投上一票，每次投票会包含所投票服务器的 myid 和 zxid
  • 同步投票结果：集群中的服务器在投票后，会将各自的投票结果同步给集群中其他服务器。
  • 检查投票有效性：各服务器在收到投票后会检查投票的有效性，如：是否本轮投票，是否来自 LOOKING 状态的服务器的投票等。
  • 处理投票：服务器之间会进行投票比对，规则如下：①、优先检查 zxid，较大的服务器优先作为 Leader；②、如果 zxid 相同，则 myid 较大的服务器作为 Leader；
  • 统计投票结果：每轮投票比对之后都会统计投票结果，确认是否有超过半数的机器都得到相同的投票结果，如果是，则选出 Leader，否则继续投票。
  • 更改服务器状态：一旦选出 Leader，每个服务器就会各自更新自己的状态

3、集团初始选举

假设我们有服务器 1～5，服务器初始化启动选主流程（粗略版）：

  1. 「服务器1」启动，发起一次选举。「服务器1」投自己一票。此时「服务器1」票数一票，不够半数以上（3票），选举无法完成，「服务器1」状态保持为 LOOKING；
  2. 「服务器2」启动，再发起一次选举。「服务器1」和「服务器2」分别投自己一票并交换选票信息；此时「服务器1」发现「服务器2」的 myid 比自己目前投票推举的「服务器1」大，更改选票为推举「服务器2」。此时「服务器1」票数 0 票，服「务器2」票数 2 票，没有半数以上结果，选举无法完成，「服务器1」，「服务器2」保持 LOOKING；
  3. 「服务器3」启动，发起一次选举。此时「服务器1」和「服务器2」都会更改选票为「服务器3」。此次投票结果：「服务器1」、「服务器2」为 0。票，「服务器3」为 3。票。此时「服务器3」的票数已经超过半数，「服务器3」当选成为 Leader。「服务器1」、「服务器2」更改状态为 FOLLOWING，「服务器3」更改状态为 LEADING；
  4. 「服务器4」启动，发起一次选举。此时「服务器1，2，3」已经不是 LOOKING 状态，不会更改选票信息。交换选票信息结果：「服务器3」为 3 票，「服务器4」为 1 票。此时「服务器4」服从多数，更改选票信息为「服务器3」，并更改状态为 FOLLOWING；
  5. 「服务器5」同「服务器4」。

4、集群重新选举

Zookeeper 集群运行期间无法和 Leader 保持正常连接时，即如果 Leader 挂了，或者 Leader 服务器故障都会进行新一轮的 Leader 选举。需要重新选举时，选举过程就需要加入数据 id，服务器id，和逻辑时钟。

img

集群重新选举时，根据 myid 和 zxid 的大小共同决断，zxid 更大的优先成为 Leader，选举的标准（粗略版）：

  • 逻辑时钟小的选举结果会被忽略，重新投票；
  • 统一逻辑时钟后，事务 id 大的胜出，当选 Leader；
  • 事务 id 相同的情况下，服务器 id 大的胜出，当选 Leader。

5、选举流程总结

总结：Zookeeper 集群按 myid 从小到大依次启动初始化时，在超过半数机器的投票的情况下，谁的 myid 最后，谁就是 Leader，知道这个定律，不同的集群规模我们都可以推算出谁是 Leader。

# 集群初始化时：

  • 集群有 3 台机器，第 2 大的 myid 所在服务器就是 Leader
  • 集群有 4 台机器，第 3 大的 myid 所在服务器就是 Leader；
  • 集群有 5 台机器，第 3 大的 myid 所在服务器就是 Leader；
  • 集群有 6 台机器，第 4 大的 myid 所在服务器就是 Leader；

集群重新选举时，根据 myid 和 zxid 的大小共同决断，zxid 更大的优先成为 Leader。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/20122.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

业务定制型异地多活架构设计

业务定制型异地多活架构设计

1个原理 大道至简-异地多活核心原理 异地多活本质上是 CAP 中的AP 大道至深-CAP 粒度 CAP 关注的粒度是数据&#xff0c;而不是系统&#xff0c;需要根据不同业务的数据特点来设计异地多活 延迟 CAP 是忽略网络延迟的 &#xff0c;但工程落地不可能做到零延迟 分区容忍…
阅读更多...
【Linux】linux中你不得不爱的命令集（上）

【Linux】linux中你不得不爱的命令集（上）

Linux命令集 我们将要介绍的命令并不是linux中所有的命令&#xff0c;是我们常见的和经常要使用的命令。 我们所用的linux版本是centos7&#xff0c;我们的linux搭建是在腾讯云服务器上搭建的&#xff0c;借助Xshell登录服务器&#xff0c;在root下进行命令行的操作。 目录 L…
阅读更多...
[附源码]java毕业设计社区生鲜仓库管理系统

[附源码]java毕业设计社区生鲜仓库管理系统

项目运行 环境配置&#xff1a; Jdk1.8 Tomcat7.0 Mysql HBuilderX&#xff08;Webstorm也行&#xff09; Eclispe&#xff08;IntelliJ IDEA,Eclispe,MyEclispe,Sts都支持&#xff09;。 项目技术&#xff1a; SSM mybatis Maven Vue 等等组成&#xff0c;B/S模式 M…
阅读更多...
异地多活架构的3种模式

异地多活架构的3种模式

业务定制型异地多活 按照业务的优先级进行排序&#xff0c;优先保证核心业务异地多活 基于核心业务的流程和数据&#xff0c;设计定制化的异地多活架构 优点 对基础设施无强要求&#xff0c;例如机房部署、存储系统、时延等&#xff0c;一般部署在远距离的两个城市&#xff…
阅读更多...
经济师报考专业选择及难度分析！这三个专业每年报考人数超10万！

经济师报考专业选择及难度分析！这三个专业每年报考人数超10万！

经济师 经济师考试报考专业设有10个专业&#xff0c;含工商管理、农业经济、财政税收、金融、保险、运输经济、人力资源管理、旅游经济、建筑与房地产经济、知识产权。那么&#xff0c;哪些专业是经济师报考的热门专业&#xff1f;哪些专业前景较好&#xff1f;哪个又更好考呢…
阅读更多...
SAP 物料分类账配置详解Part 2（ 基于SAP S/4HANA1909 版本）

SAP 物料分类账配置详解Part 2（ 基于SAP S/4HANA1909 版本）

1.12 检查物料会计科目的结算 1.13 激活在制品实际成本计算 1.14 定义并分配评估策略 1.15 定义实际成本核算/物料分类帐的访问 1.16 分配成本核算码到物料类型 1.17 将评估范围设置为生产 1.12 检查物料会计科目的结算 1.12.1 概念说明 为物料分类账的结账配置自动…
阅读更多...
C++模拟OpenGL库——图片处理及纹理系统（二)：图片Alpha值混合操作

C++模拟OpenGL库——图片处理及纹理系统（二)：图片Alpha值混合操作

目录 Alpha值混合操作 更改一些类接口设置&#xff0c;实现Alpha值设定 Alpha值混合操作 先上图&#xff0c;其实原理和ColorLerp的原理一样&#xff0c;一种线性插值的方法来实现Alpha通道的混合。 Alpha通道就是对RGB三个值的一种表现约束&#xff0c;比如Alpha0.5&#x…
阅读更多...
使用keytool生成Tomcat证书

使用keytool生成Tomcat证书

一、HTTPS原理 1、HTTP、HTTPS、SSL、TLS介绍与相互关系 &#xff08;1&#xff09;HTTP&#xff1a;平时浏览网页时候使用的一种协议。HTTP协议传输的数据都是未加密的&#xff08;明文&#xff09;&#xff0c;因此使用HTTP协议传输隐私信息非常不安全。 &#xff08;2&am…
阅读更多...
人工智能学习相关笔记

人工智能学习相关笔记

文章目录留出法(hold-out)Artifact (error)理解交叉熵损失函数(CrossEntropy Loss)信息量信息熵相对熵(KL散度)交叉熵交叉熵在单分类问题中的应用回顾知识蒸馏公式对抗学习随机投影(Random Projection)概述基本实现sklearn中的随机投影独立成分分析(ICA)ICA算法ICA 应用sklearn…
阅读更多...
tslib库编译与移植

tslib库编译与移植

tslib库编译与移植 1.tslib库简介 tslib 是电阻式触摸屏用于校准的一个软件库&#xff0c;是一个开源的程序&#xff0c;能够为触摸屏驱动获得的采样提供诸如滤波、去抖、校准等功能&#xff0c;通常作为触摸屏驱动的适配层&#xff0c;为上层的应用提供了一个统一的接口。 2…
阅读更多...
数据结构——顺序表

数据结构——顺序表

目录 一.简介 线性表 顺序表 二.结构体与初始化 1.创建 2.初始化 三.功能实现 1.打印 2.销毁 3.扩容 4.尾插 5.尾删 6.头插 7.头删 8.查找元素 9.下标位置的插入与某一数据前的插入 10.下标位置的删除与某一数据的删除 11.头插、头删、尾插、尾删的常态化 一.简…
阅读更多...
模块电路选型（1）----电源模块

模块电路选型（1）----电源模块

系列文章目录 1.电源模块 2.主控模块 3.传感器模块 4.通信模块 5.电机驱动模块 6.存储模块 7.人机交互模块 文章目录前言一、DCDC电源模块1、LM2596 DCDC降压模块设计二、LDO电源模块1、1117芯片前言 送给大学毕业后找不到奋斗方向的你&#xff08;每周不定时更新&#x…
阅读更多...
Spring Data JPA之Spring boot整合JPA进行CRUD

Spring Data JPA之Spring boot整合JPA进行CRUD

Spring boot整合JPA进行CRUD前言系列博客本博客的实现demo环境配置1.POM依赖2.application.yml文件完整的项目结构代码实现实体类启动类创建数据访问层使用Spring Data JPA 创建带条件的CRUD编写业务层创建UserController类运行测试插入用户数据删除用户数据修改数据查询数据根…
阅读更多...
kubernetes（K8S）学习笔记P2：搭建K8s集群2种方式

kubernetes（K8S）学习笔记P2：搭建K8s集群2种方式

搭建K8s集群&#xff1a;2种方式2.搭建K8s集群--->kubeadm2.1环境准备2.1.1关闭防火墙2.1.2关闭seliux2.1.3关闭swap分区2.1.4设置主机名称2.1.5将桥接的IPv4流量传递到iptables的链2.1.6时间同步2.2三台虚拟机都安装Docker2.3添加阿里云YUM软件源2.4安装/kubeadm/kubelet2.…
阅读更多...
dubbo：从零理解及搭建dubbo微服务框架（一）【附带源码】

dubbo：从零理解及搭建dubbo微服务框架（一）【附带源码】

0.引言 dubbo作为阿里巴巴开源的微服务框架&#xff0c;提供了高性能的RPC调用。同时因为有阿里的背书&#xff0c;在国内市场得到了广泛应用&#xff0c;dubbo的开源工作在2018年2月阿里将项目捐献给apache基金会后&#xff0c;得到了更加广大的发展。 之前我们讲解了spring…
阅读更多...
【图像分割】2021-Swin-Unet CVPR

【图像分割】2021-Swin-Unet CVPR

【图像分割】2021-Swin-Unet CVPR 论文题目&#xff1a;Swin-Unet: Unet-like Pure Transformer for Medical Image Segmentation 论文链接&#xff1a;https://arxiv.org/abs/2105.05537 论文代码&#xff1a;https://github.com/HuCaoFighting/Swin-Unet 发表时间&#xff1a…
阅读更多...
财政政策与货币政策

财政政策与货币政策

财政政策与货币政策 – 潘登同学的宏观经济学笔记 文章目录财政政策与货币政策 -- 潘登同学的宏观经济学笔记中国财政状况中国的财政盈余乘数效应还是李嘉图等价“乘数效应”还是“挤出效应”&#xff08;crowding out&#xff09;——“破窗理论”的启示货币政策中国货币的状况…
阅读更多...
GreaalVM编译springboot编译springboot

GreaalVM编译springboot编译springboot

GreaalVM编译springboot编译springboot 原文转自&#xff1a;https://lingkang.top/archives/greaalvm%E7%BC%96%E8%AF%91springboot https://lingkang.top/archives/greaalvm%E7%BC%96%E8%AF%91springboot window下使用GreaalVM编译springboot存在很多坑&#xff0c;主要是…
阅读更多...
IfcOpenShell - Python 2022最新安装步骤 兼谈IFC的理解与认识

IfcOpenShell - Python 2022最新安装步骤 兼谈IFC的理解与认识

前言 我之前2020年写了一个IfcOpenShell - Python的安装教程&#xff0c;相信不少对IFC感兴趣的朋友已经看过。两年多以后发生了很多事情&#xff0c;我的工作重心也不再是IFC IFCXML。目前我对IFC的理解就是“底层数据库”&#xff0c;以他为数据库我可以做很多尝试&#xff…
阅读更多...
P1113 杂务

P1113 杂务

分析:可以把每个任务看成都一个节点,如果有2个任务a,b,如果a是b的准备工作,那么就在a,b之间连一条有向边。由于互相没有关系的杂务可以同时工作,所以发现所有杂务都被完成的最短时间取决与最晚被完成的那个任务&#xff0c;于是需要找到最晚被完成任务的时间。 因为题目中有一…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023