分布式与一致性协议之ZAB协议(二)

文章详细阐述了ZAB协议如何通过主备模式、事务标识符和提案机制确保操作的顺序性,包括提案创建、广播、确认及提交过程。同时介绍了ZooKeeper的最终一致性和sync命令用于获取最新数据的机制。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

ZAB协议

ZAB协议是如何实现操作地顺序性的?

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

如果用一句话解释ZAB协议到底是什么,我觉得它是能保证操作顺序性的、基于主备模式的原子广播协议。
接下来,还是以指令X、Y为例具体演示一下,帮助你更好地理解为什么ZAB协议能实现操作的顺序性(为了演示,我们假设节点A为主节点,节点B、C为备份节点)。
首先,在ZAB协议中,写操作必须在主节点(比如节点A)上执行。如果客户端访问的节点是备份节点(比如节点B),则备份节点会将写请求转发给主节点,如图所示。
接着,当主节点接收到写请求后,它会基于写请求中的指令(也就是X、Y)来创建一个提案(Proposal),并使用一个唯一的ID来标识这个提案。这里我说的唯一ID就是事务标识符(TransactionID,也就是zxid),如图所示
从图中可以看到,指令X、Y对应的事务标识符分别为<1,1>和<1,2>。这两个标识符是什么含义呢?
你可以这么理解,事务标识符是64位的long型变量,由任期编号epoch和计数器counter两部分组成(为了形象和方便理解,我把epoch翻译城任期编号),格式为<epoch,counter>,其中,高32位位任期编号,低32位为计数器。

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

coffee_babe

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值