【Java】分布式管理员zookeeper,你需要好好了解一下

分布式管理员zookeeper,你需要好好了解一下

卢卡斯发布于 今天 01:48

晚上好,我是卢卡,最近半个月时间比较紧张,一个是快过年了,公司的人员评审和评定文档也比较多,二也是更新了一下自己之前的技术的简历,自从五月份入职,也满满有七个月的时间,发现很多技术学的不太扎实,比如经典的zookeeper,Apache zookeeper开源的分布式协调通知,对于电商系统,高并发,以及微服务的系统服务适用信息都比较高。重新再学习了一下,总结下自己的知识点,对知识点提炼和自己的理解很有帮助,技术人生从重学技术点开始。
【Java】分布式管理员zookeeper,你需要好好了解一下

zookeeper的定位

Zookeeper 是apache Zookeeper开源的项目,

Zookeeper的主要作用

对于微服务分布式的协调管理,元数据的管理,Master选举, 实际使用场景下,主要是三类项目

1.zookeeper的适用方向

① 后端以Java为主的电商类管理系统

Zookeeper主要作用于 分布式锁,注册中心 ,这里Zookeeper主要保持CAP理论中的CP(一致性和分区容错性),也就是说Zookeeper保证的是强一致性

②对于大数据存储,数据管理,主从数据切换等系统

这里我们熟知的Kafla,canal 等在使用Zookeeper的元数据管理 ,通过master选举出具体的主从,ZAB原子一致性协议,

③大型互联网公司,自研的分布式组件

一般以zookeeper为原型, zookeeper已经被大规模的工业级适用于主要的分布式系统,做元数据管理,以及注册中心,一般使用于 dubbo+Zookeeper 做一个基本的微服务架构来实现基本的数据调用

小总结:

zookeeper 分布式协调系统, 封装了分布式架构中所有的核心和主流的需求和功能;

分布式锁, 元数据管理, master选举, 分布式协调和通知

zookeeper的基本特性:

​ 在了解zookeeper的基本架构之前,我们来了解一下,zookeeper为什么可以实现分布式系统的协调通知, 元数据管理等;

​ 熟悉zookeeper技术栈的都比较了解,它本身是处于通知协调机制,数据同步方面有很强的处理能力,这也就是为什么很多自研的框架,底层都用zookeeper的原因,好了,废话不多说,我们开干;

背景:

集群环境下,zookeeper集群搭建了3台物理机器;

1.顺序一致性

 多个请求,不管是读取数据的,还是说写入数据的,都要按照顺序执行;

zookeeper内部要处理的请求,leader角色会给每一个请求分配一个全局唯一且自增的ZxID,用于请求数据

//这个唯一的全局ID就保证了顺序一致性

这里的zxid,先简单了解,作为一个请求的排列序号,后面会重点讲解的

2.原子性

要么全部机器都成功,要么全部机器都不成功,在同步数据操作时

//保证每次同步操作结果都是一致的

3.高可用性

集群化部署,避免宕机,

如果宕机,也可自己选举leader,重新提供服务

//从恢复模式到消息广播模式

4.数据一致性:

 集群情况下,每台机器上的数据都是一致的,但是如果说,在数据同步的时候,宕机了,

其他机器会自动将数据保存到磁盘日志中,等到leader角色提交之后,才会同步到znode节点中,真正实现数据在每台机器都是一致的

//这里说的数据一致性,是强一致性,也是zookeeper的核心的特性,根据分布式系统保持的CAP理论,只能支持CP,

//其中C-consistency ,一致性对于,数据的强一致性,p-为系统的分区容错性 A-高可用性,其eureka就是支持AP特性

5.高性能性

高性能,这里提出一个zookeeper的数据模型,znode节点

//znode节点,基于纯内存的,速度很快,树形结构,类似于Linux的文件系统,每个节点都有数据

存储的数据,已经可以处理的能力也就比较强,后面会仔细讲的,接着看下去吧

小总结:

基于zookeeper的集群架构的特点图:

【Java】分布式管理员zookeeper,你需要好好了解一下

zookeeper的集群化:

背景:

和上述的场景一致,都是3台机器,自动化部署的zookeeper集群,现在我们来具体拆分下每个机器的主要功能

Zookeeper的同步数据,是经过主leader提交commit然后同步到各个follow角色 :2PC提交事务--留个念想,后面细聊

1.Zookeeper集群化角色划分:

  • Leader(领导)

    集群启动后,根据半数选举成功的机器,成为Leader角色,支持读写,主要用于写操作,

  • Follower(候选人)

    剩余的选举不成功,为follower角色,支持读取数据和同步数据,(leader宕机,提供不了写数据操作时,其他Follower中选举出新的L earner来实现写数据的操作)

  • Observer

只是支持读取数据,不参与leader的竞争

这里面角色都是自身理解,也可以说成模式等等;

当每个角色确定功能之后,我们可以将数据直接开始同步,提供服务;

【Java】分布式管理员zookeeper,你需要好好了解一下

1.1注意事项:

​ 当一个写操作的请求直接访问follower角色的zookeeper的进程时,follower角色处理不了写操作,因为自身没有权限,只有Leader角色处理写操作的请求,这样的话,follower角色就会转发请求到Leader角色处理此请求,处理之后,开始数据同步,然后返回到其他follower角色,完成数据同步,阿虎;

2.Zookeeper集群与客户端访问的过程:

背景:

​ Zookeeper集群化,处理请求,可能来源于消息队列,或者是单独的发生请求读取数据,等等;那么每个请求到底是怎么连接到Zookeeper集群建立连接的呢,这节我们来具体聊聊?

当Zookeeper的集群环境下启动成功,然后我们开始分配角色,然后我们集群于客户端开始建立TCP的长连接,

当建立连接后,就会产生一个服务端的session ,形成一个会话的机制,相应的也会有sessionTimeout的存在

如果当前环境下,突然连接中断了,在sessionTimeout时间内连接成功不会影响此次长连接的使用;

3.Zookeeper集群化的数据一致性是怎么保证的?

背景:

​ 上述说到Zookeeper支持CAP理论中的CP ,主要是consistency,一致性; 他保证数据强一致性,就很有自己的架构特点,我们来一步步揭开Zookeeper怎么保证强一致性的面纱?

Zookeeper的强一致性是通过: ZAB(Zookeeper Atomic Broadcast) 协议: 原子广播协议

这个协议是Zookeeper的数据操作的核心,也用于元数据管理的关键;

协议来进行Zookeeper集群之间的数据同步,保证数据的强一致性;

ZAB: zookeeper Atomic broadcast 协议的思想:

划分角色: leader和follower

发送一个Proposal(提议),leader给所有的follower都同步一个proposal(提议)
如果半数以上的follower,都收到事务的proposal提议,每个follower都会返回一个ack

每个提议Pproposal ->先不会写入follower中znode数据中,而是会往一个自己本地磁盘日志文件中写入,然后返回给leader一个
ack
leader会发送一个commit提交事务

半数提交:2PC
也就是两个阶段提交;
leader如果异常宕机,会从follower中重新选举;

4.Zookeeper集群化数据同步的过程:

划分的比较细,坚持看完一定会有收获的⛽️

1⃣️当集群启动的时候,选举算法开始进行在机器中分配leader和follower角色,通过半数选举机制成功选到leader角色的机器

2⃣️剩下的当然就是follower角色的机器了,然后可以向外提供服务了

3⃣️当一个(写操作)请求经过Zookeeper集群后,leader角色机器会优先分配一个zxid用于创建节点或者变更节点的全局唯一自增ID,然后将发起一个提议Proposal(只是一个提议,相当于告诉其他人来活了,准备一下),将提议都放入,之前给每个follow角色准备好的队列中,(这里到可以保证顺序一致性)。

4⃣️每个follower角色的机器,拿到提议proposal,然后将数据放入自身的磁盘日志文件中,(不会放入znode节点),然后给leader节点回复一个ACK(确定连接成功,返回的确定字符)

ACK (Acknowledge character)即是确认字符:

//在数据通信中,接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。

在TCP/IP协议中,如果接收方成功的接收到数据,那么会回复一个ACK数据。通常ACK信号有自己固定的格式,长度大小,由接收方回复给发送方。

5⃣️当leader角色的机器,拿到半数以上的follower角色机器返回的ACK之后,代表已经准备成功,leader角色会推送一个commit消息,

其他follower就会将数据从磁盘文件写入,自身进行znode节点中存储起来,提交之后,数据同步完成,也就可以读取数据了

因为这个过程,分了两阶段提交,又称为2PC事务,用于解决分布式事务的方法

5.Znode的数据模型:

1.zookeeper的数据模型是,

基于纯内存的树形结构: Znode

 znode分类:

​ 持久节点:客户端与zk断开连接,节点依旧存在

​ 临时节点:客户端与zk断开连接,节点消失

​ 顺序节点: 对于创建节点的时候,自增加全局递增的序号;

zk中有一个基于分布式锁的要求环境,curator框架,我们开展临时节点来实现的,加锁的时候创建一个顺序节点

2.zk节点的用途

zookeeperk做元数据管理的时候: 肯定是持久节点
但是一般做分布式锁,分布式协调和通知,都是临时节点,如果断开,临时节点消失,

3 .znode的节点的组成部分:

img

6.zookeeper启动集群到数据同步过程

leader选举

集群启动,开始进行leader选举,半数机器认可当前机器作为leader,各个follower开始进行数据同步,完成就可以退出恢复模式,然后可以的对外提供服务了

宕机重新选举leader

3台机器,允许不超过一半的机器宕机

2台机器, 两个机器都同意某台机器作为leader ,这个就可以选举出leader;

1台机器是没法自己选举自己的;
因为1台机器,小于半数,所有不能启动集群环境了;

数据同步

leader选举出来后,其他机器都是follower--开始数据同步

强制剩下的follower 数据与自己leader一致;

数据同步完成之后,就会进去, 消息广播模式;

消息写入: leader写入,采用2PC模式过半写机制,给follower进行同步

将自己数据更新到,znode数据节点中

宕机修复

leader宕机,或者follower宕机,只要存活的机器超过一半,那就可以重新选举leader
选举leader,要求有一半以上的支持 ,其他跟follower数据同步,消息广播模式

zk从恢复模式到消息广播模式开始同步数据

7.谈谈在zookeeper集群下数据一致性的理解?

​ 在数据同步的过程中,leader 将提议proposal放入队列(先进先出),然后开始同步到follower,当过半的follower返回ACK(确认字符)之后,leader直接推送一个commit用于提交,follower同步数据;(这里我们注意,不是全部的follower返回结果)

zk的数据同步不是强一致性,

当follower将磁盘日志文件中的数据,提交到znode之后,数据才可以被读取到,最终数据会一致的,但是

zk官方给的一个回复是,顺序一致性,会根据zxid,以及提议proposal的顺序保证

因为leader一定会保证所有的proposal同步到follower上,是按照顺序,最终实现顺序一致性

zk也可以支持强一致行,但是需要手动调节zk的sync()操作

8.ZAB协议下,数据不一致的情况有哪些?

情况1:

当leader推送一个commit提交数据,刚自己提交了,但是他还没有吧commit提交给follower的时候,就已经挂掉了?

简介: 当客户端发送一个写操作的请求,leader已经收到半数以上follower发来的ack,他自己本地已经将数据写入znode中,leader自己commit成功,但是在没有给别的follower发出commit之前就已经挂了, 客户端在收到,leader已经commit数据之后,就默认已经将数据更新完成,但是我们新请求,查询数据follower机器的时候,发现没有,与之间leader返回的不一样;(导致了数据不一致)

这时,follower中的数据和刚刚宕机的leader机器上的数据肯定是不一致的,接下来zk会怎么做呢?

在具体的时间中,zk集群中的follower角色发现,老大leader无法回复,处于失联,宕机状态,他们就说我们再选一个leader,然后就再重新选一个leader01(新的),那之前已经挂掉的leader,就顺势变成了follower,

情况2:

如果客户端在,请求写数据操作的leader机器上,然后leader,发送一个proposal提议,但是还没发出去,就挂了;

导致本地磁盘日志文件中存在一个proposal;但是其他的follower中没有这个数据;

当集群奔溃之后,开展恢复模式,ZAB协议的关键核心就显示出来了,根据

情况1的解决思路:

众多的follower,开始半数选举机制,选出新的leader之后,发现本地磁盘上有没有提交的proposal,然后查看别的follower也存在这样 的情况,这里的新leader(是之前未接收到commit消息的follower),然后我们开始发送commit 给其他follower,将数据写入znode节点中 解决客户端读取数据不一致的情况;

情况2的解决过程:

根据上述的情况,已经宕机的leader存在一个proposal的提议,但是其他的follow没有收到,所以在恢复模式之后,新的leader被选择出来,开展写操作,但是发优先去查询一下本地磁盘中是否有之前遗留的proposal提议,查询到一个follower(之前宕机的发送的一个proposal的leader)磁盘数据与其他的不一致,然后现在的新leader将会同步数据给其他的follower,之前宕机的leader存在一个的提议(proposal提议)会被舍弃掉;

9.奔溃恢复时选举出来的新leader如何跟其他follower进行同步数据的过程

我们还是来模拟一个场景,5台机器的zookeeper集群化部署

其中四台是follower角色用于读取数据和同步数据的,剩下的一台就是leader专门进行写操作的机器

背景:

​ 当一个leader发出一个proposal提议后,其他三台的follower机器都收到了,唯独剩下的一个没收到proposal,但是现在已经有三台j follower机器已经返回了ack的确认字符, 所以leader判断已经都通知成功,(半数选举),然后自身开始commit,没等到给剩下的follower 角色进行提交就宕机了;

分析一下:

​ 目前leader已经commit数据到自己的znode节点上了,但是已经挂了,但是其他四台follow机器,三台已经将proposal放到自己本地的磁盘日志文件中,剩余一台啥都没有(之前半数返回ack已经够了没有收到proposal提议),万一其他三台机器恢复机制时,都选举最后一台机器,作为新的leader,那这条数据就永久丢失了,

先告诉大家一个答案,就是这中事情不会发生,zookeeper集群不会选择一个没有数据的角色选举成leader

主要是要了解一个zxid的概念:

Zxid: 可以理解为一个事物的自增ID,要是对提议改变了,他就自增,

要是这个follow没有收到提议,也就zxid相应的比收到返回ack的follower 节点的机器肯定是大的;

选举leader的要求是,在follower中,收到事务zxid最大的,也就是相当于创建时间最早的,作为新的leader

10.zxid

  • znode节点的状态信息中包含czxid, 那么什么是zxid呢?
  • ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生.
  • 创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加.

​ ZooKeeper中ZXID是一个长度64位的数字,其中低32位是按照数字递增,即每次客户端发起一个proposal,低32位的数字简单加1。高32位是leader周期的epoch编号。也就是leader的一个版本号

比如说后面epoch编号为8, 也就说当前的leader版本是8 ,挂掉之后重新选举就自增1,epoch的编号就是9

所以睡要是想之前的情况2,发生就知道是为什么会出来丢掉的数据,因为会找leader的epocn最大的一个版本作为可以提交的领导者

重新发号命令;

11.Observer节点(角色)的作用:

需要配置文件,只会单纯的接受和同步数据,observer不会参与过半写机制,不参与选举

只是被动的接受数据,

如果读的请求需求很大,我们可以添加几个Observer,

优点:

  • ​ 可一扛下很大的并发量,
  • ​ 不会影响过半写的机制,
  • ​ 不会特别影响性能

原因:

要是都是follower节点的话,当leader要发proposal提议,要等待过半的机器返回ack,然后同步数据,也是过半的,

选举的时候也是过半的,这样会很耗费时间以及网络资源,但是只要读取的数据,不参与选举的observer就很大程度上解决了这个痛点

12.zookeeper适用于实际部署场景:

​ 适用于小集群的部署,读多写少的场景;

奇数台机器,半数选举,

过半写+磁盘日志文件====》commit+znode 节点

主要是写入压力过大leader

java集群zookeeper分布式系统

阅读 31发布于 今天 01:48

本作品系原创,采用《署名-非商业性使用-禁止演绎 4.0 国际》许可协议

avatar

卢卡斯

csdn:https://me.csdn.net/qq_42419126

1 声望

0 粉丝

0 条评论

得票时间

avatar

卢卡斯

csdn:https://me.csdn.net/qq_42419126

1 声望

0 粉丝

宣传栏

晚上好,我是卢卡,最近半个月时间比较紧张,一个是快过年了,公司的人员评审和评定文档也比较多,二也是更新了一下自己之前的技术的简历,自从五月份入职,也满满有七个月的时间,发现很多技术学的不太扎实,比如经典的zookeeper,Apache zookeeper开源的分布式协调通知,对于电商系统,高并发,以及微服务的系统服务适用信息都比较高。重新再学习了一下,总结下自己的知识点,对知识点提炼和自己的理解很有帮助,技术人生从重学技术点开始。
【Java】分布式管理员zookeeper,你需要好好了解一下

zookeeper的定位

Zookeeper 是apache Zookeeper开源的项目,

Zookeeper的主要作用

对于微服务分布式的协调管理,元数据的管理,Master选举, 实际使用场景下,主要是三类项目

1.zookeeper的适用方向

① 后端以Java为主的电商类管理系统

Zookeeper主要作用于 分布式锁,注册中心 ,这里Zookeeper主要保持CAP理论中的CP(一致性和分区容错性),也就是说Zookeeper保证的是强一致性

②对于大数据存储,数据管理,主从数据切换等系统

这里我们熟知的Kafla,canal 等在使用Zookeeper的元数据管理 ,通过master选举出具体的主从,ZAB原子一致性协议,

③大型互联网公司,自研的分布式组件

一般以zookeeper为原型, zookeeper已经被大规模的工业级适用于主要的分布式系统,做元数据管理,以及注册中心,一般使用于 dubbo+Zookeeper 做一个基本的微服务架构来实现基本的数据调用

小总结:

zookeeper 分布式协调系统, 封装了分布式架构中所有的核心和主流的需求和功能;

分布式锁, 元数据管理, master选举, 分布式协调和通知

zookeeper的基本特性:

​ 在了解zookeeper的基本架构之前,我们来了解一下,zookeeper为什么可以实现分布式系统的协调通知, 元数据管理等;

​ 熟悉zookeeper技术栈的都比较了解,它本身是处于通知协调机制,数据同步方面有很强的处理能力,这也就是为什么很多自研的框架,底层都用zookeeper的原因,好了,废话不多说,我们开干;

背景:

集群环境下,zookeeper集群搭建了3台物理机器;

1.顺序一致性

 多个请求,不管是读取数据的,还是说写入数据的,都要按照顺序执行;

zookeeper内部要处理的请求,leader角色会给每一个请求分配一个全局唯一且自增的ZxID,用于请求数据

//这个唯一的全局ID就保证了顺序一致性

这里的zxid,先简单了解,作为一个请求的排列序号,后面会重点讲解的

2.原子性

要么全部机器都成功,要么全部机器都不成功,在同步数据操作时

//保证每次同步操作结果都是一致的

3.高可用性

集群化部署,避免宕机,

如果宕机,也可自己选举leader,重新提供服务

//从恢复模式到消息广播模式

4.数据一致性:

 集群情况下,每台机器上的数据都是一致的,但是如果说,在数据同步的时候,宕机了,

其他机器会自动将数据保存到磁盘日志中,等到leader角色提交之后,才会同步到znode节点中,真正实现数据在每台机器都是一致的

//这里说的数据一致性,是强一致性,也是zookeeper的核心的特性,根据分布式系统保持的CAP理论,只能支持CP,

//其中C-consistency ,一致性对于,数据的强一致性,p-为系统的分区容错性 A-高可用性,其eureka就是支持AP特性

5.高性能性

高性能,这里提出一个zookeeper的数据模型,znode节点

//znode节点,基于纯内存的,速度很快,树形结构,类似于Linux的文件系统,每个节点都有数据

存储的数据,已经可以处理的能力也就比较强,后面会仔细讲的,接着看下去吧

小总结:

基于zookeeper的集群架构的特点图:

【Java】分布式管理员zookeeper,你需要好好了解一下

zookeeper的集群化:

背景:

和上述的场景一致,都是3台机器,自动化部署的zookeeper集群,现在我们来具体拆分下每个机器的主要功能

Zookeeper的同步数据,是经过主leader提交commit然后同步到各个follow角色 :2PC提交事务--留个念想,后面细聊

1.Zookeeper集群化角色划分:

  • Leader(领导)

    集群启动后,根据半数选举成功的机器,成为Leader角色,支持读写,主要用于写操作,

  • Follower(候选人)

    剩余的选举不成功,为follower角色,支持读取数据和同步数据,(leader宕机,提供不了写数据操作时,其他Follower中选举出新的L earner来实现写数据的操作)

  • Observer

只是支持读取数据,不参与leader的竞争

这里面角色都是自身理解,也可以说成模式等等;

当每个角色确定功能之后,我们可以将数据直接开始同步,提供服务;

【Java】分布式管理员zookeeper,你需要好好了解一下

1.1注意事项:

​ 当一个写操作的请求直接访问follower角色的zookeeper的进程时,follower角色处理不了写操作,因为自身没有权限,只有Leader角色处理写操作的请求,这样的话,follower角色就会转发请求到Leader角色处理此请求,处理之后,开始数据同步,然后返回到其他follower角色,完成数据同步,阿虎;

2.Zookeeper集群与客户端访问的过程:

背景:

​ Zookeeper集群化,处理请求,可能来源于消息队列,或者是单独的发生请求读取数据,等等;那么每个请求到底是怎么连接到Zookeeper集群建立连接的呢,这节我们来具体聊聊?

当Zookeeper的集群环境下启动成功,然后我们开始分配角色,然后我们集群于客户端开始建立TCP的长连接,

当建立连接后,就会产生一个服务端的session ,形成一个会话的机制,相应的也会有sessionTimeout的存在

如果当前环境下,突然连接中断了,在sessionTimeout时间内连接成功不会影响此次长连接的使用;

3.Zookeeper集群化的数据一致性是怎么保证的?

背景:

​ 上述说到Zookeeper支持CAP理论中的CP ,主要是consistency,一致性; 他保证数据强一致性,就很有自己的架构特点,我们来一步步揭开Zookeeper怎么保证强一致性的面纱?

Zookeeper的强一致性是通过: ZAB(Zookeeper Atomic Broadcast) 协议: 原子广播协议

这个协议是Zookeeper的数据操作的核心,也用于元数据管理的关键;

协议来进行Zookeeper集群之间的数据同步,保证数据的强一致性;

ZAB: zookeeper Atomic broadcast 协议的思想:

划分角色: leader和follower

发送一个Proposal(提议),leader给所有的follower都同步一个proposal(提议)
如果半数以上的follower,都收到事务的proposal提议,每个follower都会返回一个ack

每个提议Pproposal ->先不会写入follower中znode数据中,而是会往一个自己本地磁盘日志文件中写入,然后返回给leader一个
ack
leader会发送一个commit提交事务

半数提交:2PC
也就是两个阶段提交;
leader如果异常宕机,会从follower中重新选举;

4.Zookeeper集群化数据同步的过程:

划分的比较细,坚持看完一定会有收获的⛽️

1⃣️当集群启动的时候,选举算法开始进行在机器中分配leader和follower角色,通过半数选举机制成功选到leader角色的机器

2⃣️剩下的当然就是follower角色的机器了,然后可以向外提供服务了

3⃣️当一个(写操作)请求经过Zookeeper集群后,leader角色机器会优先分配一个zxid用于创建节点或者变更节点的全局唯一自增ID,然后将发起一个提议Proposal(只是一个提议,相当于告诉其他人来活了,准备一下),将提议都放入,之前给每个follow角色准备好的队列中,(这里到可以保证顺序一致性)。

4⃣️每个follower角色的机器,拿到提议proposal,然后将数据放入自身的磁盘日志文件中,(不会放入znode节点),然后给leader节点回复一个ACK(确定连接成功,返回的确定字符)

ACK (Acknowledge character)即是确认字符:

//在数据通信中,接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。

在TCP/IP协议中,如果接收方成功的接收到数据,那么会回复一个ACK数据。通常ACK信号有自己固定的格式,长度大小,由接收方回复给发送方。

5⃣️当leader角色的机器,拿到半数以上的follower角色机器返回的ACK之后,代表已经准备成功,leader角色会推送一个commit消息,

其他follower就会将数据从磁盘文件写入,自身进行znode节点中存储起来,提交之后,数据同步完成,也就可以读取数据了

因为这个过程,分了两阶段提交,又称为2PC事务,用于解决分布式事务的方法

5.Znode的数据模型:

1.zookeeper的数据模型是,

基于纯内存的树形结构: Znode

 znode分类:

​ 持久节点:客户端与zk断开连接,节点依旧存在

​ 临时节点:客户端与zk断开连接,节点消失

​ 顺序节点: 对于创建节点的时候,自增加全局递增的序号;

zk中有一个基于分布式锁的要求环境,curator框架,我们开展临时节点来实现的,加锁的时候创建一个顺序节点

2.zk节点的用途

zookeeperk做元数据管理的时候: 肯定是持久节点
但是一般做分布式锁,分布式协调和通知,都是临时节点,如果断开,临时节点消失,

3 .znode的节点的组成部分:

img

6.zookeeper启动集群到数据同步过程

leader选举

集群启动,开始进行leader选举,半数机器认可当前机器作为leader,各个follower开始进行数据同步,完成就可以退出恢复模式,然后可以的对外提供服务了

宕机重新选举leader

3台机器,允许不超过一半的机器宕机

2台机器, 两个机器都同意某台机器作为leader ,这个就可以选举出leader;

1台机器是没法自己选举自己的;
因为1台机器,小于半数,所有不能启动集群环境了;

数据同步

leader选举出来后,其他机器都是follower--开始数据同步

强制剩下的follower 数据与自己leader一致;

数据同步完成之后,就会进去, 消息广播模式;

消息写入: leader写入,采用2PC模式过半写机制,给follower进行同步

将自己数据更新到,znode数据节点中

宕机修复

leader宕机,或者follower宕机,只要存活的机器超过一半,那就可以重新选举leader
选举leader,要求有一半以上的支持 ,其他跟follower数据同步,消息广播模式

zk从恢复模式到消息广播模式开始同步数据

7.谈谈在zookeeper集群下数据一致性的理解?

​ 在数据同步的过程中,leader 将提议proposal放入队列(先进先出),然后开始同步到follower,当过半的follower返回ACK(确认字符)之后,leader直接推送一个commit用于提交,follower同步数据;(这里我们注意,不是全部的follower返回结果)

zk的数据同步不是强一致性,

当follower将磁盘日志文件中的数据,提交到znode之后,数据才可以被读取到,最终数据会一致的,但是

zk官方给的一个回复是,顺序一致性,会根据zxid,以及提议proposal的顺序保证

因为leader一定会保证所有的proposal同步到follower上,是按照顺序,最终实现顺序一致性

zk也可以支持强一致行,但是需要手动调节zk的sync()操作

8.ZAB协议下,数据不一致的情况有哪些?

情况1:

当leader推送一个commit提交数据,刚自己提交了,但是他还没有吧commit提交给follower的时候,就已经挂掉了?

简介: 当客户端发送一个写操作的请求,leader已经收到半数以上follower发来的ack,他自己本地已经将数据写入znode中,leader自己commit成功,但是在没有给别的follower发出commit之前就已经挂了, 客户端在收到,leader已经commit数据之后,就默认已经将数据更新完成,但是我们新请求,查询数据follower机器的时候,发现没有,与之间leader返回的不一样;(导致了数据不一致)

这时,follower中的数据和刚刚宕机的leader机器上的数据肯定是不一致的,接下来zk会怎么做呢?

在具体的时间中,zk集群中的follower角色发现,老大leader无法回复,处于失联,宕机状态,他们就说我们再选一个leader,然后就再重新选一个leader01(新的),那之前已经挂掉的leader,就顺势变成了follower,

情况2:

如果客户端在,请求写数据操作的leader机器上,然后leader,发送一个proposal提议,但是还没发出去,就挂了;

导致本地磁盘日志文件中存在一个proposal;但是其他的follower中没有这个数据;

当集群奔溃之后,开展恢复模式,ZAB协议的关键核心就显示出来了,根据

情况1的解决思路:

众多的follower,开始半数选举机制,选出新的leader之后,发现本地磁盘上有没有提交的proposal,然后查看别的follower也存在这样 的情况,这里的新leader(是之前未接收到commit消息的follower),然后我们开始发送commit 给其他follower,将数据写入znode节点中 解决客户端读取数据不一致的情况;

情况2的解决过程:

根据上述的情况,已经宕机的leader存在一个proposal的提议,但是其他的follow没有收到,所以在恢复模式之后,新的leader被选择出来,开展写操作,但是发优先去查询一下本地磁盘中是否有之前遗留的proposal提议,查询到一个follower(之前宕机的发送的一个proposal的leader)磁盘数据与其他的不一致,然后现在的新leader将会同步数据给其他的follower,之前宕机的leader存在一个的提议(proposal提议)会被舍弃掉;

9.奔溃恢复时选举出来的新leader如何跟其他follower进行同步数据的过程

我们还是来模拟一个场景,5台机器的zookeeper集群化部署

其中四台是follower角色用于读取数据和同步数据的,剩下的一台就是leader专门进行写操作的机器

背景:

​ 当一个leader发出一个proposal提议后,其他三台的follower机器都收到了,唯独剩下的一个没收到proposal,但是现在已经有三台j follower机器已经返回了ack的确认字符, 所以leader判断已经都通知成功,(半数选举),然后自身开始commit,没等到给剩下的follower 角色进行提交就宕机了;

分析一下:

​ 目前leader已经commit数据到自己的znode节点上了,但是已经挂了,但是其他四台follow机器,三台已经将proposal放到自己本地的磁盘日志文件中,剩余一台啥都没有(之前半数返回ack已经够了没有收到proposal提议),万一其他三台机器恢复机制时,都选举最后一台机器,作为新的leader,那这条数据就永久丢失了,

先告诉大家一个答案,就是这中事情不会发生,zookeeper集群不会选择一个没有数据的角色选举成leader

主要是要了解一个zxid的概念:

Zxid: 可以理解为一个事物的自增ID,要是对提议改变了,他就自增,

要是这个follow没有收到提议,也就zxid相应的比收到返回ack的follower 节点的机器肯定是大的;

选举leader的要求是,在follower中,收到事务zxid最大的,也就是相当于创建时间最早的,作为新的leader

10.zxid

  • znode节点的状态信息中包含czxid, 那么什么是zxid呢?
  • ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生.
  • 创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加.

​ ZooKeeper中ZXID是一个长度64位的数字,其中低32位是按照数字递增,即每次客户端发起一个proposal,低32位的数字简单加1。高32位是leader周期的epoch编号。也就是leader的一个版本号

比如说后面epoch编号为8, 也就说当前的leader版本是8 ,挂掉之后重新选举就自增1,epoch的编号就是9

所以睡要是想之前的情况2,发生就知道是为什么会出来丢掉的数据,因为会找leader的epocn最大的一个版本作为可以提交的领导者

重新发号命令;

11.Observer节点(角色)的作用:

需要配置文件,只会单纯的接受和同步数据,observer不会参与过半写机制,不参与选举

只是被动的接受数据,

如果读的请求需求很大,我们可以添加几个Observer,

优点:

  • ​ 可一扛下很大的并发量,
  • ​ 不会影响过半写的机制,
  • ​ 不会特别影响性能

原因:

要是都是follower节点的话,当leader要发proposal提议,要等待过半的机器返回ack,然后同步数据,也是过半的,

选举的时候也是过半的,这样会很耗费时间以及网络资源,但是只要读取的数据,不参与选举的observer就很大程度上解决了这个痛点

12.zookeeper适用于实际部署场景:

​ 适用于小集群的部署,读多写少的场景;

奇数台机器,半数选举,

过半写+磁盘日志文件====》commit+znode 节点

主要是写入压力过大leader

以上是 【Java】分布式管理员zookeeper,你需要好好了解一下 的全部内容, 来源链接: utcz.com/a/111393.html

回到顶部