共计 4737 个字符，预计需要花费 12 分钟才能阅读完成。
ZooKeeper 为高可用的一致性协调框架，自然的 ZooKeeper 也有着一致性算法的实现，ZooKeeper 使用的是 ZAB 协议作为数据一致性的算法，ZAB（ZooKeeper Atomic Broadcast）全称为：原子消息广播协议；ZAB 可以说是在 Paxos 算法基础上进行了扩展改造而来的，ZAB 协议设计了支持崩溃恢复，ZooKeeper 使用单一主进程 Leader 用于处理客户端所有事务请求，采用 ZAB 协议将服务器数状态以事务形式广播到所有 Follower 上；由于事务间可能存在着依赖关系，ZAB 协议保证 Leader 广播的变更序列被顺序的处理，：一个状态被处理那么它所依赖的状态也已经提前被处理；ZAB 协议支持的崩溃恢复可以保证在 Leader 进程崩溃的时候可以重新选出 Leader 并且保证数据的完整性；
在 ZooKeeper 中所有的事务请求都由一个主服务器也就是 Leader 来处理，其他服务器为 Follower，Leader 将客户端的事务请求转换为事务 Proposal，并且将 Proposal 分发给集群中其他所有的 Follower，然后 Leader 等待 Follwer 反馈，当有 过半数（>=N/2+1）的 Follower 反馈信息后，Leader 将再次向集群内 Follower 广播 Commit 信息，Commit 为将之前的 Proposal 提交；
协议状态
ZAB 协议中存在着三种状态，每个节点都属于以下三种中的一种：
1. Looking：系统刚启动时或者 Leader 崩溃后正处于选举状态
2. Following：Follower 节点所处的状态，Follower 与 Leader 处于数据同步阶段；
3. Leading：Leader 所处状态，当前集群中有一个 Leader 为主进程；
ZooKeeper 启动时所有节点初始状态为 Looking，这时集群会尝试选举出一个 Leader 节点，选举出的 Leader 节点切换为 Leading 状态；当节点发现集群中已经选举出 Leader 则该节点会切换到 Following 状态，然后和 Leader 节点保持同步；当 Follower 节点与 Leader 失去联系时 Follower 节点则会切换到 Looking 状态，开始新一轮选举；在 ZooKeeper 的整个生命周期中每个节点都会在 Looking、Following、Leading 状态间不断转换；
状态切换图
选举出 Leader 节点后 ZAB 进入原子广播阶段，这时 Leader 为和自己同步的每个节点 Follower 创建一个操作序列，一个时期一个 Follower 只能和一个 Leader 保持同步，Leader 节点与 Follower 节点使用心跳检测来感知对方的存在；当 Leader 节点在超时时间内收到来自 Follower 的心跳检测那 Follower 节点会一直与该节点保持连接；若超时时间内 Leader 没有接收到来自过半 Follower 节点的心跳检测或 TCP 连接断开，那 Leader 会结束当前周期的领导，切换到 Looking 状态，所有 Follower 节点也会放弃该 Leader 节点切换到 Looking 状态，然后开始新一轮选举；
阶段
ZAB 协议定义了 选举（election）、发现（discovery）、同步（sync）、广播 (Broadcast) 四个阶段；ZAB 选举（election）时当 Follower 存在 ZXID（事务 ID）时判断所有 Follower 节点的事务日志，只有 lastZXID 的节点才有资格成为 Leader，这种情况下选举出来的 Leader 总有最新的事务日志，基于这个原因所以 ZooKeeper 实现的时候把 发现（discovery）与同步（sync）合并为恢复（recovery）阶段；
1. Election：在 Looking 状态中选举出 Leader 节点，Leader 的 lastZXID 总是最新的；
2. Discovery：Follower 节点向准 Leader 推送 FOllOWERINFO，该信息中包含了上一周期的 epoch，接受准 Leader 的 NEWLEADER 指令，检查 newEpoch 有效性，准 Leader 要确保 Follower 的 epoch 与 ZXID 小于或等于自身的；
3. sync：将 Follower 与 Leader 的数据进行同步，由 Leader 发起同步指令，最总保持集群数据的一致性；
4. Broadcast：Leader 广播 Proposal 与 Commit，Follower 接受 Proposal 与 Commit；
5. Recovery：在 Election 阶段选举出 Leader 后本阶段主要工作就是进行数据的同步，使 Leader 具有 highestZXID，集群保持数据的一致性；
选举（Election）
election 阶段必须确保选出的 Leader 具有 highestZXID，否则在 Recovery 阶段没法保证数据的一致性，Recovery 阶段 Leader 要求 Follower 向自己同步数据没有 Follower 要求 Leader 保持数据同步，所有选举出来的 Leader 要具有最新的 ZXID；
在选举的过程中会对每个 Follower 节点的 ZXID 进行对比只有 highestZXID 的 Follower 才可能当选 Leader；
选举流程：
1. 每个 Follower 都向其他节点发送选自身为 Leader 的 Vote 投票请求，等待回复；
2. Follower 接受到的 Vote 如果比自身的大（ZXID 更新）时则投票，并更新自身的 Vote，否则拒绝投票；
3. 每个 Follower 中维护着一个投票记录表，当某个节点收到过半的投票时，结束投票并把该 Follower 选为 Leader，投票结束；
ZAB 协议中使用 ZXID 作为事务编号，ZXID 为 64 位数字，低 32 位为一个递增的计数器，每一个客户端的一个事务请求时 Leader 产生新的事务后该计数器都会加 1，高 32 位为 Leader 周期 epoch 编号，当新选举出一个 Leader 节点时 Leader 会取出本地日志中最大事务 Proposal 的 ZXID 解析出对应的 epoch 把该值加 1 作为新的 epoch，将低 32 位从 0 开始生成新的 ZXID；ZAB 使用 epoch 来区分不同的 Leader 周期；
恢复（Recovery）
在 election 阶段选举出来的 Leader 已经具有最新的 ZXID，所有本阶段的主要工作是根据 Leader 的事务日志对 Follower 节点数据进行更新；
Leader：Leader 生成新的 ZXID 与 epoch，接收 Follower 发送过来的 FOllOWERINFO（含有当前节点的 LastZXID）然后往 Follower 发送 NEWLEADER；Leader 根据 Follower 发送过来的 LastZXID 根据数据更新策略向 Follower 发送更新指令；
同步策略：
1. SNAP：如果 Follower 数据太老，Leader 将发送快照 SNAP 指令给 Follower 同步数据；
2. DIFF：Leader 发送从 Follolwer.lastZXID 到 Leader.lastZXID 议案的 DIFF 指令给 Follower 同步数据；
3. TRUNC：当 Follower.lastZXID 比 Leader.lastZXID 大时，Leader 发送从 Leader.lastZXID 到 Follower.lastZXID 的 TRUNC 指令让 Follower 丢弃该段数据；
Follower：往 Leader 发送 FOLLOERINFO 指令，Leader 拒绝就转到 Election 阶段；接收 Leader 的 NEWLEADER 指令，如果该指令中 epoch 比当前 Follower 的 epoch 小那么 Follower 转到 Election 阶段；Follower 还有主要工作是接收 SNAP/DIFF/TRUNC 指令同步数据与 ZXID，同步成功后回复 ACKNETLEADER，然后进入下一阶段；Follower 将所有事务都同步完成后 Leader 会把该节点添加到可用 Follower 列表中；
SNAP 与 DIFF 用于保证集群中 Follower 节点已经 Committed 的数据的一致性，TRUNC 用于抛弃已经被处理但是没有 Committed 的数据；
广播(Broadcast)
客户端提交事务请求时 Leader 节点为每一个请求生成一个事务 Proposal，将其发送给集群中所有的 Follower 节点，收到过半 Follower 的反馈后开始对事务进行提交，ZAB 协议使用了原子广播协议；在 ZAB 协议中只需要得到过半的 Follower 节点反馈 Ack 就可以对事务进行提交，这也导致了 Leader 几点崩溃后可能会出现数据不一致的情况，ZAB 使用了崩溃恢复来处理数字不一致问题；消息广播使用了 TCP 协议进行通讯所有保证了接受和发送事务的顺序性。广播消息时 Leader 节点为每个事务 Proposal 分配一个全局递增的 ZXID（事务 ID），每个事务 Proposal 都按照 ZXID 顺序来处理；
Leader 节点为每一个 Follower 节点分配一个队列按事务 ZXID 顺序放入到队列中，且根据队列的规则 FIFO 来进行事务的发送。Follower 节点收到事务 Proposal 后会将该事务以事务日志方式写入到本地磁盘中，成功后反馈 Ack 消息给 Leader 节点，Leader 在接收到过半 Follower 节点的 Ack 反馈后就会进行事务的提交，以此同时向所有的 Follower 节点广播 Commit 消息，Follower 节点收到 Commit 后开始对事务进行提交；
Ubuntu 14.04 安装分布式存储 Sheepdog+ZooKeeper http://www.linuxidc.com/Linux/2014-12/110352.htm
CentOS 6 安装 sheepdog 虚拟机分布式储存 http://www.linuxidc.com/Linux/2013-08/89109.htm
ZooKeeper 集群配置 http://www.linuxidc.com/Linux/2013-06/86348.htm
使用 ZooKeeper 实现分布式共享锁 http://www.linuxidc.com/Linux/2013-06/85550.htm
分布式服务框架 ZooKeeper — 管理分布式环境中的数据 http://www.linuxidc.com/Linux/2013-06/85549.htm
ZooKeeper 集群环境搭建实践 http://www.linuxidc.com/Linux/2013-04/83562.htm
ZooKeeper 服务器集群环境配置实测 http://www.linuxidc.com/Linux/2013-04/83559.htm
ZooKeeper 集群安装 http://www.linuxidc.com/Linux/2012-10/72906.htm
Zookeeper3.4.6 的安装 http://www.linuxidc.com/Linux/2015-05/117697.htm
参考资料：
http://web.stanford.edu/class/cs347/reading/zab.pdf
http://www.tcs.hut.fi/Studies/T-79.5001/reports/2012-deSouzaMedeiros.pdf
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-03/129508.htm
