Zookeeper讲解（三）

Hello小伙伴们你们好~本兔君又来鸟~~今天要接着为你们介绍Zookeeper呢，有没有很期待哟！下面切入正题！

通常企业级架构的Zookeeper都是采用一主多从的架构，主节点负责写和读而从节点负责读取，在更新数据时，首先更新到主节点（这里的节点是指服务器，不是Znode），再同步到从节点。在读取数据时，直接读取任意从节点。那么如何保证主从节点数据的一致性呢？Zookeeper采用了ZAB协议，这种协议很是相似于一致性算法Paxos和Raft。

在学习ZAB以前，咱们须要首先了解ZAB协议所定义的三种节点状态：

Looking ：选举状态。

Following ：Follower节点（从节点）所处的状态。

Leading ：Leader节点（主节点）所处状态。

最大ZXID又是啥呢？

最大ZXID也就是节点本地的最新事务编号，包含epoch和计数两部分。epoch是纪元的意思，至关于Raft算法选主时候的term。假如Zookeeper当前的主节点挂掉了，集群会进行崩溃恢复。ZAB的崩溃恢复分红三个阶段：下面一一为你们介绍一波~

1

选举阶段

1.Leader election

选举阶段，此时集群中的节点处于Looking状态。它们会各自向其余节点发起投票，投票当中包含本身的服务器ID和最新事务ID（ZXID）。

接下来，节点会用自身的ZXID和从其余节点接收到的ZXID作比较，若是发现别人家的ZXID比本身大，也就是数据比本身新，那么就从新发起投票，投票给目前已知最大的ZXID所属节点。

每次投票后，服务器都会统计投票数量，判断是否有某个节点获得半数以上的投票。若是存在这样的节点，该节点将会成为准Leader，状态变为Leading。其余节点的状态变为Following。

2.Discovery

发现阶段，用于在从节点中发现最新的ZXID和事务日志。或许有人会问：既然Leader被选为主节点，已是集群里数据最新的了，为何还要从节点中寻找最新事务呢？这是为了防止某些意外状况，好比因网络缘由在上一阶段产生多个Leader的状况。因此这一阶段，Leader集思广益，接收全部Follower发来各自的最新epoch值。Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。各个Follower收到全新的epoch后，返回ACK给Leader，带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID，并更新自身历史日志。

3.Synchronization

同步阶段，把Leader刚才收集获得的最新历史事务日志，同步给集群中全部的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。自此，故障恢复正式完成。

2

ZAB实现写入数据

什么是Broadcast呢？简单来讲，就是Zookeeper常规状况下更新数据的时候，由Leader广播到全部的Follower。其过程以下：

1.客户端发出写入数据请求给任意Follower。

2.Follower把写入数据请求转发给Leader。

3.Leader采用二阶段提交方式，先发送Propose广播给Follower。

4.Follower接到Propose消息，写入日志成功后，返回ACK消息给Leader。

5.Leader接到半数以上ACK消息，返回成功给客户端，而且广播Commit请求给Follower。

今天的分享就到这里啦，本兔兔是否是讲的很明白呀，小伙们感受清晰易懂别忘了关注+在看哦，想打个赏我也不拦着~~

本文分享自微信公众号 - 萌兔it（mengtu_it）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。