分布式算法(五):初识ZAB协议

文章目录

  • 一、什么是Zookeeper
  • 二、ZAB与Zookeeper的关系
    • 为什么Zookeeper不直接使用Paxos
  • 三、ZAB简介
    • 1.名词解释
      • 提案(Proposal)
      • 事务(Transaction)
      • 原子广播(Atomic Broadcast)
    • 2.集群角色
      • 领导者(Leader)
      • 跟随者(Follower)
      • 观察者(Observer)
    • 3.成员状态
    • 4.运行阶段
      • (1)Leader Election(领导者选举阶段)
      • (2)Discovery(发现阶段)
      • (3)Synchronization(同步阶段)
      • (4)Broadcast(广播阶段)
      • Commit(提交阶段)
      • Observer Handling(观察者处理)
    • 5.事务标识符
      • 作用
      • 示例

一、什么是Zookeeper

Zookeeper 是一种分布式协调服务,它帮助分布式系统中的进程或服务之间进行协作。通过提供一套简单的原语和 API,Zookeeper 使得开发者可以更容易地实现复杂的协调任务,如:

  • 配置管理:应用程序可以在 Zookeeper 中存储配置信息,并且可以在配置发生变化时得到通知。
  • 命名服务:为分布式系统中的组件提供一个统一的名字空间,类似 DNS 之于互联网。
  • 分布式同步:提供机制以确保多个节点之间的操作能够按照一定的顺序执行。
  • 组成员管理:跟踪集群中成员的状态,检测成员的加入和离开。
  • 领导选举:在一组服务器中选出一个领导者来协调某些活动。

Zookeeper 的核心概念包括:

  • Znodes(节点):类似于文件系统中的文件和目录,数据被组织成树状结构。
  • Ephemeral nodes(临时节点):这类节点在创建它们的客户端断开连接后会被自动删除。
  • Watchers(监视器):允许客户端等待特定事件的发生,例如节点数据的变化或子节点的增删。
  • ACLs(访问控制列表):用于控制哪些客户端可以对 znodes 执行什么类型的访问。

关于Zookeeper的简单介绍可以看我的另一篇blog:https://blog.csdn.net/Tracycoder/article/details/142792750

二、ZAB与Zookeeper的关系

ZAB(Zookeeper Atomic Broadcast)协议是 Zookeeper 的核心技术,它通过实现领导者选举、原子广播和事务日志同步,确保了分布式系统中数据的一致性和可靠性,并且能够在节点故障时维持服务的连续性和高可用性。ZAB 保证所有服务器按照全局一致的顺序处理更新操作,提供顺序一致性,同时支持一定的容错能力,使得 Zookeeper 能够有效地协调分布式应用程序中的各个组件。

虽然ZAB是在特定的应用场景下设计的(ZooKeeper),但它确实借鉴并实现了Paxos的核心思想——特别是关于如何通过多数派投票机制达成一致。因此,可以说ZAB是基于Paxos多数派思想的共识算法。

为什么Zookeeper不直接使用Paxos

Zookeeper 选择不直接使用 Paxos 协议,而是开发了自己的 ZAB协议,主要是因为 Paxos 虽然在理论上提供了强大的一致性保证,但在实际应用中实现和理解都非常复杂,尤其是在构建高效的分布式系统时。以下是 Zookeeper 不直接采用 Paxos 的一些主要原因:

  • Paxos 的复杂性:Paxos 协议虽然解决了分布式共识问题,但其算法本身非常抽象且难以理解和实现。对于大多数开发者来说,正确地实现 Paxos 是一个挑战,这可能导致实现上的错误,影响系统的稳定性和可靠性。

  • 性能考虑:Paxos 在处理某些类型的故障或网络分区时可能会导致性能下降。例如,在领导者选举过程中,Paxos 可能需要多次通信轮次才能达成一致,这在高负载或网络延迟较高的情况下会显著降低性能。

  • 特定需求:Zookeeper 需要一种能够支持顺序一致性、快速恢复以及高效领导者选举的协议。虽然 Paxos 提供了一致性,但它并不直接支持这些特性。因此,Zookeeper 团队设计了 ZAB,它更专注于满足 Zookeeper 的具体需求,如高效的领导者选举和事务日志同步。

  • 简化操作:ZAB 协议简化了许多操作,比如通过引入一个持久的领导者来减少决策过程中的复杂性,并确保所有更新都按全局一致的顺序执行。此外,ZAB 还实现了原子广播功能,这对于 Zookeeper 所需的分布式协调服务非常重要。

  • 容错机制:ZAB 设计了更为直观的容错机制,可以在部分节点失效的情况下继续运作,同时允许失效节点重新加入集群后快速同步状态,这比直接应用 Paxos 更加高效和实用。

三、ZAB简介

1.名词解释

在 ZAB(Zookeeper Atomic Broadcast)协议中,提案(Proposal)、事务(Transaction)和原子广播(Atomic Broadcast)是三个核心概念。

提案(Proposal)

提案是指由 Zookeeper 集群中的领导者发起的一个变更提议。每个提案包含了客户端请求的具体操作(如创建节点、删除节点等),以及一个唯一的序列号,用来确保所有提案按照全局一致的顺序被处理。

事务(Transaction)

在 ZAB 的上下文中,事务指的是对 Zookeeper 状态的一次或多次更改的集合。一次事务可以包含多个操作(例如创建多个 znode 或修改现有 znode 的数据),但这些操作被视为一个不可分割的整体。
事务具有原子性,即事务中的所有操作要么全部成功执行,要么完全不执行。这保证了即使在网络故障或其他异常情况下,系统的状态仍然保持一致。

原子广播(Atomic Broadcast)

原子广播是 ZAB 协议的核心功能之一,它确保了所有集群成员以相同的顺序接收并应用相同的消息(即提案)。这意味着一旦一个消息被广播给所有成员,那么这个消息最终会被所有正常工作的成员接收到,并且不会有任何成员接收到部分消息或不同版本的消息。

原子性 指Follower要么全部批准,要么全部拒绝。

2.集群角色

在 ZAB(Zookeeper Atomic Broadcast)协议中,集群中的每个节点(也称为服务器或成员)都可以扮演不同的角色。这些角色对于确保集群的正常运作、数据一致性和高可用性至关重要。以下是 ZAB 协议中常见的集群角色:

领导者(Leader)

  • 职责
    • 负责接收来自客户端的所有写请求,并将这些请求转化为提案(Proposal),然后广播给所有跟随者。
    • 管理提案的提交过程,确保所有跟随者按照全局一致的顺序处理提案。

跟随者(Follower)

  • 职责
    • 接收来自领导者的提案,并对提案进行投票确认。
    • 如果大多数跟随者同意了某个提案,则该提案会被提交并应用到本地状态机上。
    • 跟随者也会转发读请求给领导者处理,但可以直接响应只读请求(在某些配置下)。

观察者(Observer)

  • 职责
    • 类似于跟随者,观察者也会接收来自领导者的提案,并同步其状态。
    • 然而,观察者不会参与投票过程,因此它们的存在不影响法定人数(Quorum)的计算。
    • 主要用于扩展 Zookeeper 集群的读取能力,减轻领导者和跟随者的负载。

3.成员状态

ZAB(ZooKeeper Atomic Broadcast)协议是ZooKeeper用来实现分布式一致性的一个关键组件。它确保所有服务器能够就一系列更新达成一致,即使在某些服务器故障的情况下也是如此。ZAB协议定义了几个成员状态:

ELECTION

  • 当集群中的领导者(Leader)宕机或与大多数Follower失去联系时,ZooKeeper进入ELECTION状态。
  • 在这个状态下,每个服务器都认为自己可能是新的领导者,并尝试选举一个新的领导者。
  • 一旦选出了新的领导者,所有参与者将从ELECTION状态转移到FOLLOWING或LEADING状态。

LEADING

  • 只有一个服务器可以处于LEADING状态,即当前的领导者。
  • 领导者负责协调所有的写操作,确保它们被正确地广播到所有的Follower。
  • 领导者还负责发起和协调新的选举过程,如果它检测到自己不再是多数派的一员。

FOLLOWING

  • 大部分服务器会处于FOLLOWING状态,作为跟随者(Follower)。
  • 跟随者接收来自客户端的读请求并直接处理它们(因为ZooKeeper的数据模型是可复制的),而对于写请求,则转发给领导者。
  • 它们也接收来自领导者的提议(Proposal)并且应用这些提议以保持数据的一致性。

OBSERVING

  • 这个状态是在加入新成员或重新连接断开成员时使用的一种特殊状态。
  • 观察者(Observer)不参与选举,但它们会像跟随者一样接收和处理来自客户端的请求以及来自领导者的提议。
  • 观察者帮助分担读取负载而不影响写入路径的一致性决策。

4.运行阶段

ZAB(Zookeeper Atomic Broadcast)协议的运行过程可以分为几个关键阶段,这些阶段确保了集群中数据的一致性和高可用性。以下是 ZAB 协议的主要运行阶段:

在这里插入图片描述

(1)Leader Election(领导者选举阶段)

  • 触发条件:当 Zookeeper 集群启动时或当前领导者失效时。
  • 过程
    • 所有服务器尝试成为领导者,通过一个协商过程来决定哪个服务器将成为新的领导者。
    • 每个服务器会广播自己的提议,并收集其他服务器的投票。
    • 如果一个服务器获得了超过半数的票数(即法定人数),它就成为新的领导者。
    • 新的领导者将同步其状态与最完整的事务日志副本保持一致。

(2)Discovery(发现阶段)

  • 描述:新选出来的领导者进入此阶段,以确保所有跟随者都知道谁是新的领导者,并且所有跟随者都同意领导者的最新状态。
  • 过程
    • 领导者向所有跟随者发送心跳消息,确认它们的状态。
    • 跟随者回复它们最后处理的事务 ID,以便领导者了解每个跟随者的状态。
    • 领导者根据跟随者的反馈确定需要发送给每个跟随者的最小事务集,以使它们的状态与自己同步。

(3)Synchronization(同步阶段)

  • 描述:在这个阶段,领导者确保所有跟随者的状态与其自身一致。
  • 过程
    • 领导者发送必要的缺失事务给跟随者,以更新它们的状态。
    • 跟随者应用这些事务并确认完成。
    • 当大多数跟随者(法定人数)确认后,领导者认为集群已经同步完成。

(4)Broadcast(广播阶段)

  • 描述:一旦集群同步完成,领导者开始正常接收和处理客户端请求。
  • 过程
    • 领导者接收来自客户端的写请求,将其转化为提案(Proposal),并广播给所有跟随者。
    • 跟随者对收到的提案进行投票确认。
    • 如果大多数跟随者同意,则该提案被提交,所有成员按照相同的顺序应用这个提案。
    • 对于读请求,跟随者可以直接响应,而不需要经过领导者(在某些配置下)。

ZAB协议中的消息广播类似于两阶段提交(2PC)的过程, 因为它同样依赖于一个领导者来协调所有跟随者的行动,并通过两个主要阶段确保数据的一致性:首先,领导者将提议的消息广播给所有跟随者并等待它们的确认(类似于2PC的准备阶段);一旦收到大多数跟随者的确认,领导者就会通知所有节点应用该消息,从而完成广播(类似于2PC的提交阶段)。这种机制保证了即使在部分节点故障的情况下,系统仍能维持一致性和可用性。
但是,ZAB采用了一种更简单的两阶段过程: 提议阶段和提交阶段。领导者一旦收到大多数跟随者的确认,就可以立即通知所有节点应用提议。而2PC需要额外的准备阶段来询问每个参与者是否可以执行操作,这增加了延迟。消息广播还移除了第二阶段的中断逻辑,所有的Follower要么批准每一个Proposal,要么抛弃Leader服务器。

Commit(提交阶段)

  • 描述:当一个提案获得法定人数的认可后,它就会被提交。
  • 过程
    • 领导者通知所有跟随者提交该提案。
    • 每个跟随者将提案应用于本地状态机,并更新其状态。
    • 提交完成后,提案所代表的操作正式生效。

Observer Handling(观察者处理)

  • 描述:观察者不参与投票,但仍然需要保持最新的状态。
  • 过程
    • 观察者从领导者那里接收提案并应用到本地状态机上。
    • 它们可以响应只读请求,但不会影响法定人数的计算。

5.事务标识符

ZAB(ZooKeeper Atomic Broadcast)协议中的事务标识符 zxid 是一个非常重要的概念,它用于唯一标识每个事务,并确保事务的顺序性。zxid 是一个64位的数字,由两部分组成:

  1. EPOCH (32位):表示领导者的周期或者任期。每当选举出一个新的领导者时,EPOCH会增加。这有助于区分不同领导者的提议,即使它们在不同的任期内提出了相同的本地序列号。

  2. COUNT (32位):是领导者提出的事务在其任期内的递增计数器。每次领导者提出新的提议时,COUNT都会增加。这意味着在同一任期内,COUNT可以用来对提议进行排序。

作用

  • 唯一性:由于zxid结合了EPOCH和COUNT,因此它可以保证每个事务在整个集群中都是唯一的。
  • 全局有序:通过zxid,可以确保所有服务器上的事务按照相同的顺序被应用,这对于维护数据的一致性和正确性至关重要。
  • 故障恢复:当一个新的领导者被选出来之后,它可以通过比较zxid来确定哪些事务已经被确认,哪些还没有,从而能够安全地继续处理未完成的事务。

示例

假设我们有一个初始的zxid为0x0000000100000001,这里前32位是EPOCH(0x00000001),后32位是COUNT(0x00000001)。如果这个领导者发起了两个事务,那么第二个事务的zxid将会是0x0000000100000002。如果此时发生了领导者变更,新的领导者的EPOCH将变为0x00000002,而它的第一个事务的zxid可能是0x0000000200000001。

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

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

RabbitMQ基础篇之Java客户端 Topic交换机

文章目录 Topic 交换机概述 Routing Key 与 Binding Key优缺点及场景优点缺点应用场景 案例演示创建队列和交换机:消费者代码:消息发送代码:测试: 总结 Topic 交换机概述 路由机制: Topic交换机与Direct交换机类似&am…

开源模型应用落地-LangChain实用小技巧-使用各种Loader高效解析不同数据源(七)

一、前言 在 LangChain框架中,提供了Loader机制,以统一的方式来从各种数据源获取数据,使得开发人员可以方便地集成不同类型的数据源,而无需为每种数据源编写特定的加载代码。它可以将不同格式的数据转换为 LangChain 可以处理的统…

SSRF服务端请求Gopher伪协议白盒测试

前言 是什么SSRF? 这个简单点说就是 服务端的请求伪造 就是这个如果是个 请求图片的网站 他的目的是请求外部其他网站的 图片 但是 SSRF指的是让他请求本地的图片 再展示出来 请求的是他的服务器上的图片 SSRF(Server-Side Request Forgery:服务器端请求伪造) …

数据可视化-16. 日历图

目录 1. 日历图的概念 2. 日历图的适用场景 2.1 事件或活动的频率分析 2.2 数据的时间周期性分析 2.3 异常值检测 2.4 绩效监控 3. 日历图的缺陷 3.1 粒度受限于天数 3.2 数据密度过高时候难以解读 3.3 难以比较多个数据集 3.4 周期性较长的数据不易展示 4. 日历图…

Flink源码解析之:如何根据JobGraph生成ExecutionGraph

Flink源码解析之:如何根据JobGraph生成ExecutionGraph 在上一篇Flink源码解析中,我们介绍了Flink如何根据StreamGraph生成JobGraph的流程,并着重分析了其算子链的合并过程和JobGraph的构造流程。 对于StreamGraph和JobGraph的生成来说&…

LeetCode算法题——有序数组的平方

题目描述 给你一个按非递减顺序排序的整数数组nums,返回每个数字的平方组成的新数组,要求也按非递减顺序排序。 题解 解法一:暴力解法 思路: 该题目可通过暴力解法解决,即利用for循环遍历数组,对数组每…

【Python】FastAPI之SQLAlchemy、关联关系

第四节:SQLAlchemy操作数据库 一、SQLAlchemy介绍 SQLAlchemy 是一个功能强大且灵活的 Python SQL 工具包及对象关系映射(ORM)库,它提供了全面的数据库访问抽象层。通过 SQLAlchemy,开发者可以使用 Python 代码来定义…

GRAPE——RLAIF微调VLA模型:通过偏好对齐提升机器人策略的泛化能力(含24年具身模型汇总)

前言 过去的这两年,工作之余,我狂写大模型与具身的文章,加之具身大火,每周都有各种朋友通过CSDN私我及我司「七月在线」寻求帮助/指导(当然,也欢迎各大开发团队与我司合作共同交付): 要么是做…

基于 LangChain 实现数据库问答机器人

基于 LangChain 实现数据库问答机器人 一、简介二、应用场景三、实战案例1、需求说明2、实现思路3、对应源码 一、简介 在 Retrieval 或者 ReACT 的一些场景中,常常需要数据库与人工智能结合。而 LangChain 本身就封装了许多相关的内容,在其官方文档-SQ…

Kali 自动化换源脚本编写与使用

1. 背景与需求 在使用 Kali Linux 的过程中,软件源的配置对系统的更新与软件安装速度至关重要。 Kali 的默认官方源提供了安全且最新的软件包,但有时由于网络条件或地理位置的限制,使用官方源可能会出现速度较慢的问题。 为了解决这一问题&a…

1Panel自建RustDesk服务器方案实现Windows远程macOS

文章目录 缘起RustDesk 基本信息实现原理中继服务器的配置建议 中继服务器自建指南准备服务器安装1Panel安装和配置 RustDesk 中继服务防火墙配置和安全组配置查看key下载&安装&配置客户端设置永久密码测试连接 macOS安装客户端提示finder写入失败hbbs和hbbr说明**hbbs…

Maple软件的安装和使用

文章目录 1.前言说明2.我为什么要学习Maple3.软件的安装4.如何使用4.1基本的赋值语句4.2函数的定义4.3三个类型的书写介质 5.指数运算5.1使用面板5.2自己输入 6.对数的使用 1.前言说明 众所周知,我虽然是一名这个计算机专业的学生,但是我对于数学&#…

Nacos配置中心总结

Nacos配置中心总结 Nacos配置文件的加载顺序和优先级 加载顺序 nacos作为配置中心时,需要在bootstrap.yml文件中添加nacos config相关的配置,这样系统启动时就能先去拉取nacos server上的配置了。拉取过来后会和本地配置文件进行合并。 bootstrap.ym…

Java开发-后端请求成功,前端显示失败

文章目录 报错解决方案1. 后端未配置跨域支持2. 后端响应的 Content-Type 或 CORS 配置问题3. 前端 request 配置问题4. 浏览器缓存或代理问题5. 后端端口未被正确映射 报错 如下图,后端显示请求成功,前端显示失败 解决方案 1. 后端未配置跨域支持 …

springboot523基于Spring Boot的大学校园生活信息平台的设计与实现(论文+源码)_kaic

摘 要 现代经济快节奏发展以及不断完善升级的信息化技术,让传统数据信息的管理升级为软件存储,归纳,集中处理数据信息的管理方式。本大学校园生活信息平台就是在这样的大环境下诞生,其可以帮助管理者在短时间内处理完毕庞大的数据…

【Ubuntu使用技巧】Ubuntu22.04无人值守Crontab工具实战详解

一个愿意伫立在巨人肩膀上的农民...... Crontab是Linux和类Unix操作系统下的一个任务调度工具,用于周期性地执行指定的任务或命令。Crontab允许用户创建和管理计划任务,以便在特定的时间间隔或时间点自动运行命令或脚本。这些任务可以按照分钟、小时、日…

Linux(14)——网络管理

目录 一、检测网络配置: 1、查看网络接口(ip): 2、查看性能(ip): 3、查看 IP 地址(ip): 4、查看路由表(ip): 5、追踪…

《机器学习》——线性回归模型

文章目录 线性回归模型简介一元线性回归模型多元线性回归模型误差项分析一元线性模型实例完整代码 多元线性模型实例完整代码 线性回归模型简介 线性回归是利用数理统计中回归分析,来确定两种或两种以上变量间相互依赖的定量关系的一种统计分析方法。 相关关系&…

GeoTrust True BusinessID Wildcard

GeoTrust由DigiCert 提供支持,是最受信任和尊重的品牌之一,以提供高保证的网站安全而闻名。 GeoTrust True BusinessID通配符证书 – 以低成本保护多个主机名。即使将其用于您的公司主页或电子邮件服务器主机名,保护所有敏感信息也是您的目标…

华为配置 之 链路聚合

简介: 链路聚合(Link Aggregation)是一种计算机网络技术,通过将多个物理端口汇聚在一起,形成一个逻辑端口,以实现出/入流量吞吐量在各成员端口的负荷分担。当交换机检测到其中一个成员端口的链路发生故障时…