聊聊分布式架构10——Zookeeper入门详解

这篇具有很好参考价值的文章主要介绍了聊聊分布式架构10——Zookeeper入门详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

01ZooKeeper的ZAB协议

ZAB协议概念

ZAB协议基本模式

消息广播

崩溃恢复

选举出新的Leader服务器

数据同步

02Zookeeper的核心

ZooKeeper 的核心特点

ZooKeeper 的核心组件

选举算法概述

服务器启动时的Leader选举

服务器运行期间的Leader选举

03ZooKeeper的简单使用

04ZooKeeper的应用场景



聊聊分布式架构10——Zookeeper入门详解,分布式架构,分布式,架构,zookeeper

01ZooKeeper的ZAB协议

在解决一致性方面,Zookeeper并没有直接采用Paxos算法,而是采用了一种被称为ZAB(ZooKeeper Atomic Broadcast)的一致性协议。

ZAB协议概念

ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。基于该协议,Zookeeper实现了一种主备模式的系统架构来维持集群中各副本之间数据的一致性。

ZAB协议的核心是定义了事务请求的处理方式:

所有事务请求必须由一个全局唯一的服务器来协调处理,这样的服务器被称为Leader服务器,而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换为一个事务Proposal(提议),并将该Proposal分发给集群中的所有Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈,一旦超过半数的Follower服务器进行了正确的反馈后,那么Leader就会再次向所有的Follower服务器发布Commit信息,要求将前一个Proposal进行提交。

ZAB协议基本模式

ZAB 协议包括两种基本模式:消息广播和崩溃恢复。

  1. 消息广播:这是 ZAB 协议的基本模式之一,用于确保 ZooKeeper 集群中的所有节点都接收到相同的消息。在这种模式下,ZooKeeper 集群中的 leader 节点负责将客户端请求转化为一系列的消息,然后将这些消息广播给所有的 follower 节点。每个 follower 节点接收到消息后,会将消息写入本地的事务日志。一旦超过半数的节点确认接收了消息,leader 就可以提交这些消息,并将其应用到自己的状态机上,从而达到状态一致性。这确保了 ZooKeeper 的一致性和可靠性。

  2. 崩溃恢复:是 ZAB 协议的另一种基本模式,用于选择 ZooKeeper 集群中的 leader 节点。在一个 ZooKeeper 集群中,只有一个节点充当 leader,负责处理客户端请求并维护共享状态。如果当前的 leader 节点出现故障,集群需要选举一个新的 leader。ZAB 协议中的选举是基于消息广播的,节点会争相发送选举消息,然后根据规则选择新的 leader。选举过程确保了只有一个节点成为 leader,从而维持了一致性。

消息广播

ZAB的消息广播类似于二阶段提交。不同之处是ZAB协议移除了中断逻辑——Follower服务器要么Ack给Leader,要么抛弃Leader。当过半的Follower服务器反馈Ack之后就开始提交事务Proposal,而不需要等待集群中所有的Follower服务器都反馈响应。

聊聊分布式架构10——Zookeeper入门详解,分布式架构,分布式,架构,zookeeper

  • 消息广播是基于具有FIFO特性的TCP协议通信的,所以能很容易地保证消息广播过程中消息接收与发送的顺序性。

  • 整个消息广播过程中,leader服务器会为每一个事务请求生成一个Proposal来进行广播,并且在广播事务Proposal之前,Leader服务器会为这个事务分配一个全局单调递增的唯一ID,称之为事务ID(即ZXID)。而且每一个事务Proposal严格按照其ZXID的先后顺序进行排序和处理。

  • 消息广播过程中,Leader服务器会为每一个Follower服务器各自分配一个单独的队列,将需要广播的事务Proposal一次放入队列中,根据FIFO的策略发送。每一个Follower服务器在接收到这个事务Proposal之后,都会首先将其以事务日志的形式写入本地磁盘,在成功写入后反馈给Leader服务器一个Ack响应。服务器收到过半的Follower的Ack响应后,就会广播一个Commit消息给所有的服务器以通知其进行事务提交,同时Leader完成自身的事务提交,每一个Follower服务器收到Commit消息后,完成自身事务的提交。

需要注意的是:Leader服务器可以处理事务请求(包括创建、更新和删除节点等需要保证强一致性的操作)和非事务请求,Follower服务器只能处理非事务请求,如果Follower收到事务请求会转交给Leader服务器。

崩溃恢复

简化的二阶段提交模型是无法处理Leader崩溃带来的数据不一致问题。一旦Leader服务器出现崩溃,或者由于网络导致Leader服务器失去了过半Follower的联系,就会进入崩溃恢复模式。

崩溃恢复状态下,ZAB协议有两件事要做:

  • 选举出新的Leader服务器

  • 数据同步

选举出新的Leader服务器

整个崩溃过程结束后,需要选举出新的Leader服务器,而且还得让其他服务器感知到选举产生的新Leader服务器。

在ZAB协议中,崩溃恢复模式可能出现的两个数据不一致的隐患场景:

  1. 服务器Leader在确认半数通过后完成了进行自身事务的提交,但是发送Commit告知Follower进行事务提交的瞬间异常,这是第一个需要保证的特性:确保在Leader服务器提交过的事务最终被所有服务器都提交。

  2. ZAB协议规定:如果一个Proposal事务在一台机器上被处理成功,那么应该在所有的机器上都被处理成功,哪怕机器出现故障崩溃。(所以在过半确认过程中数据会被强制一致的)基于这个特性,如果Leader节点在提出了某个Proposal事务之后就崩了,没有告知到Follower进行本地提交,等崩溃恢复了,原本的Leader保留了提出这个Proposal的状态,此时应该直接丢弃而不是强制同步。这是第二个需要保证的特性:确保丢弃那些只在Leader服务器上被提出的事务。

结合这两种情况,ZAB协议设计的选举算法就必须要满足:能够确保提交已经被Leader提交的事务Proposal,同时丢弃已经被跳过的事务Proposal。

ZAB协议的Leader选举方案就是:拥有最大ZXID的Follower服务器作为新的Leader服务器。为什么呢?

  1. 在消息广播的过程中,Leader服务器进行自身事务的提交前提是收到了半数的Follower服务器的Ack响应,那么此时必然有Follower服务器的事务日志中保存了所有的proposal状态,包含Leader异常时提交的那份。

  2. Follower自身ZXID是64位,高32位是epoch编号,低32位是消息计数器,每接收到1条消息+1,新Leader选举后epoch会+1,消息计数器置为0。设计的好处在于,旧的Leader作为Follower接入时,它的ZXID是肯定小于新Leader的,而且新Leader会让它将所有的拥有旧的epoch号的未被Commit的proposal清除。

至此,就保证了崩溃恢复后数据的一致性。

数据同步

在选出新的Leader服务器后,需要开始数据同步。Leader服务器会为每一个Follower服务器准备一个队列,将那些没有被同步的事务以Proposal消息的形式逐个发给Follower服务器,在Follower服务器将所有未同步的proposal事务从Leader服务器上同步并成功应用到本地数据库中后,Leader服务器会将该Follower服务器加入真正可用的Follower列表中,然后开始之后的正常流程。

02Zookeeper的核心

ZooKeeper是一个开源的分布式协调服务,用于构建分布式应用和分布式系统。它提供了一个高度可靠的分布式协调基础设施,帮助应用程序在分布式环境中协同工作。ZooKeeper 通常用于解决分布式系统中的一致性、配置管理、锁服务、命名服务等问题。

ZooKeeper 的核心特点
  1. 分布式文件系统:ZooKeeper 维护一个分层的命名空间,类似于文件系统目录结构,它可以用于存储配置信息和分布式数据。

  2. 一致性:ZooKeeper 提供了强一致性的数据模型,即一旦数据被写入,所有客户端都能读取到最新的数据,从而确保数据的一致性。

  3. 高可用性:ZooKeeper 以多数节点的方式运行,即在集群中的节点数必须超过半数,以确保高可用性。如果一些节点失效,ZooKeeper 仍然能够提供服务。

  4. 快速通知:ZooKeeper 允许客户端监听节点数据的变化,一旦节点数据发生变化,相关的客户端将得到通知。

  5. 顺序一致性:ZooKeeper 允许客户端按照顺序创建节点,并提供了有序性保证,这在分布式锁服务中非常有用。

ZooKeeper 的核心组件
  1. 集群:ZooKeeper 集群由多个节点组成,这些节点分布在不同的机器上,它们协同工作以提供服务。典型的 ZooKeeper 集群包括奇数个节点,通常是 3、5 或 7 个节点,以确保多数节点可用。

  2. ZNode:ZNode 是 ZooKeeper 命名空间的基本单元,类似于文件系统中的目录或文件。每个 ZNode 可以包含数据,并具有一个路径名称。

  3. 会话:ZooKeeper 客户端与 ZooKeeper 服务器之间建立会话,会话是客户端与服务器之间的状态会话,用于保持连接和跟踪会话的生命周期。

  4. Watch:客户端可以在 ZNode 上设置 Watch,以便在 ZNode 数据发生变化时获得通知。

  5. 选举算法:ZooKeeper 使用选举算法来选举 leader 节点,leader 负责协调事务和保持一致性。

选举算法概述

分两种情况拆解下选举算法:服务器启动时的Leader选举和服务器运行期间的Leader选举。

服务器启动时的Leader选举

假设在集群中,有3台服务器已经可以互相通信,它们需要选出一个Leader服务器。有一个前提条件,它们拥有一个myid的属性,server1的myid是1,server2的myid是2,server3的myid是3。

1.每个server会发出一个投票

例如server1以(myid,zxid)格式发送给其他服务器投票的数据(1,0),server2发送的(2,0)。

2.接收来自每个服务器的投票

每个服务器都会收到其他服务器的投票,首先验证有效性,其次是否本轮投票、是否来自Looking状态的服务器。

3.处理投票

每个服务器根据规则处理收到的投票,规则如下:

  • 优先zxid。zxid大的优先作为Leader。

  • zxid相同,myid大的作为Leader。

那么,3台服务器的zxid都为0,就会比较myid。server1和server2根据规则会修改自身投票为(3,0)。然后重新向其他服务器发送投票。server3不用修改,只是再发送一次。

4.统计投票

每次投票,服务器都会统计所有投票判断是否产生了Leader,这里还是使用的过半概念:当有一半的服务器收到相同的投票时候,就认为已经选出了Leader。

5.改变服务器状态

一旦确定了Leader,服务器就会变更自己的状态:Follower会变更为FOLLOWING,Leader会变更为LEADING。

服务器运行期间的Leader选举

当Leader服务器挂掉的时候,就会进行新一轮的Leader选举。

1.变更状态

非Observer服务器会将自己的服务器状态变更为LOOKING,开始选举流程。(Observer服务器不参与选举也不投票)

2.每个server发出一个投票

与启动期间不同的是,运行期间的服务器可能有不同的zxid。例如server的投票(1,1112),server3的投票(3,1113)。

3.接收各个服务器的投票

4.处理投票,显然server3的zxid大,server3会成为Leader。

5.统计投票

6.改变服务器状态

03ZooKeeper的简单使用

可以参考这篇博客:

04ZooKeeper的应用场景

Apache ZooKeeper 在分布式系统中有多种典型应用场景,它提供了高度可靠的分布式协调服务,用于解决各种分布式系统的共识、配置管理和协同协作问题。以下是 ZooKeeper 的一些典型应用场景:

  1. 分布式配置管理:ZooKeeper 可用于存储和管理应用程序的配置信息。各个分布式节点可以监听配置节点,当配置发生变化时,节点能够及时获取最新的配置,实现动态配置管理。

  2. 分布式锁服务:ZooKeeper 提供了分布式锁服务,允许多个节点协同竞争获取锁。这对于协调分布式系统中的操作非常有用,确保只有一个节点能够执行关键操作。

  3. 分布式一致性:ZooKeeper 可以用于协调多个节点以达成一致的决策。它确保在分布式系统中节点的状态和数据是一致的,从而提供强一致性的数据存储。

  4. 服务发现:ZooKeeper 可用于注册和发现分布式系统中的服务。各个服务可以在 ZooKeeper 上注册自己的地址和状态,其他节点可以查询这些信息以发现可用的服务。

  5. 领导者选举:ZooKeeper 通常用于选举分布式系统中的领导者节点。它确保只有一个节点成为领导者,从而协调系统的操作。

  6. 分布式任务队列:ZooKeeper 可用于创建分布式任务队列,多个节点可以将任务推送到队列中,然后从队列中获取任务进行处理。

  7. 分布式协同协作:ZooKeeper 提供了分布式协调服务,可以用于构建分布式应用程序,确保多个节点协同协作并实现一致性。

  8. 分布式文件系统:虽然 ZooKeeper 不是一个文件系统,但它可以用于管理分布式系统中的文件和配置信息,作为分布式文件系统的一部分。

参考资料:从Paxos到Zookeeper  分布式一致性原理与实践 [倪超著]文章来源地址https://www.toymoban.com/news/detail-718890.html

到了这里,关于聊聊分布式架构10——Zookeeper入门详解的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 聊聊分布式架构02——Http到Https

    目录 HTTP通信协议 请求报文 响应报文 持久连接 状态管理 HTTPS通信协议 安全的HTTPS HTTP到HTTPS的演变 对称加密 非对称加密 混合加密机制 证书机构 SSL到底是什么 HTTPS是身披SSL外壳的HTTP HTTP通信协议 一次HTTP请求的通信流程:客户端浏览器通过域名访问网页资源,由DNS解析得到

    2024年02月07日
    浏览(17)
  • 聊聊分布式架构08——SpringBoot开启微服务时代

    目录 微服务架构时代 快速入门 入门详解 SpringBoot的自动配置 石器时代:XML配置bean 青铜时代:SpringConfig 铁器时代:AutoConfigurationImportSelector 手写简单Starter SpringApplication启动原理 微服务架构时代 Spring Boot的出现与微服务架构有关,它是Spring Framework的一部分,旨在简化开发独

    2024年02月06日
    浏览(24)
  • zookeeper分布式协调系统的架构设计与源码剖析

    目录 001_我们一般到底用ZooKeeper来干什么事儿? 002_有哪些开源的分布式系统中使用了ZooKeeper? 003_为什么我们在分布式系统架构中需要使用ZooKeeper集群? 004_ZooKeeper为了满足分布式系统的需求要有哪些特点 005_为了满足分布式系统的需求,ZooKeeper的架构设计有哪些特点? 006_

    2024年02月03日
    浏览(20)
  • Zookeeper入门实战(5)-分布式锁

    在分布式环境中,当需要控制对某一资源的不同进程并发访问时就需要使用分布式锁;可以使用 ZooKeeper + Curator 来实现分布式锁,本文主要介绍 Curator 中分布式锁的使用,文中所使用到的软件版本:Java 1.8.0_341、Zookeeper 3.7.1、curator 5.4.0。 信号量用于控制对资源同时访问的进

    2024年02月08日
    浏览(33)
  • 分布式应用程序协调服务 ZooKeeper 详解

    目录 1、ZooKeeper简介 2、ZooKeeper的使用场景 3、ZooKeeper设计目的 4、ZooKeeper数据模型

    2024年02月08日
    浏览(22)
  • SpringBoot整合Dubbo和Zookeeper分布式服务框架使用的入门项目实例

    Dubbo是一个 分布式服务框架 ,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。简单的说,dubbo就是个服务框架,如果没有分布式的需求,其实是不需要用的,只有在分布式的时候,才有dubbo这样的分布式服务框架的需求。其本质上是个远程服务调用

    2024年01月21日
    浏览(17)
  • 聊聊什么是分布式事务

    分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上,以上是百度百科的解释。 简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务

    2024年02月08日
    浏览(15)
  • 【分布式系统】聊聊高性能设计

    对于以上的数字,其实每个程序员都应该了解,因为只有了解这些基本的数字,才能知道对于CPU、内存、磁盘、网络之间数据读写的时间。1000ms = 1S。毫秒-微秒-纳秒-秒-分钟 为什么高性能如此重要的呢,在架构设计中,高性能、高可用、高并发是三高问题。其实背后对应的就

    2024年02月13日
    浏览(21)
  • 聊聊分布式解决方案Saga模式

    Saga模式使用一系列本地事务来提供事务管理,而一个本地事务对应一个Saga参与者,在Saga流程里面每一个本地事务只操作本地数据库,然后通过消息或事件来触发下一个本地事务,如果其中一个本地事务失败了,Saga就会执行一系列补偿事务来实现回滚操作。(补偿事务简单来

    2024年02月06日
    浏览(15)
  • 聊聊分布式 SQL 数据库Doris(七)

    Doris的存储结构是类似LSM-Tree设计的,因此很多方面都是通用的,先阅读了解LSM相关的知识,再看Doris的底层存储与读取流程会清晰透彻很多,LSM基本知识如下: 原理:把各种数据先用log等形式组织在内存中(该数据结构称为MemTable,且有序);到达一定数据量后再批量merge写入磁

    2024年02月05日
    浏览(20)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包