Zookeeper 的恢复模式，广播模式，选举流程

目录

背景：

由来：

ZAB 的两种模式：

恢复模式

消息广播模式

特殊情况崩溃的处理：

选举流程：

思维导图：

背景：

作为高可用一致性协调框架的老大哥，“动物界的管理员”，zookeeper 肯定有自己的一致性算法，叫做 ZAB,全称是 Zookeeper Atomic Broadcast ,翻译过来叫做原子消息广播协议。

由来：

这个算法是基于 paxos 扩展而来的，设计了崩溃恢复模式，zk 使用单一主进程 leader 来处理客户端所有的事务请求，采用ZAB协议将服务器数状态以事务形式广播到所有Follower上。

ZAB 的两种模式：

恢复模式：ZAB协议支持的崩溃恢复可以保证在Leader进程崩溃的时候可以重新选出Leader并且保证数据的完整性;

什么时候会进入恢复模式呢？

1.集群刚刚启动的时候。

2.leader 因为故障宕机了。

3.leader 失去了半数的机器支持。

消息广播模式：在ZooKeeper中所有的事务请求都由一个主服务器也就是Leader来处理，其他服务器为Follower，Leader将客户端的事务请求转换为事务Proposal，并且将Proposal分发给集群中其他所有的Follower，然后Leader等待Follwer反馈，当有过半数（>=N/2+1）的Follower反馈信息后，Leader将再次向集群内Follower广播Commit信息，Commit为将之前的Proposal提交。

图是从网上找的，图画的很清晰，一个客户端的写请求进来之后，leader 会为每个客户端的写请求包装成事务，并提供一个递增事务ID(zxid),保证每个消息的因果关系顺序。leader 会为该事务生成一个 Proposal,进行广播，leader 会为每一个 Follower服务器分配一个单独的FIFO 队列，然后把 Proposal 放到队列中，每一个 Follower 收到 该 Proposal 之后会把它持久到磁盘上，当完全写入之后，发一个 ACK 给leader，我们的leader 也不傻，收到超过半数机器的ack之后，他自己把自己机器上 Proposal 提交一下，同时开始广播 commit,每一个 Follower 收到 commit 之后，完成各自的事务提交。

可见，多数派机制和 ack 机制保证了 zk 的效率和可靠性。

特殊情况崩溃的处理：

已经被 leader 提交的 Proposal 确保最终被所有的 Follower 提交。

确保只有在 leader 上被提出的 Proposal 会被遗弃。

这里的丢弃事务是如何让进行的呢？我们知道，每一个事务都是有一个 zxid进行标记的，这个zxid 是一个 64位的数字，低32位做为计数器，高32位作为 leadert 的epcho周期、重新选举出来的 leader 会在急集群中找到最大的日志的 zxid，然后提取出来 + 1 作为自己的 epcho 周期数，然后把后面的32位清零，开始计数。

选举流程：

假设目前有五台服务器，每台服务器均没有数据，编号分别是 1，2，3，4，5，按照编号一次启动他们：

服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。

服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。

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

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

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

这样，服务器3成为了 leader !   

基于上面的选举流程，试想如果是启动顺序按照服务器 5，4，3，2，1 ，谁会是 leader 呢？

ps：这里的编号指的是：myid 文件里对应的编号。

答案是：服务器 5

思维导图：