关于java:阿里一面说说你对zookeeper中ZAB协议的理解

10次阅读

共计 2661 个字符，预计需要花费 7 分钟才能阅读完成。

又到了金三银四的时候，大家都按耐不住心田的躁动，我在这里给大家分享下之前面试中遇到的一个知识点（ZAB 协定），心愿对大家有些帮忙。如有有余，欢送大佬们指导指导。

ZAB 协定尽管舍弃分布式协定中的可用性，但却是一致性的经典代表。

咱们先来看下 zookeeper 的架构图，从上图可知，zookeeper 服务端中会存在一个 leader 节点，负责所有数据的写入，而其余 follower 节点只反对读，follower 节点的写申请会转发给 leader 节点解决，有点相似读写拆散的主从模式。

所有事务申请转发给 leader

Leader 调配全局枯燥递增事务 id(Zxid)，播送事务提议

Follower 解决提议，做出反馈

Leader 收到过半数反馈，播送 Commit

从这个过程能够看出 ZAB 协定的重要个性是 == 有序性 ==，次要提当初 Zxid 的生成规定上

Leader 服务器呈现解体，或者说因为网络起因导致 Leader 服务器失去了与过半 Follower 的分割，那么就会讲入解体恢复模式。

ZAB 协定规定如果一个事务 Proposal 在一台机器上被解决胜利，那么应该在所有的机器上都被解决胜利，哪怕机器呈现故障解体。

ZAB 协定确保那些曾经在 Leader 服务器上提交的事务最终被所有服务器都提交

ZAB 协定确保抛弃那些只在 Leader 服务器上被提出的事务

ZAB 协定须要设计的选举算法应该满足:

确保提交曾经被 Leader 提交的事务 Proposal，同时抛弃曾经被跳过的事务 Proposal。

这个选举算法的益处是什么呢？

如果让 Leader 选举算法可能保障新选举进去的 Leader 服务器领有集群中所有机器最高 ZXID 的事务 Proposal，那么就能够保障这个新选举进去的 Leader 肯定具备所有曾经提交的提案。如果让具备最高编号事务

Proposal 的机器来成为 Leader，就能够省去 Leader 服务器查看 Proposal 的提交和抛弃工作的这一步操作。

对选举算法的要求:

选出的 Leader 节点上要持有最高的 zxid

过半数节点批准

Leader 选举进去后，需实现 Followers 与 Leader 的数据同步，当半数的 Followers 实现同步，则能够开始提供服务。

同步的过程如下:

Leader 服务器会为每一个 Follower 服务器都筹备一个队列，并将那些没有被各 Follower 服务器同步的事务以 Proposal 音讯的模式一一发送给 Follower 服务器，并在每一个 Proposal 音讯前面紧接着再发送一个 Commit 音讯，以示意该事务曾经被提交。

Follower 服务器将所有其尚未同步的事务 Proposal 都从 Leader 服务器上同步过去并胜利利用到本地数据库中后，Leader 服务器就会将该 Follower 服务器退出到真正的可用 Follower 列表中，并开始之后的其余流程。

在 ZAB 协定的事务编号 ZXID 设计中，ZXID 是一个 64 位的数字。

低 32 位是一个简略的枯燥递增的计数器，针对客户端的每一个事务申请，Leader 服务器在产生一个新的事务 Proposal 的时候，都会对该计数器进行加 1 操作;

高 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)。

选举机制中的概念:

服务器 id：myid

事务 id，服务器中寄存的最大 Zxid

逻辑时钟，发动的投票轮数计数
选举状态:
 >Looking，竞选状态。>Following，随从状态，同步 leader 状态，参加投票。>Observing，察看状态，同步 leader 状态，不参加投票。
Leading，领导者状态。

选举算法:

每个服务实例均发动选举本人为领导者的投票(本人的投给本人）;

其余服务实例收到投票邀请时，比拟发起者的数据事务 ID 是否比本人最新的事务 ID 大, 大则给它投一票，小则不投票给它，相等则比拟发起者的服务器 ID，大则投票给它;

发起者收到大家的投票反馈后，看投票数 (含本人的) 是否大于集群的半数，大于则胜出，负责领导者; 未超过半数且领导者未选出，则再次发动投票。

胜出条件:

投票赞成数大于半数则胜出的逻辑。

选举示例

有 5 台服务器，每台服务器均没有数据，它们的编号别离是 1,2;3,4,5, 按编号顺次启动，它们的选举过程如下:

服务器 1 启动，给本人投票，而后发投票信息，因为其它机器还没有启动所以它收不到反馈信息，服务器 1 的状态始终属于 Looking

服务器 2 启动，给本人投票，同时与之前启动的服务器 1 替换后果，因为服务器 2 的编号大所以服务器 2 胜出，但此时投票数没有大于半数，所以两个服务器的状态仍然是 Lookingo

服务器 3 启动，给本人投票，同时与之前启动的服务器 1,2 替换信息，因为服务器 3 的编号最大所以服务器 3 胜出，此时投票数正好大于半数，所以服务器 3 成为领导者，服务器 1,2 成为小弟。

服务器 4 启动，给本人投票，同时与之前启动的服务器 1,2,3 替换信息，只管服务器 4 的编号大，但之前服务器 3 曾经胜出，所以服务器 4 只能成为小弟。

服务器 5 启动, 前面的逻辑同服务器 4 成为小弟。

在微服务和分布式的时代，zookeeper 作为协调服务的代表，在面试中很容易被问到，心愿大家能把握这方面的常识，进步本人的外围竞争力，在谈薪的时候拿到最高的那个区间。

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

正文完