分布式协议与算法实战
韩健
腾讯资深工程师
23193 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 31 讲
分布式协议与算法实战
15
15
1.0x
00:00/00:00
登录|注册

15 | ZAB协议:如何实现操作的顺序性?

处理主节点崩溃的情况
如果ZAB采用UDP协议,能保证消息接收的顺序性吗?
保证操作的顺序性
主节点按顺序提交提案
主节点创建提案并广播到其他节点
写操作必须在主节点上执行
基于主备模式的原子广播协议
Multi-Paxos不关心各值的顺序
兰伯特的Multi-Paxos只考虑了如何实现共识
下节课内容
课堂思考
ZAB是如何实现操作的顺序性的?
为什么Multi-Paxos无法保证操作顺序性?
ZAB协议

该思维导图由 AI 生成,仅供参考

你好,我是韩健。
很多同学应该使用过 ZooKeeper,它是一个开源的分布式协调服务,比如你可以用它进行配置管理、名字服务等等。在 ZooKeeper 中,数据是以节点的形式存储的。如果你要用 ZooKeeper 做配置管理,那么就需要在里面创建指定配置,假设创建节点"/geekbang"和"/geekbang/time",步骤如下:
[zk: 192.168.0.10:2181(CONNECTED) 0] create /geekbang 123
Created /geekbang
[zk: 192.168.0.10:2181(CONNECTED) 1] create /geekbang/time 456
Created /geekbang/time
我们分别创建了配置"/geekbang"和"/geekbang/time",对应的值分别为 123 和 456。那么在这里我提个问题:你觉得在 ZooKeeper 中,能用兰伯特的 Multi-Paxos 实现各节点数据的共识和一致吗?
当然不行。因为兰伯特的 Multi-Paxos,虽然能保证达成共识后的值不再改变,但它不关心达成共识的值是什么,也无法保证各值(也就是操作)的顺序性。而这就是 Zookeeper 没有采用 Multi-Paxos 的原因,又是 ZAB 协议着力解决的,也是你理解 ZAB 协议的关键。
那么为了帮你更好地理解这个协议,接下来,我将分别以如何实现操作的顺序性、领导者选举、故障恢复、处理读写请求为例,具体讲解一下。希望你能在全面理解 ZAB 协议的同时,加深对 Paxos 算法的理解。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

ZAB协议是ZooKeeper中实现操作顺序性的关键,通过基于主备模式的原子广播协议,解决了Multi-Paxos无法保证操作顺序性的问题。文章通过具体例子演示了Multi-Paxos的局限性,指出其无法保证操作顺序性,因为它不关心达成共识的值是什么,也无法保证各值的顺序性。ZooKeeper之所以没有采用Raft,是因为当时还没有Raft。文章围绕ZAB协议的实现原理展开,帮助读者理解了ZooKeeper中操作顺序性的重要性以及ZAB协议的作用。ZAB协议通过强领导者模型和严格按照顺序处理、提交提案,实现了操作的顺序性。它基于TCP协议广播消息,保证了消息接收的顺序性。此外,文章还提到了ZAB协议中主节点的重要性以及对主节点崩溃的处理。总的来说,本文深入浅出地介绍了ZAB协议的实现原理和作用,对于理解分布式系统中操作顺序性的重要性以及ZAB协议的技术特点具有很好的指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式协议与算法实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(36)

  • 最新
  • 精选
  • Jialin
    如果 ZAB 采用的是 UDP 协议,无法保证消息接收的顺序性,主要是因为 TCP 协议本身支持按序确认,而 UCP 只能支持尽最大可能交付

    作者回复: 加一颗星:)

    2020-04-27
    5
    33
  • 竹马彦四郎的好朋友影法師
    本质上讲,zab和raft都是通过强领导者模型实现就多值达成共识的

    作者回复: 加一颗星:)

    2020-05-06
    9
  • z
    "首先,需要你注意的是,在 ZAB 中,写操作必须在主节点(比如节点 A)上执行。如果客户端访问的节点是备份节点(比如节点 B),它会将写请求转发给主节点" 关于这一点写请求会转发到主节点, 如果客户端把X,Y发往了两个不同的备份节点,这时候主节点拿到X,Y的顺序是不是没办法保证? 那最终执行的顺序还是没法保证呀

    作者回复: 加一颗星:),存在这样的情况,但这不是问题,因为在实际场景中,如果我们想实现X、Y的顺序性,那么客户端可以连接一个节点,而不是多个节点,执行写操作。

    2020-06-22
    5
    8
  • 竹马彦四郎的好朋友影法師
    怎么感觉zab和raft如果刨去leader选举之外就一模一样了,希望老师解惑,谢谢!

    作者回复: 加一颗星:),在接下来的加餐中,我会补充个对比总结。

    2020-05-06
    2
    6
  • 海连天
    感觉过程像极了两阶段提交

    作者回复: 加一颗星:),可以对比着理解,理解为简化版的二阶段提交,基于“大多数”确认来提交。

    2020-05-03
    4
  • ezekiel
    老师您好 我有两个疑问 图 2、3、4中尚无提案准备,是Mutli-paxos中的步骤吗?我理解领导者直接进入第二阶段赋值,是否正确? 图2中接受者已经赋值,后来领导者C执行Basic Paxos中准备阶段,将其修改。不是一旦赋值后就不能修改了吗?

    作者回复: 加一颗星:),1. 准备阶段是可以省略的,属于优化,但是否省略,对最终结果都没有影响,为了理解方便,演示时,就没有省略。2. 不是赋值不能修改,而是算法保证被“大多数”节点接受的值就不再改变。

    2020-10-31
    3
  • piboye
    multipaxos假设就是不相关的吧,相关的数据,应该用paxos来决议log,这样就一致了。fast paxos也可以一次rpc一个提交,不过效率应该不如raft流模式。 zab比raft和paxos没有优势了吧?

    作者回复: 加一颗星:),ZAB比paxos实现(chubby)新,比Raft旧,相比Raft,ZAB没有优势,究其原因,技术是不断继承,和发展的。

    2020-09-17
    2
  • Gavin
    在创建完提案之后,主节点会基于 TCP 协议,并按照顺序将提案广播到其他节点。这样就能保证先发送的消息,会先被收到,保证了消息接收的顺序性。 请问下,tcp协议有可能先发的消息后收到吧?

    作者回复: 加一颗星:),不会的,TCP基于seq序号实现了TCP重组,能保证数据被严格按照顺序接收到。

    2020-08-07
    2
  • nomoshen
    第一个阶段提议ok之后,第二个committed阶段主节点挂了,那么在选举的时候这写未提交的提议咋处理?主节点反馈给客户端是否要直到comitted绝大多数才算OK

    作者回复: 加一颗星:),问题1:因为提案已复制到大多数节点上,领导者选举能保证新的领导者一定包含这个未提交的提案,并最终将它提交。 问题2:不一定是主节点,也不需要等到committed绝大多数,具体来说,当节点接收到COMMIT消息后,提交提案,如果是自己接收的写请求,那么这时返回成功响应给客户端。

    2020-06-04
    2
    2
  • 明翼
    我看很多朋友回复是通过tcp来控制顺序,我不认为这样,tcp发送如果中间过程路由发生了变化,仍然会导致后发的消息先到;udp当然更不行了。。后来我看一篇文章说leader为每个flow生成一个先进先出的队列,如果flow去主动取数据的话这个顺序是可以保障的

    作者回复: 加一颗星:),TCP是能保证消息的顺序的,乱序的数据包会基于seq,进行乱序重组。

    2020-09-25
    2
收起评论
显示
设置
留言
36
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部