zookeeper - 介绍

11.1.1. Zookeeper 概念

Zookeeper 是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。 Zookeeper 提供了一个相似于 Linux 文件系统的树形结构（可认为是轻量级的内存文件系统，但 只适合存少许信息，彻底不适合存储大量文件或者大文件），同时提供了对于每一个节点的监控与 通知机制。

11.1.1. Zookeeper 角色

Zookeeper 集群是一个基于主从复制的高可用集群，每一个服务器承担以下三种角色中的一种

11.1.1.1. Leader

1. 一个 Zookeeper 集群同一时间只会有一个实际工做的 Leader，它会发起并维护与各 Follwer 及 Observer 间的心跳。 2. 全部的写操做必需要经过 Leader 完成再由 Leader 将写操做广播给其它服务器。只要有超过 半数节点（不包括 observeer 节点）写入成功，该写请求就会被提交（类 2PC 协议）。

11.1.1.2. Follower

1. 一个 Zookeeper 集群可能同时存在多个 Follower，它会响应 Leader 的心跳， 2. Follower 可直接处理并返回客户端的读请求，同时会将写请求转发给 Leader 处理， 3. 而且负责在 Leader 处理写请求时对请求进行投票。

11.1.1.3. Observer 角色

与 Follower 相似，可是无投票权。Zookeeper 需保证高可用和强一致性，为了支持更多的客 户端，须要增长更多 Server；Server 增多，投票阶段延迟增大，影响性能；引入 Observer， Observer 不参与投票； Observers 接受客户端的链接，并将写请求转发给 leader 节点； 加入更 多 Observer 节点，提升伸缩性，同时不影响吞吐率。

 11.1.1.1. ZAB 协议

事务编号 Zxid（事务请求计数器+ epoch）

在 ZAB ( ZooKeeper Atomic Broadcast , ZooKeeper 原子消息广播协议） 协议的事务编号 Zxid 设计中，Zxid 是一个 64 位的数字，其中低 32 位是一个简单的单调递增的计数器，针对客户端每 一个事务请求，计数器加 1；而高 32 位则表明 Leader 周期 epoch 的编号，每一个当选产生一个新 的 Leader 服务器，就会从这个 Leader 服务器上取出其本地日志中最大事务的 ZXID，并从中读取 epoch 值，而后加 1，以此做为新的 epoch，并将低 32 位从 0 开始计数。 Zxid（Transaction id）相似于 RDBMS 中的事务 ID，用于标识一次更新操做的 Proposal（提议） ID。为了保证顺序性，该 zkid 必须单调递增。

epoch

epoch：能够理解为当前集群所处的年代或者周期，每一个 leader 就像皇帝，都有本身的年号，所 以每次改朝换代，leader 变动以后，都会在前一个年代的基础上加 1。这样就算旧的 leader 崩溃 恢复以后，也没有人听他的了，由于 follower 只遵从当前年代的 leader 的命令。

Zab 协议有两种模式-恢复模式（选主）、广播模式（同步）

Zab 协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导 者崩溃后，Zab 就进入了恢复模式，当领导者被选举出来，且大多数 Server 完成了和 leader 的状 态同步之后，恢复模式就结束了。状态同步保证了 leader 和 Server 具备相同的系统状态。

ZAB 协议 4 阶段 Leader election（选举阶段-选出准 Leader）

1. Leader election（选举阶段）：

节点在一开始都处于选举阶段，只要有一个节点获得超半数 节点的票数，它就能够当选准 leader。只有到达 广播阶段（broadcast） 准 leader 才会成 为真正的 leader。这一阶段的目的是就是为了选出一个准 leader，而后进入下一个阶段。 

Discovery（发现阶段-接受提议、生成 epoch、接受 epoch）

2. Discovery（发现阶段）：在这个阶段，followers 跟准 leader 进行通讯，同步 followers 最近接收的事务提议。这个一阶段的主要目的是发现当前大多数节点接收的最新提议，而且 准 leader 生成新的 epoch，让 followers 接受，更新它们的 accepted Epoch 一个 follower 只会链接一个 leader，若是有一个节点 f 认为另外一个 follower p 是 leader，f 在尝试链接 p 时会被拒绝，f 被拒绝以后，就会进入从新选举阶段。 Synchronization（同步阶段-同步 follower 副本）

3. Synchronization（同步阶段）：同步阶段主要是利用 leader 前一阶段得到的最新提议历史， 同步集群中全部的副本。只有当 大多数节点都同步完成，准 leader 才会成为真正的 leader。 follower 只会接收 zxid 比本身的 lastZxid 大的提议。 Broadcast（广播阶段-leader 消息广播）

4. Broadcast（广播阶段）：到了这个阶段，Zookeeper 集群才能正式对外提供事务服务， 而且 leader 能够进行消息广播。同时若是有新的节点加入，还须要对新节点进行同步。

ZAB 提交事务并不像 2PC 同样须要所有 follower 都 ACK，只须要获得超过半数的节点的 ACK 就 能够了。

ZAB 协议 JAVA 实现（FLE-发现阶段和同步合并为 Recovery Phase（恢复阶段））

协议的 Java 版本实现跟上面的定义有些不一样，选举阶段使用的是 Fast Leader Election（FLE）， 它包含了 选举的发现职责。由于 FLE 会选举拥有最新提议历史的节点做为 leader，这样就省去了 发现最新提议的步骤。实际的实现将 发现阶段 和 同步合并为 Recovery Phase（恢复阶段）。所 以，ZAB 的实现只有三个阶段：Fast Leader Election；Recovery Phase；Broadcast Phase。

11.1.1.2. 投票机制

每一个 sever 首先给本身投票，而后用本身的选票和其余 sever 选票对比，权重大的胜出，使用权 重较大的更新自身选票箱。具体选举过程以下：

1. 每一个 Server 启动之后都询问其它的 Server 它要投票给谁。对于其余 server 的询问， server 每次根据本身的状态都回复本身推荐的 leader 的 id 和上一次处理事务的 zxid（系 统启动时每一个 server 都会推荐本身）

2. 收到全部 Server 回复之后，就计算出 zxid 最大的哪一个 Server，并将这个 Server 相关信 息设置成下一次要投票的 Server。

3. 计算这过程当中得到票数最多的的 sever 为获胜者，若是获胜者的票数超过半数，则改 server 被选为 leader。不然，继续这个过程，直到 leader 被选举出来 4. leader 就会开始等待 server 链接

5. Follower 链接 leader，将最大的 zxid 发送给 leader

6. Leader 根据 follower 的 zxid 肯定同步点，至此选举阶段完成。

7. 选举阶段完成 Leader 同步后通知 follower 已经成为 uptodate 状态 8. Follower 收到 uptodate 消息后，又能够从新接受 client 的请求进行服务了 

 

目前有 5 台服务器，每台服务器均没有数据，它们的编号分别是 1,2,3,4,5,按编号依次启动，它们 的选择举过程以下：

1. 服务器 1 启动，给本身投票，而后发投票信息，因为其它机器尚未启动因此它收不到反 馈信息，服务器 1 的状态一直属于 Looking。

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

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

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

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