【深入理解Zookeeper原理】Zab 协议

Zookeeper 原理

Zookeeper 概念

Zookeeper 是一个分布式协调服务，可以用于服务发现，分布式锁，分布式选举，配置管理等场景。

Zookeeper 提供了一个类似于 Linux 文件系统的树形结构（可以认为是轻量级的内存文件系统，但是只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的通知机制。

Zookeeper 角色

leader

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

follwer

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

observer

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

什么是 zab 协议？

ZAB 协议是用来实现分布式系统中的一致性的。
是为了分布式协调服务 Zookeeper 专门设计的一种支持恢复的原子广播协议。有了这个协议，Zookeeper 实现了一种主备架构来保持机器中各个副本的数据一致性。

ZAB 协议

ZAB 协议 中有两个重要的元素：事务编号Zxid、epoch。

Zxid

协议的事务编号 Zxid 设计中， Zxid 是一个 64位的数字，其中低 32 位是一个简单的单调递增的计数器， 针对客户端每一个事务请求，计数器加 1; 而高32 位则代表 Leader 周期 epoch 的编号，每个当选产生一个新的 Leader 服务器，就会从这个 Leader 服务器上取出其本地日志中的最大事务 ZXID ,并从中读取 epoch 值，然后加 1 ，以此作为新的 epoch.并降低 32 位从 0 开始计数。

Zxid 类似 RDBMS 中的事务 ID ，用于标记一次更新操作的 Proposal (提议) ID, 为了保证顺序性，该 zxid 必须单调递增。

epoch

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

Zab 协议的4阶段

Phase 0. Leader election(选举阶段)

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

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

在这个阶段， followers 跟准 leader 进行通信，同步 followers
最近接收的事务提议。这个一阶段的主要目的是发现当前大多数节点接收的最新提议，并且准 leader 生成新的 epoch，让 followers 接受，更新它们的 accepted Epoch,一个 follower 只会连接一个 leader， 如果有一个节点 f 认为另一个 follower p 是 leader， f 在尝试连接 p 时会被拒绝， f 被拒绝之后，就会进入 选举 阶段。

Phase 2. Synchronization (同步阶段-同步 follower 副本)

Synchronization（同步阶段）: 同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。 只有当大多数节点都同步完成，准 leader 才会成为真正的 leader。follower 只会接收 zxid 比自己的 lastZxid 大的提议。

Phase 3. Broadcast（广播阶段）

到了这个阶段， Zookeeper 集群才能正式对外提供事务服务，
并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。ZAB 提交事务并不像 2PC 一样需要全部 follower 都 ACK， 只需要得到超过半数的节点的 ACK 就可以了。

ZAB 协议实现

协议的 Java 版本实现上面的定义不一样，宣酒节点使用的是 Fast Leader Election (FLE) 它包含了Phase 1 的发现职责，因为 FLE 会选举拥有最新提议历史的节点作为 leader, 这样就可以省去发现新提议的步骤，实际的实现将 Phase 1 和 Phase 2 合并成 Recovery Phase 。所以 ZAB 实现只有三个阶段。

• Fast Leader Election

• Recovery Phase

• Broadcast Phase

• https://juejin.im/post/5b924b0de51d450e9a2de615

主从架构下，leader 崩溃，数据一致性怎么保证？

leader 崩溃之后，集群会选出新的 leader，然后就会进入恢复阶段，新的 leader 具有所有已经提交的提议，因此它会保证让 followers 同步已提交的提议，丢弃未提交的提议（以 leader 的记录为准），这就保证了整个集群的数据一致性。

选举 leader 的时候，整个集群无法处理写请求的，如何快速进行 leader 选举？

这是通过 Fast Leader Election 实现的，leader 的选举只需要超过半数的节点投票即可，这样不需要等待所有节点的选票，能够尽早选出 leader。

ZAB 两种模式

恢复模式

当服务启动或者在 leader 崩溃的时候， Zab 进入恢复模式，当领导者被选举出来，并且大多数 server 和 leader 状态同步后，恢复模式结束。

广播模式

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 号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了 zxid。
6. 实现中 zxid 是一个 64 为的数字，它高 32 位是 epoch 用来标识 leader 关系是否改变，每次一个 leader 被选出来，它都会有一个新的 epoch。低 32 位是个递增计数。
7. 当 leader 崩溃或者 leader 失去大多数的 follower，这时候 zk 进入恢复模式，恢复模式需要重新选举出一个新的 leader，让所有的 server 都恢复到一个正确的状态。

程序员开发者社区