Zookeeper 的核心引擎：深入分析 ZAB 协议

#作者：张桐瑞


媒介

ZooKeeper 最核心的作用就是包管分布式体系的数据划一性，而无论是处理惩罚来自客户端的会话哀求时，还是集群 Leader 节点发生重新推举时，都会产生数据不划一的环境。为了办理这个题目，ZooKeeper 接纳了 ZAB 协议算法。
ZAB 协议算法

ZAB 协议算法（Zookeeper Atomic Broadcast ，Zookeeper 原子广播协议）是 ZooKeeper 专门操持用来办理集群终极划一性题目的算法，它的两个核心功能点是瓦解规复和原子广播协议。
在整个 ZAB 协议的底层实现中，ZooKeeper 集群告急接纳主从模式的体系架构方式来包管 ZooKeeper 集群体系的划一性，当汲取到来自客户端的事件性会话哀求后，体系集群接纳主服务器来处理惩罚该条会话哀求，颠末主服务器处理惩罚的效果会通过网络发送给集群中其他从节点服务器举行数据同步利用。
以 ZooKeeper 集群为例，这个利用过程可以概括为：当 ZooKeeper 集群汲取到来自客户端的事件性的会话哀求后，集群中的其他 Follow 脚色服务器会将该哀求转发给 Leader 脚色服务器举行处理惩罚。当 Leader 节点服务器在处理惩罚完该条会话哀求后，会将效果通过利用日志的方式同步给集群中的 Follow 脚色服务器。然后 Follow 脚色服务器根据汲取到的利用日志，在本地实验干系的数据处理惩罚利用，终极完成整个 ZooKeeper 集群对客户端会话的处理惩罚工作。
瓦解规复

整个 ZooKeeper 集群处理惩罚客户端会话的核心点在一台 Leader 服务器上。全部的业务处理惩罚和数据同步利用都要靠 Leader 服务器完成。联合ZooKeeper 架构方式，会发现极易产生单点题目，即当集群中的 Leader 发生故障的时间，整个集群就会由于缺少 Leader 服务器而无法处理惩罚来自客户端的事件性的会话哀求。因此，为办理这个题目。在 ZAB 协议中也设置了处理惩罚该题目的瓦解规复机制。
瓦解规复机制是包管 ZooKeeper 集群服务高可用的关键。触发 ZooKeeper 集群实验瓦解规复的变乱是集群中的 Leader 节点服务器发生了非常而无法工作，于是 Follow 服务器会通过投票来决定是否选出新的 Leader 节点服务器。
投票过程如下：当瓦解规复机制开始的时间，整个 ZooKeeper 集群的每台 Follow 服务器会发起投票，并同步给集群中的其他 Follow 服务器。在汲取到来自集群中的其他 Follow 服务器的投票信息后，集群中的每个 Follow 服务器都会与自身的投票信息举行对比，如果判断新的投票信息更符合，则接纳新的投票信息作为本身的投票信息。在集群中的投票信息还没有到达凌驾半数原则的环境下，再举行新一轮的投票，终极当整个 ZooKeeper 集群中的 Follow 服务器凌驾半数投出的效果类似的时间，就会产生新的 Leader 服务器。
选票布局

整个投票阶段中的投票信息具有的布局。以 Fast Leader Election 推举的实现方式来讲，如下图所示，一个选票的团体效果可以分为一下六个部门：

• logicClock：用来纪录服务器的投票轮次。logicClock 会从 1 开始计数，每当该台服务颠末一轮投票后，logicClock 的数值就会加 1 。
  
• state：用来标志当前服务器的状态。在 ZooKeeper 集群中一台服务用具有 LOOKING、FOLLOWING、LEADERING、OBSERVING 这四种状态。
  
• self_id：用来表现当前服务器的 ID 信息，该字段在 ZooKeeper 集群中告急用来作为服务器的身份标识符。
  
• self_zxid： 当前服务器上所生存的数据的最大事件 ID ，从 0 开始计数。
  
• vote_id：投票要被推选的服务器的唯一 ID 。
  
• vote_zxid：被推选的服务器上所生存的数据的最大事件 ID ，从 0 开始计数。
  

当 ZooKeeper 集群须要重新推举出新的 Leader 服务器的时间，就会根据上面先容的投票信息内容举行对比，以找出最恰当的服务器。
选票筛选

接下来我们再来看一下，当一台 Follow 服务器汲取到网络中的其他 Follow 服务器的投票信息后，是怎样举行对比来更新本身的投票信息的。Follow 服务器举行选票对比的过程，如下图所示。

起首，会对比 logicClock 服务器的投票轮次，当 logicClock 类似时，表明两张选票处于类似的投票阶段，并进入下一阶段，否则跳过。接下来再对比 vote_zxid 被推举的服务器 ID 信息，若汲取到的外部投票信息中的 vote_zxid 字段较大，则将本身的票中的 vote_zxid 与 vote_myid 更新为收到的票中的 vote_zxid 与 vote_myid ，并广播出去。要是对比的效果类似，则继承对比 vote_myid 被推举服务器上所生存的最大事件 ID ，若外部投票的 vote_myid 比力大，则将本身的票中的 vote_myid 更新为收到的票中的 vote_myid 。 颠末这些对比和更换后，终极该台 Follow 服务器会产生新的投票信息，并在下一轮的投票中发送到 ZooKeeper 集群中。
消息广播

在 Leader 节点服务器处理惩罚哀求后，须要关照集群中的其他脚色服务器举行数据同步。ZooKeeper 集群接纳消息广播的方式发送关照。
ZooKeeper 集群利用原子广播协议举行消息发送，该协议的底层实现过程与我们在“ 28 | 彻底把握二阶段提交/三阶段提交算法原理” 的二阶段提交过程非常相似，如下图所示。

当要在集群中的其他脚色服务器举行数据同步的时间，Leader 服务器将该利用过程封装成一个 Proposal 提交事件，并将其发送给集群中其他须要举行数据同步的服务器。当这些服务器汲取到 Leader 服务器的数据同步事件后，会将该条事件能否在本地正常实验的效果反馈给 Leader 服务器，Leader 服务器在汲取到其他 Follow 服务器的反馈信息后举行统计，判断是否在集群中实验本次事件利用。
这里请各人注意 ，与我们“ 28 | 彻底把握二阶段提交/三阶段提交算法原理” 中提到的二阶段提交过程差别（即须要集群中全部服务器都反馈可以实验事件利用后，主服务器再次发送 commit 提交哀求实验数据变动） ，ZAB 协议算法省去了停止的逻辑，当 ZooKeeper 集群中有凌驾一样寻常的 Follow 服务器可以或许正常实验事件利用后，整个 ZooKeeper 集群就可以提交 Proposal 事件了。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

继续阅读请点击广告