【Zookeeper 】- ZAB协议 - 有主写

【Zookeeper 】- ZAB协议 - 有主写_第1张图片

文章目录

    • 前置知识点
    • 二阶段提交
      • 二阶段提交执行流程
    • ZAB协议

前置知识点

在开始ZAB协议之前先跟兄弟们一起回顾一些知识点

协调者(Leader):主节点

参与者(Follower):从节点

【Zookeeper 】- ZAB协议 - 有主写_第2张图片

二阶段提交

2PC,是Two-Phase Commit的缩写,即二阶段提交,是计算机网络尤其是在数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性一致性而设计的一种算法。通常,二阶段提交协议也被认为是一种一致性协议,用来保证分布式系统数据的一致性。目前,绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的,利用该协议能够非常方便地完成所有分布式事务参与者协调统一决定事务的提交回滚,从而能够有效地保证分布式数据一致性,因此二阶段提交协议被广泛地应用在许多分布式系统中。

二阶段提交执行流程

一阶段:提交事务请求

1、事务询问

协调者所有参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各参与者的响应

2、执行事务

参与者节点执行事务操作,并将UndoRedo信息记入事务日志中。

3、参与者向协调者反馈

如果各参与者成功执行了事务操作,那么就反馈给协调者Yes响应,表示事务可以执行;如果参与者没有成功执行事务,那么就反馈给协调者No响应,表示事务不可以执行。

二阶段:执行事务提交

事务提交

协调者接收到所有参与者的ACK消息都是YES,执行事务提交

  • 1、发送提交申请

    协调者参与者发出Commit请求

  • 2、事务提交

    参与者收到Commit请求后,执行事务提交,完成后释放整个事务执行期间占用的事务资源

  • 3、反馈结果

    参与者在完成事务提交后,给协调者发送ACK消息

  • 4、事务完成

    协调者接收到所有参与者反馈的ACK消息后,事务完成

如图:

一阶段:

【Zookeeper 】- ZAB协议 - 有主写_第3张图片

二阶段

【Zookeeper 】- ZAB协议 - 有主写_第4张图片

事务中断

任何一个参与者反馈了NO,或者等待超时了导致协调者没有接收到所有参与者的反馈就会中断事务

  • 1、发送回滚请求

    协调者所有参与者发送Rollback请求

  • 2、事务回滚

    参与者接收到Rollback请求后,会根据一阶段中的Undo日志进行事务回滚,

  • 3、事务回滚结果反馈

    参与者在完成回滚后,向协调者发送ACK消息

  • 4、中断事务

    协调者接收到所有参与者反馈的ACK消息后完成事务中断

如图:

一阶段

【Zookeeper 】- ZAB协议 - 有主写_第5张图片

二阶段

【Zookeeper 】- ZAB协议 - 有主写_第6张图片

【Zookeeper 】- ZAB协议 - 有主写_第7张图片

ZAB协议

Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性

ZAB又名原子广播协议(Zookeeper Atomic Broadcast ) 作用在可用状态有Leader

  • 原子:要么成功,要么失败,没有中间状态(FIFO队列+类似2PC操作)

  • 广播:分布式多节点的,所以执行操作都是由Leader(协调者)向所有Follower(参与者)统一发送请求

PS:

  • ZK的数据状态存储在内存

  • ZK是日志存储在磁盘

一主两从环境下写操作为例展开讨论
如图(由于要连很多线条,所以没有用类似上方两阶段提交中的上下结构布局):【Zookeeper 】- ZAB协议 - 有主写_第8张图片

  • 第一步:在ZK客户端对任意一个Follower节点执行一个写操作create /rhys "aaa"

  • 第二步:Follower节点将这笔写操作转发给Leader节点

  • 第三步:Leader会创建一个事务ID(zxid),假设本次给出的事务ID为1

  • 第四步:其实在Leader对于每个Follower都维护着一个发送队列(FIFO队列),紧接着Leader会给两台Follower发起关于创建XXX节点这件事第一阶段操作写日志,那么这个写日志操作就会先入发送队列。再顺序执行队列中操作,当写日志操作执行成功后,Follower会返回一个ok/yes的状态,那对应的Leader中也会生成一个ok/yes的状态,由于我们是一主两从,那有了两台机返回了ok状态,满足了过半通过条件 (3/2+1),这时Leader会再次对两台Follower发起第二阶段write写内存操作,其实就是类似两阶段提交(2PC),只是这里的两阶段提交开始回顾的两阶段提交不一样的地方时没有中断事务操作,因为这里的两阶段提交不需要接收到所有Follower(参与者)的ACK反馈,只需要超过一半的机器ACK就可以了,依然是入发送队列,然后从队列中顺序执行操作,操作完成同样的会返回一个ok/yes状态,达到过半条件则Leader会给Follower返回一个over-ok状态,再由Follower传递给客户端

兄弟这边有一点需要提一下,我们刚提到过半提交这个概念对吧,那另一台Follower机器没有返回ok状态,对应的发送队列依旧会放入一个write操作,只要最终那台没有返回okFollower机器能把队列中操作消费完,那这个节点的数据最终还是会跟其他两个节点保持一致的,这边就体现出了最终一致性

  • 总结:回过头再看ZAB的原子没有中间状态其实就是依据FIFO队列+类似2PC操作,广播其实就是体现了过半通过的概念

【Zookeeper 】- ZAB协议 - 有主写_第9张图片

你可能感兴趣的:(Zookeeper,zookeeper,java,架构,中间件)