阿里一面,说说你对zookeeper中ZAB协议的理解()

又到了金三银四的时候,大家都按耐不住内心的躁动,我在这里给大家分享下之前面试中遇到的一个知识点(ZAB协议),希望对大家有些帮助。如有不足,欢迎大佬们指点指点。

ZAB协议虽然舍弃分布式协议中的可用性,但却是一致性的经典代表。
1、zookeeper服务端架构? 阿里一面,说说你对zookeeper中ZAB协议的理解()
文章图片

咱们先来看下zookeeper的架构图,从上图可知,zookeeper服务端中会存在一个leader节点,负责所有数据的写入,而其他follower节点只支持读,follower节点的写请求会转发给leader节点处理,有点类似读写分离的主从模式。
2、ZAB协议过程说明 阿里一面,说说你对zookeeper中ZAB协议的理解()
文章图片

  1. 所有事务请求转发给leader
  2. Leader分配全局单调递增事务id(Zxid),广播事务提议
  3. Follower处理提议,做出反馈
  4. Leader收到过半数反馈,广播Commit
从这个过程可以看出ZAB协议的重要特性是==有序性==,主要提现在Zxid的生成规则上
3、ZAB协议中的崩溃恢复 Leader服务器出现崩溃,或者说由于网络原因导致Leader服务器失去了与过半Follower的联系,那么就会讲入崩溃恢复模式。
阿里一面,说说你对zookeeper中ZAB协议的理解()
文章图片

  1. ZAB协议规定如果一个事务Proposal在一台机器上被处理成功,那么应该在所有的机器上都被处理成功,哪怕机器出现故障崩溃。
  2. ZAB协议确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交
  3. ZAB协议确保丢弃那些只在Leader服务器上被提出的事务
ZAB协议需要设计的选举算法应该满足:
确保提交已经被Leader提交的事务Proposal,同时丢弃已经被跳过的事务Proposal。
这个选举算法的好处是什么呢?
  1. 如果让Leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高ZXID的事务Proposal,那么就可以保证这个新选举出来的Leader一定具有所有已经提交的提案。如果让具有最高编号事务
  2. Proposal 的机器来成为 Leader,就可以省去 Leader 服务器检查Proposal的提交和丢弃工作的这一步操作。
对选举算法的要求:
  1. 选出的Leader节点上要持有最高的zxid
  2. 过半数节点同意
4、ZAB协议中的数据同步
Leader选举出来后,需完成Followers与Leader的数据同步,当半数的Followers完成同步,则可以开始提供服务。
同步的过程如下:
  1. Leader 服务器会为每一个 Follower服务器都准备一个队列,并将那些没有被各Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower服务器,并在每一个Proposal消息后面紧接着再发送一个Commit消息,以表示该事务已经被提交。
  1. Follower服务器将所有其尚未同步的事务Proposal 都从 Leader 服务器上同步过来并成功应用到本地数据库中后,Leader服务器就会将该Follower服务器加入到真正的可用 Follower列表中,并开始之后的其他流程。
5、ZAB协议中丢弃事务Proposal外理 在ZAB协议的事务编号ZXID设计中,ZXID是一个64位的数字。
  1. 低32位是一个简单的单调递增的计数器,针对客户端的每一个事务请求,Leader服务器在产生一个新的事务Proposal的时候,都会对该计数器进行加1操作;
  2. 高32位代表了Leader周期纪元的编号,每当选举产生一个新的Leader服务器,就会从这个Leader服务器上取出基本地日志中最大事务 Proposal的ZXID,并从该ZXID中解析出对应的纪元值,然后对其进行加1操作,之后就会以此编号作为新的纪元,并将低32位置0来开始生成新的ZXID。
基于这样的策略,当一个包含了上一个Leader周期中尚未提交过的事务Proposal的服务器启动加入到集群中,发现此时集群中已经存在leader,将自身以Follower角色连接上Leader服务器之后,Leader服务器会根据自己服务器上最后被提交的 Proposal来和 Follower 服务器的Proposal进行比对,发现follower中有上一个leader周期的事务Proposal时,Leader会要求Follower进行一个回退操作(回退到一个确实已经被集群中过半机器提交的最新的事务Proposal)。
6、ZooKeeper集群Leader选举机制 选举机制中的概念:
  1. 服务器id:myid
  2. 事务id,服务器中存放的最大Zxid
  3. 逻辑时钟,发起的投票轮数计数
  4. 选举状态:
    >Looking,竞选状态。 >Following,随从状态,同步leader状态,参与投票。 >Observing,观察状态,同步leader状态,不参与投票。

    Leading,领导者状态。
选举算法:
  1. 每个服务实例均发起选举自己为领导者的投票(自己的投给自己);
  2. 其他服务实例收到投票邀请时,比较发起者的数据事务ID是否比自己最新的事务ID大,大则给它投一票,小则不投票给它,相等则比较发起者的服务器ID,大则投票给它;
  3. 发起者收到大家的投票反馈后,看投票数(含自己的)是否大于集群的半数,大于则胜 出,担任领导者; 未超过半数且领导者未选出,则再次发起投票。
胜出条件:
投票赞成数大于半数则胜出的逻辑。
选举示例
有5台服务器,每台服务器均没有数据,它们的编号分别是1,2; 3,4,5,按编号依次启动,它们的选举过程如下:
  1. 服务器1启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反馈信息,服务器1的状态一直属于Looking
  2. 服务器2启动,给自己投票,同时与之前启动的服务器1交换结果,由于服务器2的编号大所以服务器2胜出,但此时投票数没有大于半数,所以两个服务器的状态依然是Lookingo
  3. 服务器3启动,给自己投票,同时与之前启动的服务器1,2交换信息,由于服务器3的编号最大所以服务器3胜出,此时投票数正好大于半数,所以服务器3成为领导者,服务器1,2成为小弟。
  4. 服务器4启动,给自己投票,同时与之前启动的服务器1,2,3交换信息,尽管服务器4的编号大,但之前服务器3已经胜出,所以服务器4只能成为小弟。
  5. 服务器5启动,后面的逻辑同服务器4成为小弟。
7、总结
在微服务和分布式的时代,zookeeper作为协调服务的代表,在面试中很容易被问到,希望大家能掌握这方面的知识,提高自己的核心竞争力,在谈薪的时候拿到最高的那个区间。
【阿里一面,说说你对zookeeper中ZAB协议的理解()】最后,外出打工不易,希望各位兄弟找到自己心仪的工作,虎年发发发! 也希望兄弟们能==关注、点赞、收藏、评论==支持一波,非常感谢大家!

    推荐阅读