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

加餐 | ZAB协议(二):如何从故障中恢复?

课堂思考
数据同步
成员发现
ZAB协议故障恢复

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

你好,我是韩健。
我们上一讲提到了 ZAB 的领导者选举,在我看来,它只是选举了一个适合当领导者的节点,然后把这个节点的状态设置成 LEADING 状态。此时,这个节点还不能作为主节点处理写请求,也不能使用领导职能(比如,它没办法阻止其他“领导者”广播提案)。也就是说,集群还没有从故障中恢复过来,而成员发现和数据同步会解决这个问题。
总的来说,成员发现和数据同步不仅让新领导者正式成为领导者,确立了它的领导关系,还解决了各副本的数据冲突,实现了数据副本的一致性。这样一来,集群就能正常处理写请求了。在这句话里:
确立领导关系,也就是在成员发现(DISCOVERY)阶段,领导者和大多数跟随者建立连接,并再次确认各节点对自己当选领导者没有异议,确立自己的领导关系;
处理冲突数据,也就是在数据同步(SYNCHRONIZATION)阶段,领导者以自己的数据为准,解决各节点数据副本的不一致。
对你来说,理解这两点,可以更好地理解 ZooKeeper 怎么恢复故障,以及当主节点崩溃了,哪些数据会丢失,哪些不会,以及背后的原因。也就是说,你能更加深刻地理解 ZooKeeper 的节点故障容错能力。
那么说了这么多,集群具体是怎么从故障中恢复过来的呢?带着这个问题,我们进入今天的学习。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

ZooKeeper中的ZAB协议是故障恢复的关键协议,包括领导者选举和数据同步两个关键步骤。在领导者选举阶段,新领导者需要建立自己的领导关系,并处理读写请求;而在数据同步阶段,确保跟随者节点上的数据与领导者节点上的数据一致。成员发现是通过跟随者和领导者交互来确立领导者的领导地位,而数据同步则是通过领导者向跟随者同步数据来实现。数据同步包括三种方式:TRUNC、DIFF、SNAP,用于处理不一致数据。领导者先就已提交提案和跟随者达成一致,然后将未提交提案也缓存在发送队列,并最终复制给跟随者节点,确保各节点数据的一致。整个过程展示了ZAB协议在ZooKeeper中的故障恢复原理和实现方式。 ZAB协议是ZooKeeper中故障恢复的关键协议,包括领导者选举和数据同步两个关键步骤。在领导者选举阶段,新领导者需要建立自己的领导关系,并处理读写请求;而在数据同步阶段,确保跟随者节点上的数据与领导者节点上的数据一致。成员发现是通过跟随者和领导者交互来确立领导者的领导地位,而数据同步则是通过领导者向跟随者同步数据来实现。数据同步包括三种方式:TRUNC、DIFF、SNAP,用于处理不一致数据。领导者先就已提交提案和跟随者达成一致,然后将未提交提案也缓存在发送队列,并最终复制给跟随者节点,确保各节点数据的一致。整个过程展示了ZAB协议在ZooKeeper中的故障恢复原理和实现方式。

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

全部留言(12)

  • 最新
  • 精选
  • 小波菜
    “如果写请求对应的提案“SET X = 1”未被复制到大多数节点上,比如在领导者广播消息过程中,领导者崩溃了,那么,提案“SET X = 1”,可能被复制到大多数节点上,并提交和之后就不再改变,也可能会被删除。这个行为是未确定的,取决于新的领导者是否包含该提案。” 请教韩老师: 这边set x=1只复制到少数节点上,那么这些少数节点的zxid应该是最大,应该回成为新的leader,也就不会丢数据了啊? 然后这个问题又该如何避免呢?

    作者回复: 加一颗星:),问题1:新领导者不是所有节点中ZXID最大的节点,而是大多数节点中ZXID最大的节点,如果“set x = 1”只复制到少数节点上,ZAB的领导者选举规则,不能保证成为领导者的节点一定是这些“少数节点”。 问题2:对客户端而言,需要支持操作的冥等性,如果写入超时(即在指定时间内,服务器没有成功将指令复制到大多数节点上),重试就可以了。而操作的冥等性,能保证最后的结果是预期的结果(即X的值为1)。

    2020-05-21
    2
    20
  • Tim
    有个问题请教下韩老师,在做故障恢复数据同步时候,如果 minCommittedLog < peerLastZxid < maxCommittedLog, 比如leader 是 【5,6,7,8,9】,而follower是【5,7】,follower中间少了一个zxid 6的事务,这时候数据同步会恢复嘛?谢谢老师解答。

    作者回复: 加一颗星:),不会出现这种情况,ZAB能保证提案的顺序性。

    2020-05-18
    5
    8
  • 要努力的兵长
    如果写请求对应的提案“SET X = 1”未被复制到大多数节点上,比如在领导者广播消息过程中,领导者崩溃了,那么,提案“SET X = 1”,可能被复制到大多数节点上,并提交和之后就不再改变,也可能会被删除。这个行为是未确定的,取决于新的领导者是否包含该提案 ----------像这种 提案的 事务ID明显是最大的吧。 那选举新leader 的时候, 也不可能选举出 没有接受的该提案的那种节点吧 (任期相同的情况下,选举 事务ID最大的 作为领导者)

    作者回复: 加一颗星:),有可能这个节点也出现了网络故障,没有参与领导者选举,只有“大多数”,才不会再改变。

    2020-09-10
    7
  • Heaven
    少数节点为何我XID最大我不能成为领导者呢?

    作者回复: 加一颗星:),不满足“大多数”原则,共识算法本质上是“多数派”算法。

    2020-08-19
    2
    4
  • Kvicii.Y
    感觉成员发现应该算是选举过后的一个选举补偿,而数据同步则是数据补偿

    作者回复: 加一颗星:),现在看来,这两个阶段其实是可以省去的,比如Raft就没有这两个阶段,技术是在不断发展的。

    2020-07-01
    3
  • 春风
    当接收到领导者的响应后,跟随者会判断领导者的任期编号是否最新,如果不是,就发起新的选举; 老师,什么情况下领导者的任期编号会不是最新呢?这个时候发起新的选举,其他节点的状态是不是应该是following状态,zab状态应该是discovery状态,这个时候是怎么响应选举的呢?

    作者回复: 加一颗星:),问题1:暂时没想到具体例子,我再想想:)。问题2:响应它认为是领导者的节点信息给这个选举状态的节点。

    2020-07-08
    2
  • kylexy_0817
    韩老师好,“只有当集群大多数节点处于广播状态的时候,集群才能提交提案”,是否意味着BROADCAST广播状态,是会与其它三个状态同时存在的呢?

    作者回复: 加一颗星:),在任意时刻,每个节点只能处于一种状态,但集群中的各节点可能处于不同的状态。

    2020-09-05
    1
  • 小麦
    【在 ZooKeeper 中,被复制到大多数节点上的提案,最终会被提交】 如果一个提案已经被复制到大多数节点上了,但是在 Leader 向节点发送 commit 之前崩溃了,那么 follower 是没有收到 commit 请求的,那这个提案最终也会被提交吗?为什么?
    2022-01-21
    1
    2
  • 豆豆酱
    我一直以为zk的读是顺序一致性,然后今天读到这个commit的特性。 zk这个commit 的特性(退出跟随者时commit),会不会影响顺序一致性?如果这个时候commit的提案被读了,后面又被删了?那这样就是最终一致性了。所以到底是什么?
    2023-05-09归属地:北京
  • simple_孙
    ZAB必须有数据同步的操作是不是因为Raft在提交数据的时候,跟随者会检查上一条数据是否提交成功,没成功的话就会重新同步;而ZAB的数据同步就是一个二阶段提交,没法检查上一个位置的同步结果。
    2021-11-13
    1
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部