Zookeeper（2）

ZAB 协议

概述

1. ZAB(Zookeeper Automic Broadcast) 是一套专门为 Zookeeper 设计的用于进行 原子广播 和 崩溃恢

复 的协议

2. ZAB 协议主要包含了两个功能

   1. 原子广播：保证数据一致性

   2. 崩溃恢复：保证集群的高可用

3. ZAB 协议本身是基于 2PC 算法来进行的设计，加入了 PAXOS 算法和过半性进行了改进

4. 正因为 ZAB 协议的特点，所以 Zookeeper 是一个 CP 框架

2PC 算法

1. 2PC(Two Phase Commit) ，二阶段提交，顾名思义，将请求的完成过程拆分成了 2 个阶段

2. 在 2PC 算法中，包含了两类角色：协调者 (negotiator) 和参与者 (participants)

3. 过程

   1. 请求阶段：协调者收到请求之后，不会立即决定这个请求是否执行，而是会将这个请求发送

给所有的参与者，要求所有的参与者在规定时间内进行反馈

   2. 提交阶段：当协调者在 规定时间内 收到 所有 参与者返回的 yes ，那么就表示这个请求可以执

行，此时协调者命令所有的参与者执行这个请求 3. 中止阶段：当协调者没有在规定时间内收到所有参与者的 yes ，那么此时协调者就会放弃这个请求并且命令所有的参与者也放弃这个请求

4. 2PC 只会执行两个阶段：请求 - 提交，请求 - 中止

5. 2PC 的核心思想是 " 一票否决 "

6. 2PC 的优势和劣势都非常明显

    1. 优势：理解和实现过程都会非常简单

    2. 劣势：会非常受外部环境影响。当集群规模较大的时候， 2PC 基本不可能成功

7. 2PC 提供了一种思路：在分布式环境中，如何就一个请求达成所有节点的一致性

PAXOS 算法

1. PAXOS 算法是兰伯特在 1998 年发表的一篇论文 <PAXOS Made Simple> 首次提出，后来兰伯特在2001年的时候才发表了这个算法的推论过程，并且兰伯特凭此获得了图灵奖

2. 故事背景：在一个 PAXOS 小岛上，生活着一群人，这群人由议会管理，议会中的每一个议员都不是专职的而是兼职的，这也就意味着每一位议员都会随时参与议会提案的决策，也随时都会撤离。那么此时，如何就一项提案达成一个一致性的意见？

3. PAXOS 算法解决的问题：如何在不稳定网络中达成集群的一致性

4. PAXOS 算法中包含了 3 类角色

    1. Proposer ：提议者，负责提出提案 (Proposal)

    2. Acceptor ：接受者，接收并且回应提案

    3. Learner ：学习者，不参与决策，而是学习最后的效果

5. 一个节点既可以是 Proposer ，也可以是 Acceptor

6. PAXOS 算法过程

   1. Prepare( 准备 ) 阶段

   1. Proposer 会先给自己的提案生成一个全局唯一且递增的编号 Proposal ID ，并且给

Acceptor 发送 Propose 请求。注意，此时这个请求中没有携带具体的请求内容，只是携

带 Proposal ID

   2. Acceptor 接收到 Proposer 的请求之后，会进行 Promise( 承诺 ) ：

   1. 不再接收 Proposal ID 小于等于当前编号的 Propose 请求

   2. 不再接收 Proposal ID 小于当前提案的 Accept 请求

   3. 在不违背承诺的前提下， Acceptor 回复给 Proposer 当前接收到的最大的 Proposal

ID ，如果没有则返回 null

2. Accept( 接受 / 表决阶段

   1. Proposer 在接收到半数及以上的 Acceptor 返回的 Promise 之后，会要求所有的 Acceptor

执行刚才的提案

   2. Acceptor 在不违背承诺的前提下，会处理这个 Proposal

   3. Learn( 学习 ) 阶段： Proposal 执行完成之后， Learner 会执行这个请求

7. PAXOS 算法可能会导致产生活锁

原子广播

1. 原子广播，依赖于 ZAB 协议来实现了 数据一致性 。基于 ZAB 协议， Zookeeper 实现了一种类似于主从结构的特点

2. 不同于 PAXOS 算法的地方在于，在 ZAB 协议中，只允许一个角色 (leader) 进行提案，并且在集群中只能有一个leader( 全局唯一 ) ，从而避免产生活锁问题

3. 过程

     1. leader 接收到请求之后，会先将这个请求记录到本地的日志文件中

     2. 如果记录成功，那么 leader 会为这个请求生成一个唯一的编号 ( 事务 id ， Zxid) ，然后将 Zxid 放

到队列中，发送给每一个 follower

     3. follower 收到队列之后，会从队列中依次取出请求，记录到本地的日志文件中。如果记录成

功，那么会给 leader 返回一个 ACK(Acknowledge Character ，确认字符 ) 表示确认；如果记录

失败，那么会给 leader 返回一个失败信息

    4. 如果 leader 收到半数及以上的 follower 返回的 ACK ，那么就表示这个请求可以执行，那么此时

leader 就会命令所有的 follower 以及 observer 执行这个请求；反之，就会命令所有的 follower

以及 observer 放弃这个请求

4. 日志文件的位置由 dataLogDir 属性决定，但是 dataLogDir 的值默认和 dataDir 一致

5. 查看 log 文件

6. 查看快照文件

7. 如果 follower 记录失败，那么还需要执行这个请求，此时 follower 会给 leader 发送请求，请求获取

刚才任务的事务 id ，重新记录，记录成功，则执行这个任务；如果记录失败，那么会重新请求重新

记录

8. 如果一个节点加入了 Zookeeper ，这个节点会先找到自己最大的事务 id ，然后自己的最大事务 id 发

送给 leader ， leader 收到之后，会将欠缺的事务放入队列中发送给这个 follower ， follower 收到之

后，回依次从队列中取出请求依次记录执行。这个节点在补齐期间，不对外接收写操作

9. 注意： Zookeeper 所有的节点都能接收请求，如果是读请求，那么直接处理回复；如果 follower 接收到了写请求，会将这个请求转给leader ，进行原子广播

CAP 理论

概述

1. 对于分布式框架而言，基本上都会遵循 CAP 三大理论

2. CAP(CAP 理论是从客户端角度出发的！！！ )

1. C(Consistency) ：一致性。在一段时间内，访问这个集群获取到的数据是相同的 。注意，此

时，在一个时间段内，不要求每一台服务器的数据都一样，只要保证客户端获取到的数据一

样就行

2. A(Availability) ：可用性。当客户端对集群中的节点发起请求的时候，节点能够在合理的时间

内 ( 一般理解为立刻 ) 进行响应 - 时效性。注意，此处的可用性和服务器的高可用不是一回事

儿！！！

3. P(Partition Tolerance) ：分区容忍性。当集群中的某一个或者一部分节点产生故障的时候，

不会影响集群其他功能的使用和运行。注意，服务器的高可用指的是分区容忍性

3. CAP 经过严格的理论证明，无法同时满足。对于集群而言，首先要考虑满足 P ，所以一个集群要么是CP 结构要么是 AP 结构

一致性方式

# 从 Zookeeper3.5.5 开始，提供了 zkTxnLogToolkit.sh ；在 3.5.5 之前，通过 LogFormatter 类

来查看

zkTxnLogToolkit.sh log.200000001

zkSnapShotToolkit.sh snapshot.100000000 1. 强一致性：当一个节点上的数据发生变化的时候，其他节点能够立即感知这个变化并作出对应相应

2. 弱一致性：当一个节点上的数据发生变化的时候，其他节点能够部分感知这个变化或者对变化没有感知

3. 最终一致性：忽略中间过程，最终结果相同

一致性实现方案

1. 主从 (Master-Slave ，简称为 M/S) 结构：通过一个主节点来管理其他的从节点，客户端只能通过访问主节点来获取数据

2. PAXOS 算法及其变种，例如 ZAB 协议就是 PAXOS 的变种算法

3. WNR 策略。 W 表示写入节点数量， R 表示读取节点数量， N 表示总节点数量，只要保证 W+R>N ，就能保证数据一致性