阿里一面，说说你对zookeeper中ZAB协议的理解？

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

ZAB协议虽然舍弃分布式协议中的可用性，但却是一致性的经典代表。

1、zookeeper服务端架构?

咱们先来看下zookeeper的架构图，从上图可知，zookeeper服务端中会存在一个leader节点，负责所有数据的写入，而其他follower节点只支持读，follower节点的写请求会转发给leader节点处理，有点类似读写分离的主从模式。

2、ZAB协议过程说明

1. 所有事务请求转发给leader
2. Leader分配全局单调递增事务id(Zxid)，广播事务提议
3. Follower处理提议，做出反馈
4. Leader收到过半数反馈，广播Commit

从这个过程可以看出ZAB协议的重要特性是==有序性==，主要提现在Zxid的生成规则上

3、ZAB协议中的崩溃恢复

Leader服务器出现崩溃，或者说由于网络原因导致Leader服务器失去了与过半Follower的联系，那么就会讲入崩溃恢复模式。

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消息，以表示该事务已经被提交。

2. 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作为协调服务的代表，在面试中很容易被问到，希望大家能掌握这方面的知识，提高自己的核心竞争力，在谈薪的时候拿到最高的那个区间。

最后，外出打工不易，希望各位兄弟找到自己心仪的工作，虎年发发发！ 也希望兄弟们能==关注、点赞、收藏、评论==支持一波，非常感谢大家！