目录


安装及配置

准备工作:

接下来创建 ZooKeeper 3.7.0 伪集群:


Paxos 简介

ZooKeeper 在恢复模式下,选举 Leader 使用的是 Paxos 算法。Paxos 是一种分布式一致性算法,其解决的问题是:分布式系统如何就一个值达成一致。在 Paxos 中,多个节点之间就同一个值达成一致的过程叫 Paxos Instance

在 Basic Paxos 算法中,主要有两类角色:

paxos.png

如上图所示,Paxos 分为两个阶段:

通过上述流程可知,在并发情况下,Paxos 存在活锁问题:

livelock.png

  1. S1 作为提议者,发起 Prepare(3.1),并在 S1、S2、S3 达成多数派
  2. S5 作为提议者,发起 Prepare(3.5),并在 S3、S4、S5 达成多数派
  3. S1 发起 Accept(3.1,value1),由于 S3 上 3.5 > 3.1,导致 Accept 请求无法达成多数派,S1 尝试重新生成提议
  4. S1 发起 Prepare(4.1),并在 S1、S2、S3 达成多数派
  5. S5 发起 Accpet(3.5,value5),由于 S3 上提议 4.1 > 3.5,导致 Accept 请求无法达成多数派,S5 尝试重新生成提议
  6. S5 发起 Prepare(5.5),并在 S3、S4、S5 达成多数派,导致后续 S1 发起的 Accept(4.1,value1)失败
  7. ......

Paxos 的特点是:每个 Proposer 都可以提出 value,但 Proposer 不会“坚持”自己的 value,而是通过 Prepare 阶段,去“学习”其它 Proposer 提出的 value(图 1 中的第 4 步)。


ZooKeeper 的基本原理

ZooKeeper 集群中的角色主要有以下三类:

角色描述
Leader负责发起提议;更新系统状态
Follower负责接受客户端请求,向客户端返回结果(在收到写请求时 Forward 给 Leader);选举过程中参与投票
Observer与 Follower 类似,但在选举过程中不参与投票,只同步 Leader 的状态。Observer 的存在是为了扩展系统,提高读取速度
Client请求的发起者

系统模型如下所示:

xitongmoxing.jpg

ZooKeeper 的特性:


ZooKeeper 的基本概念

ZooKeeper 的数据模型和 Unix 文件系统很像,都是具有层级关系的树形结构。ZooKeeper 中的每个节点叫 ZNode,ZNode 可以用其路径唯一标识(注意:ZNode 只能使用绝对路径表示,不能使用相对路径表示。除根节点外,路径名不能以 “/” 结尾)。每个 ZNode 可以存储少量数据(默认是1M,可配置注意:因为 ZooKeeper 在运行时会把 ZNode 加载进内存,所以不建议在 ZNode 上存储大量数据。)。另外,ZNode上还存储 ACL 信息,ZNode 的 ACL 和 Unix 文件系统的 ACL 完全不同,每个 ZNode 的 ACL 互相独立,子节点不会继承父节点的 ACL,关于 ZooKeeper 的 ACL,请参考其它文章。

shujumoxing.jpg

下面通过示例,看一下 ZNode 的属性:

下面以数据版本号为例,说明版本号的作用。假设实现 AtomicInteger,该数据类型提供原子的 incr <number> 操作。那么 ZooKeeper Client 的做操可能是:

如果在 set 时,不校验版本号,那么可能导致其它客户端的更新丢失。

接下来介绍 ZooKeeper 的 Watch 特性:

ZooKeeper 支持 Watch 操作,Client 可以在 ZNode 上设置 Watcher(比如 get -w /test-node),当 ZNode 发生相应的变化时,会触发 Watcher,把发生的事件通知给设置 Watcher 的 Client。需要注意的是:Watcher 是一次性的,即触发一次之后,就会被取消,如果想继续 Watch,Client 需要重新设置 Watcher。


ZooKeeper 的客户端 API

使用命令行客户端连接到 ZooKeeper,即可执行命令:

ZooKeeper 支持如下命令:

下面使用一些示例进行说明:


ZooKeeper 的应用


两阶段提交和 Zab 协议

两阶段提交用来保证分布式事务的原子性,两阶段提交中的角色分为:协调者(1 个)和参与者(多个),其过程如下:

  1. 协调者记录 Prepare T 日志,并向所有参与者发送 Prepare T 消息

    • 参与者收到 Prepare T 消息后,在自身执行事务的预处理,此时存在两种情况:

      • 如果参与者可以提交事务,那么记录日志,并返回 Ready T
      • 如果参与者不能提交事务,那么撤销自身的修改;记录日志;返回 Not Commit T

ZooKeeper Atomic Broadcast(简称 ZAB,Zookeeper 原子消息广播协议)是 ZooKeeper 保证数据一致性的核心算法。它分为两种模式:

ZAB 的崩溃恢复需要保证以下两种情况:

leader-commit.jpg

Server1 是 Leader,C2 在 Leader 上完成事务提交,但在通知 Follower 服务器 Commit 时挂掉,保证 C2 在 Server2 和 Server3 上提交

leader-prepare.jpg

假设初始的 Leader Server1 在提出事务 Proposal3(P3)后,还没有给 Follower 发送请求时宕机,那么丢弃 P3

ZAB 选举算法要求:


参考文档