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

加餐 | ZAB协议(三):如何处理读写请求?

课堂思考
内容小结
处理读操作
处理写操作
ZooKeeper处理读写请求的原理

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

你好,我是韩健!
你应该有这样的体会,如果你想了解一个网络服务,执行的第一个功能肯定是写操作,然后才执行读操作。比如,你要了解 ZooKeeper,那么肯定会在 zkCli.sh 命令行中执行写操作(比如“create /geekbang 123”)写入数据,然后再是读操作(比如“get /geekbang”)查询数据。这样一来,你才会直观地理解 ZooKeeper 是如何使用的了。
在我看来,任何网络服务最重要的功能就是处理读写请求,因为我们访问网络服务本质上都是在执行读写操作,ZooKeeper 也不例外。而且对 ZooKeeper 而言,这些功能更为重要,因为在 ZooKeeper 中,如何处理写请求,关乎着操作的顺序性,而操作的顺序性会影响节点的创建;如何处理读请求,关乎着一致性,它们又影响着客户端是否会读到旧数据。
接下来,我会从 ZooKeeper 系统的角度,全面地分析整个读写请求的流程,帮助你更加全面、透彻地理解读写请求背后的原理。
你肯定知道,在 ZooKeeper 中,写请求是必须在领导者上处理,如果跟随者接收到了写请求,它需要将写请求转发给领导者,当写请求对应的提案被复制到大多数节点上时,领导者会提交提案,并通知跟随者提交提案。而读请求可以在任何节点上处理,也就是说,ZooKeeper 实现的是最终一致性。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

ZooKeeper中的ZAB协议是处理读写请求的核心机制。文章全面分析了读写请求的流程,强调了理解ZooKeeper性能和一致性的重要性。在ZooKeeper中,写请求必须在领导者上处理,而读请求可以在任何节点上处理,实现了最终一致性。文章详细介绍了ZooKeeper代码中如何实现读写操作的过程,包括处理写请求的核心流程和处理读请求的实现。通过分析ZooKeeper代码,读者可以深入了解ZooKeeper处理读写请求的原理和代码实现。此外,文章还补充了ZAB协议的术语和与Raft算法的对比,以及对ZooKeeper提供的最终一致性进行了思考。整体而言,本文对于想深入了解ZooKeeper读写请求处理机制的读者具有很高的参考价值。

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

全部留言(17)

  • 最新
  • 精选
  • zyz
    Zookeeper通过Leader来主导写操作,保证了顺序一致性。当一半以上的节点返回已写入,就返回客户端已写入,但是这时候只是部分节点写入,有的节点可能还没有同步上数据,所以读取备份节点可能不是最新的。同时Zookeeper的单一视图特征,保证客户端看到的数据不会比在之前服务器上所看到的更老。

    作者回复: 加一颗星:)

    2020-05-21
    5
    9
  • zyz
    老师!Zookeeper版本3.5.0开始支持dynamic configuration,成员变更的时候,不需要重启了吧

    作者回复: 加一颗星:),感谢反馈,采用dynamic configuration进行成员变更,不需要重启的,已修正。

    2020-05-20
    5
  • xzy
    你好,既然 zk 只能保证最终一致性,那么在分布式系统中,如 kafka、hbase 等,用 zk 做元数据管理岂不是有问题

    作者回复: 加一颗星:),绝大多数时候,业务对数据的新旧是没那么敏感的。

    2020-05-26
    2
    2
  • Dovelol
    老师好,想问下zab协议处理写请求要这么多步骤,那还能保证性能吗?如果其中某一小步骤延迟或阻塞都会影响写的性能把。

    作者回复: 加一颗星:),性能是相对,相比原子提交协议(比如2PC),共识算法的性能要高些。阻塞属于异常情况,在实际场景中,如果代码本身没有缺陷,在绝大多数时候,系统都是正常运行的,不存在阻塞的,也不会影响到写的性能。

    2020-06-21
    1
  • DY-杨
    老师,咨询下。paxos算法从您讲解下来好像仅是对某个提案达成共识。没有看到故障恢复或日志恢复的过程啊。反倒zab和raft有。那您知道用这种共识算法的软件是自研的日志恢复吗?另外联合共识算法是什么呢。

    作者回复: 加一颗星:),算法和工程实现之间存在差异,对于Paxos而言,差异就更大了,缺少工程实现的必须细节,这也是为什么大家现在主要选择了raft的原因。故障恢复,是ZAB定义的,Raft没有定义这个阶段。问题1:若使用paxos,需要自己权衡,可以使用它的提到的方法,新领导者通过prepare阶段来发现之前选定的值,也可以自己设计,需要整体考虑。问题2:联合共识,是Raft中处理成员变更的一种方法。

    2020-05-20
    1
  • 爱德华
    老师,在说处理写请求的时候好像有点问题。本文中所说的是leader要在第二阶段(commit)后才会返回给客户端成功。但是在前几讲中,好像是说zab在第一阶段,收到大多数响应后就返回给客户端成功。那么这两个说法哪个正确呢?

    作者回复: 加一颗星:),第二个说法,在文中我没有搜到,如果方便,帮忙补充下哈。如果第二个说法去掉“第一阶段”和“就”,那么这两个说法,在我看来,都是正确的,一个侧重代码实现,一个侧重算法原理,就像同样是一棵树,生物学家和文学家的描述是不同的。

    2020-07-07
    2
  • Kvicii.Y
    领导者CommitProcessor.tryToCommit() 提交提案的方法似乎在3.6.0在Leader类中

    作者回复: 加一颗星:),是的

    2020-07-02
  • 王伟建
    老师有几个问题不太理解: 1.zk的写请求是领导者节点的两阶段提交,说写请求是强一致性,是说这个两阶段过程未完成之前不允许其他操作,所以说他是强一致性吗? 2.zk的读只能提供顺序一致性,也就是说他可能读到旧的版本的数据,那为什么还要把zk归为CP类型的系统呢?CAP里的C 不应该是强一致性吗,说到底感觉还是对这个一致性没理解透,就之前的理解来说,我认为C是指每次读取的数据都是最近一次写入的数据,而不是过期的数据。希望老师能讲解一下这块儿。 3.利用zk来实现分布式锁,多个服务同时去拿锁时,如果zk提供的读不是强一致性,那么会不会读到旧的锁信息?这块儿是怎么保证每个服务拿到的都是最新的数据,实现上来说是靠sync读吗?
    2020-12-27
    3
    4
  • 路人
    写我看用的是2pc,2pc中有些如果只有部分commit成功,zookeeper会怎么处理呢?是有什么补偿机制么?
    2020-09-03
    1
    2
  • 姑射仙人
    老师,那么Zookeeper是CP呢,还是AP呢?读是最终一致,那么我理解是AP。但之前读的一篇文章,说Zookeeper不适合作为注册中心,说Zookeeper是CP,AP更适合作为注册中心,因为是读多写少,不要求马上能看到新的实例更新。 至于同步机制,Zookeeper也是支持增量更新,这样看来完全没有问题。麻烦老师指点下。
    2021-03-10
    3
    1
收起评论
显示
设置
留言
17
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部