关于java:阿里一面说说你对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 作为协调服务的代表，在面试中很容易被问到，心愿大家能把握这方面的常识，进步本人的外围竞争力，在谈薪的时候拿到最高的那个区间。

最初，外出打工不易，心愿各位兄弟找到本人心仪的工作，虎年发发发！也心愿兄弟们能 == 关注、点赞、珍藏、评论 == 反对一波，非常感谢大家！