当前位置:   article > 正文

一文通吃:从 ZooKeeper 一致性,Leader选举讲到 ZAB 协议与 PAXOS 算法(下)

一文通吃:从 ZooKeeper 一致性,Leader选举讲到 ZAB 协议与 PAXOS 算法(下)

本文首发自\[慕课网] ,想了解更多IT干货内容,程序员圈内热闻,欢迎关注"慕课网"及“慕课网公众号”!

作者:大能 | 慕课网讲师


上篇文章,我们介绍了ZooKeeper集群保证数据一致性和Zookeeper集群Leader选举,这边文章我们接着介绍ZAB协议和Paxos算法

ZAB协议

在ZooKeeper在处理事务型请求的时候有提到一个协议,就是ZAB协议,然后在Leader选举时,ZooKeeper也是基于这个协议来进行实现的。所以实际上在整个ZooKeeper集群模式里面,这个ZAB协议是非常重要的。

ZAB 协议全称:Zookeeper Atomic Broadcast(Zookeeper 原子广播协议)。ZAB协议是为分布式协调服务 ZooKeeper 专门设计的一种支持 崩溃恢复原子广播协议,这里需要注意,它并不是通用的分布式一致性算法,而是ZooKeeper 自己量身定制的,这样的好处就是它相对来说比较简单,没那么复杂,而且跟 ZooKeeper 完美契合。

ZAB 协议 ZXID 是如何生成的

基于这个协议,ZooKeeper 实现了各个副本之间数据一致性,并且集群初始化的时候,或者主节点发生故障的话,需要通过这个协议来选举Leader节点,这里我们来看一下这个问题:

数据一致性的保证和选举Leader节点都是非常依赖事务ID的,在ZAB协议里面叫做 ZXID ,那么这个 ZXID 是如何设计的?它是不是只是一个单纯的从小到大递增的过程?

那么我们结合这个问题来看一下这个 ZXID 是如何生成的

在 ZAB 协议的事务编号 ZXID 设计中,ZXID 是一个 64 位的数字,其中:

  • 低 32 位:可以看作是一个简单的递增的计数器,针对客户端的每一个事务请求,Leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操作。

  • 高 32 位:则代表了 Leader 服务器上取出本地日志中最大事务 Proposal 的 ZXID,并从该 ZXID 中解析出对应的 epoch 值,然后再对这个值加一。

高 32 位代表了每代 Leader 的唯一性,低 32 代表了每代 Leader 中事务的唯一性。同时,也能让 Follwer 通过高 32 位识别不同的 Leader。

基于这样的策略,当一个包含了上一个Leader周期中尚未提交过的事务Proposal的服务器启动加入到集群中,发现此时集群中已经存在leader,将自身以Follower角色连接上Leader服务器之后,Leader服务器会根据 自己服务器上最后被提交的Proposal来和Follower服务器的Proposali进行比对,发现follower中有上一个leader)周期的事务Proposal时,Leader会要求Follower进行一个回退操作(回退到一个确实已经被集群中过半机器提交的最新的事务Proposal.)。

ZAB协议——崩溃恢复模式

当整个集群启动过程中,或者当 Leader 服务器出现网络中弄断、崩溃退出或重启等异常时,Zab协议就会 进入崩溃恢复模式,选举产生新的Leader。

一但出现崩溃,会导致数据不一致,ZAB的崩溃恢复开始起作用。有如下两个确保:

  1. ZAB协议需要确保已经在Leader提交的事务最终被所有服务器提交。

  2. ZAB协议需要确保丢弃只在Leader服务器上被提出的事务。

针对上两个要求,如果Leader选举算法保证新选举出来的Leader服务器拥有集群中所有机器最高编号(ZXID最大)的事务Proposal,那么就能保证新的Leader 一定具有已提交的所有提案,更重要是,如果这么做,可以省去Leader服务器检查Proposal的提交和丢弃工作的这一步。

一旦Leader服务器出现崩溃,或者说网络原因导致Leader服务器失去了与过半的Follower的联系,那么就会进入崩溃恢复模式。为了保证程序的正常运行,整个恢复过程后需要选举一个新的Leader服务器。因此,ZAB协议需要一个高效可靠的Leader选举算法,从而确保能够快速的选举出新的Leader。同时,新的Leader选举算法不仅仅需要让Leader自己知道其自身已经被选举为Leader,同时还需要让集群中所有的其它机器也能够快速的感知选举产生的新的Leader服务器。

ZAB协议规定了如果一个事务Proposal在一台机器上被处理成功,那么应该在所有的机器上都被处理成功,哪怕机器出现崩溃。

ZAB协议——消息广播模式

当新的Leader出来了,同时,已有过半机器完成同步之后,ZAB协议将退出恢复模式。进入消息广播模式。这时,如果有一台遵守Zab协议的服务器加入集群,因为此时集群中已经存在一个Leader服务器在广播消息,那么该新加入的服务器自动进入恢复模式:找到Leader服务器,并且完成数据同步。同步完成后,作为新的Follower一起参与到消息广播流程中。

如果集群中其它机器收到客户端事务请求后,那么会先转发Leader服务器,由Leader统一处理。

  1. 在zookeeper集群中,数据副本的传递策略就是采用消息广播模式。zookeeper中数据副本的同步方式与二段提交相似,但是却又不同。二段提交要求协调者必须等到所有的参与者全部反馈ACK确认消息后,再发送commit消息。要求所有的参与者要么全部成功,要么全部失败。二段提交会产生严重的阻塞问题。

  2. Zab协议中 Leader 等待 Follower 的ACK反馈消息是指“只要半数以上的Follower成功反馈即可,不需要收到全部Follower反馈”

  3. 整个过程中,Leader为每个事务请求生产对应的Prop

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小小林熬夜学编程/article/detail/170467
推荐阅读
相关标签
  

闽ICP备14008679号