【JAVA】Zookeeper基础

1 概念

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

2 角色

Zookeeper 集群基于主从复制高可用集群。
每个服务器是如下三种角色之一。

2.1 Leader

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

2.2 Follower

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

2.3 Observer

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

3 协议与机制

3.1 ZAB协议

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

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

ZAB协议4 阶段

1. Leader election(选举阶段):节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准leader 。只有到达 广播阶段(broadcast )准 leader 才会成为真正的leader。这一阶段的目的是就是为了选出一个准leader ,然后进入下一个阶段。 选出准Leader
2. Discovery（发现阶段）：在此阶段，followers跟准leader进行通信，同步followers最近接收的事务提议。这个一阶段的主要目的是发现当前大多数节点接收的最新提议，并且准leader生成新的epoch ，让followers接受，更新它们的accepted Epoch。一个follower只会连接一个leader，如果有一个节点 f 认为另一个 follower p 是leader ，f 在尝试连接p时会被拒绝,f 被拒绝之后，就会进入重新选举阶段。接受提议、生成epoch 、接受epoch
3. Synchronization(同步阶段)：同步阶段主要是利用leader前一阶段获得的最新提议历史，同步集群中所有的副本。只有当大多数节点都同步完成，准leader才会成为真正的 leader 。follower只会接收zxid比自己的lastZxid大的提议。同步follower 副本
4. Broadcast (广播阶段)：到了这个阶段,Zookeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。leader 消息广播

3.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 的请求进行服务了

3.3 Zookeeper工作原理(原子广播)

1. Zookeeper的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们是恢复模式和广播模式。
2. 当服务启动或者在领导者崩溃后，Zab 就进入了恢复模式，当领导者被选举出来，且大多数server 的完成了和 leader 的状态同步以后，恢复模式就结束了。
3. 状态同步保证了 leader 和server 具有相同的系统状态
4. 一旦leader 已经和多数的 follower 进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个 server 加入zookeeper 服务中，它会在恢复模式下启动，发现leader ，并和 leader 进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的followers 支持。
5. 广播模式需要保证 proposal被按顺序处理，因此 zk采用了递增的事务 id 号(zxi d) 来保证。所有的提议(proposal) 都在被提出的时候加上了 zxid 。
6. 实现中 zxid 是一个 64为的数字，它高 32位是 epoch 用来标识 leader 关系是否改变，每次一个 leader 被选出来，它都会有一个新的 epoch 。低32位是个递增计数。
7. 当leader 崩溃或者 leader 失去大多数的 follower ，这时候 zk进入恢复模式，恢复模式需要重新选举出一个新的 leader ，让所有的 server 都恢复到一个正确的状态。

3.4 Znode 有四种形式的目录节点

1. PERSISTENT ：持久的节点。
2. EPHEMERAL ：暂时的节点。
3. PERSISTENT_SEQUENTIAL：持久化顺序编号目录节点。
4. EPHEMERAL_SEQUENTIAL：暂时化顺序编号目录节点。

3.5 Epoch

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