1、Zookeeper 的产生来源

Apache ZooKeeper 是一个高可靠的分布式协调中间件。它是 Google Chubby 的一个开源 实现，那么它主要是解决什么问题的呢？

那就得先了解 Google Chubby，Google Chubby 是谷歌的一个用来解决分布式一致性问题的组件，同时，也是粗粒度的分布式锁服务。

1.1 分布式一致性问题

• 什么是分布式一致性问题呢？

简单来说，就是在一个分布式系统中，有多个节点，每个节点都会提出一个请求，但是在所有节点中只能确定一个请求被通过。而这个通过是需要所有节点达成一致的结果，所以所谓的一致性就是在提出的所有请求中能够选出最终一个确定请求。并且这个请求选出来以后，所有的节点都要知道。

这个就是典型的拜占庭将军问题。

拜占庭将军问题说的是：拜占庭帝国军队的将军们必须通过投票达成一致来决定是否对某一个国家发起进攻。但是这些将军在地理位置上是分开的，并且在将军中存在叛徒。叛徒可以通过任意行动来达到自己的目标：

1. 欺骗某些将军采取进攻行动；
2. 促使一个不是所有将军都统一的决定，比如将军们本意是不希望进攻，但是叛徒可以促成进攻行动；
3. 迷惑将军使得他们无法做出决定，如果叛徒达到了任意一个目标，那么这次行动必然失败。只有完全达成一致那么这次进攻才可能胜利。

拜占庭问题的本质是，由于网络通信存在不可靠的问题，也就是可能存在消息丢失，或者网络延迟。如何在这样的背景下对某一个请求达成一致。

所以，分布式一致性的本质，就是在分布式系统中，多个节点就某一个提议如何达成一致。

• 这个和 Google Chubby 有什么关系呢？
  在 Google 有一个 GFS(google file system)，他们有一个需求就是要从多个 gfs server 中选出 一个 master server。这个就是典型的一致性问题，5 个分布在不同节点的 server，需要确定 一个 master server，而他们要达成的一致性目标是：确定某一个节点为 master，并且所有节点要同意。

而 GFS 就是使用 chubby 来解决这个问题的。
实现原理是：所有的 server 通过 Chubby 提供的通信协议到 Chubby server 上创建同一个文件，当然，最终只有一个 server 能够获准创建这个文件，这个 server 就成为了 master，它会在这个文件中写入自己的地址，这样其它的 server 通过读取这个文件就能知道被选出的 master 的地址。

1.2 分布式锁服务

从另外一个层面来看，Chubby 提供了一种粗粒度的分布式锁服务，chubby 是通过创建文件的形式来提供锁的功能，server 向 chubby 中创建文件其实就表示加锁操作，创建文件成功表示抢占到了锁。

由于 Chubby 没有开源，所以雅虎公司基于 chubby 的思想，开发了一个类似的分布式协调 组件 Zookeeper，后来捐赠给了 Apache。

所以，大家一定要了解，zookeeper 并不是作为注册中心而设计，他是作为分布式锁的一种设计。而注册中心只是他能够实现的一种功能而已。

2、zookeeper 的设计猜想

基于 Zookeeper 本身的一个设计目标，zookeeper 主要是解决分布式环境下的服务协调问题 而产生的，我们来猜想一下，如果我们要去设计一个 zookeeper，需要满足那些功能呢?

2.1 防止单点故障

首先，在分布式架构中，任何的节点都不能以单点的方式存在，因此我们需要解决单点的问题。常见的解决单点问题的方式就是集群。

大家来思考一下，这个集群需要满足那些功能?

1. 集群中要有主节点和从节点(也就是集群要有角色)；
2. 集群要能做到数据同步，当主节点出现故障时，从节点能够顶替主节点继续工作，但是继续工作的前提是数据必须要主节点保持一致；
3. 主节点挂了以后，从节点如何接替成为主节点? 是人工干预？还是自动选举？

所以基于这几个点，我们先来把 zookeeper 的集群节点画出来。

• Leader 角色
  Leader 服务器是整个 zookeeper 集群的核心，主要的工作任务有两项：

1. 事物请求的唯一调度和处理者，保证集群事物处理的顺序性；
2. 集群内部各服务器的调度者。

• Follower 角色
  Follower 角色的主要职责是：

1. 处理客户端非事务请求、转发事务请求给leader服务器；
2. 参与事务请求 Proposal 的投票(需要半数以上服务器通过才能通知 leader commit 数据; Leader 发起的提案，要求 Follower 投票)；
3. 参与 Leader 选举的投票。

2.2 数据同步

接着上面那个结论再来思考，如果要满足这样的一个高性能集群，我们最直观的想法应该是，每个节点都能接收到请求，并且每个节点的数据都必须要保持一致。要实现各个节点的数据一致性，就势必要一个 leader 节点负责协调和数据同步操作。这个我想大家都知道，如果在这样一个集群中没有 leader 节点，每个节点都可以接收所有请求，那么这个集群的数据同步的复杂度是非常大。

所以，当客户端请求过来时，需要满足，事务型数据和非事务型数据的分开处理方式，就是 leader 节点可以处理事务和非事务型数据。而 follower 节点只能处理非事务型数据。原因是， 对于数据变更的操作，应该由一个节点来维护，使得集群数据处理的简化。同时数据需要能 够通过 leader 进行分发使得数据在集群中各个节点的一致性。

leader 节点如何和其他节点保证数据一致性，并且要求是强一致的。在分布式系统中，每一个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败，但是却无法直接获取其他分布式节点的操作结果。所以当一个事务操作涉及到跨节点的时候，就需要用到分布式事务，分布式事务的数据一致性协议有 2PC 协议和 3PC 协议。

2.2.1 关于 2PC 提交

(Two Phase Commitment Protocol)当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的 ACID 特性，就需要引入一个“协调者”™来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点被称为 AP（Application Program，既应用程序）。TM（Transaction Manager，事务管理器） 负责调度 AP 的行为，并最终决定这些 AP 是否要把事务真正进行提交；因为整个事务是分为两个阶段提交，所以叫 2pc。

（1）阶段一：提交事务请求(投票)

1. 事务询问
   协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

2. 执行事务
   各个参与者节点执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中，尽量把提交过程中所有消耗时间的操作和准备都提前完成确保后面 100% 成功提交事务。

3. 各个参与者向协调者反馈事务询问的响应
   如果各个参与者成功执行了事务操作，那么就反馈给参与者 yes 的响应，表示事务可以执行; 如果参与者没有成功执行事务，就反馈给协调者 no 的响应，表示事务不可以执行，上面这个阶 段有点类似协调者组织各个参与者对一次事务操作的投票表态过程，因此 2pc 协议的第一个阶 段称为“投票阶段”，即各参与者投票表明是否需要继续执行接下去的事务提交操作。

（2）阶段二：执行事务提交

在这个阶段，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况 下包含两种可能：执行事务、中断事务。

• 执行事务提交
  假设协调者从所有的参与者获取的反馈都是 Yes 响应，那么就会执行事务提交。

1. 发送提交请求
   协调者向所有参与者节点发送 Commit 请求。

2. 事务提交
   参与者接收到 Commit 请求后，会正式执行事务提交操作，并在完成提交之后释放在正式事务执行期间占用的资源。

3. 反馈事务提交结果
   参与者在完成事务提交之后，向协调者发送 Ack 消息。

4. 完成事务
   协调者接收到所有参与者反馈的 Ack 消息后，完成事务。

• 中断事务
  假设任何一个参与者向协调者反馈 No 响应，或者在等待超时之后，协调者尚无法接受到所有参与者的反馈响应，那么就会中断事务。

1. 发送回滚请求。
   协调者向所有的参与者发送 Rollback 请求。

2. 事务回滚
   参与者接受到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。

3. 反馈事务回滚结果
   参与者在完成事务回滚之后，向协调者发送 Ack 消息。

4. 中断事务
   协调者接受到所有参与者反馈的 Ack 消息后，完成事务中断。

以上就是二阶段提交的过程中，前后两个阶段分别进行的处理逻辑。简单来讲，二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试提交的处理方式，因此也可以将二阶段提交看做一个强一致性的算法

优缺点

• 优点：原理简单，实现方便。

• 缺点：同步阻塞，单点问题，脑裂，太过保守。

1. 同步阻塞
   二阶段提交协议存在的最明显也是最大的一个问题就是同步阻塞，这会极大地限制分布式系统的性能。在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应过程中，将无法进行其他任何操作。

2. 单点问题
   一旦协调者出现问题，那么整个二阶段提交流程将无法运转，更为严重的是，如果协调者是在阶段二中出现问题的话，那么其他参与者将会一直处于锁定事务资源的状态中，无法继续完成事务操作。

3. 数据不一致
   在二阶段提交协议的阶段二，即执行事务提交的时候，当协调者向所有的参与者发送 Commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完 Commit 请求之前自身发送了崩溃，导致最终只有部分参与者收到了 Commit 请求。于是，这部分收到了 Commit 请求的参与者就会进行事务的提交，而其他没有收到 Commit 请求的参与者则无法进行事务提交，于是整个分布式系统就会出现数据不一致现象。

4. 太过保守
   如果在协调者指示参与者进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠自身的超时机制来判断是否需要中断事务，这样的策略显得比较保守。换句话说，二阶段提交协议没有涉及较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。

2.2.2 关于 3PC 提交

了解二阶段提交协议的设计和实现原理，并明确指出了其在实际运行过程中可能存在诸多问题，比如同步阻塞、协调者的单点问题、脑裂和太过保守的容错机制等缺陷，因此研究者在二阶段提交协议的基础上进行了改进，提出了三阶段提交协议。

协议说明
3PC，是 Three-Phase Commit 的缩写，即三阶段提交，是 2PC 的改进版，其将二阶段提交协议的"提交事务请求"过程一分为二，形成了 canCommit，preCommit 和 doCommit三个阶段组成的事务处理协议，协议设计图如下：

• （1）阶段一：canCommit

1. 事务询问

协调者向所有的参与者发送一个包含事务内容的 canCommit 请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

2. 各参与者向协调者反馈事务询问的响应

参与者在接收到来自协调者的 canCommit 请求后，正常情况下，如果其自身认为可以顺利执行任务，那么就会反馈 Yes 响应，并进入预备状态，否则反馈 No 响应。

• 阶段二：preCommit
  在阶段二，协调者会根据各参与者的反馈情况来决定是否进行事务的 PreCommit 操作，正常情况下，包含两种可能。

• 执行事务预提交
  假如协调者从所有的参与者获得的反馈都是 Yes，那么就会执行事务预提交。

1. 发送预提交请求
   协调者向所有参与者节点发出 preCommit 请求，并进入 Prepared 阶段。

2. 事务预提交
   参与者接收到 preCommit 请求后，会执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中。

3. 各参与者向协调者反馈事务执行的响应
   如果参与者成功执行了事务操作，那么就会反馈给协调者 Ack 响应，同时等待最终的指令：提交（commit）或中止（abort）。

• 中断事务
  假如任何一个参与者向协调者反馈了 No 响应，或者在等待超时之后，协调者尚无法接受到所有参与者的反馈响应，那么就会中断事务。

1. 发送中断请求
   协调者向所有的参与者节点发送 abort 请求。

2. 中断事务
   无论是收到来自协调者的 abort 请求，或者是在等待协调者请求过程中出现超时，参与者都会中断事务。

• （3）阶段三：doCommit
  该阶段将进行真正的事务提交，会存在以下两种可能的情况。

• 执行提交

1. 发送提交请求
   进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的 Ack 响应，那么它将从“预提交”状态转换到“提交”状态，并向所有的参与者发送 doCommit 请求。

2. 事务提交
   参与者接收到 doCommit 请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。

3. 反馈事务提交结果
   参与者在完成事务提交之后，向协调者发送 Ack 消息。

4. 完成事务
   协调者接收到所有参与者反馈的 Ack 消息后，完成事务。

• 中断事务
  进入这一阶段，假设协调者处于正常工作状态，并且有任意一个参与者向协调者反馈了 No 响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

1. 发送中断请求
   协调者向所有的参与者节点发送 abort 请求。

2. 事务回滚
   参与者接收到 abort 请求后，会利用其在阶段二中记录的 Undo 信息来执行回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。

3. 反馈回滚结果
   参与者在完成事务回滚之后，向协调者发送 Ack 消息。

4. 中断事务
   协调者接收到所有参与者反馈的 Ack 消息后，中断事务。

需要注意的是，一旦进入阶段三，可能会存在以下两种故障。

（1）协调者出现问题。
（2）协调者和参与者之间的网络出现故障。

无论哪种情况，最终都会导致参与者无法及时接收来自协调者的 doCommit 或是 abort 请求，针对这样的异常情况，参与者都会在等待超时之后，继续进行事务提交。

优缺点

三阶段提交协议的优点：相较于二阶段提交协议，三阶段提交协议最大的优点就是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。

三阶段提交协议的缺点：三阶段提交协议在去除阻塞的同时也引入了新的问题，那就是在参与者接收到 preCommit 消息后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常网络通信，在这种情况下，该参与者依然会进行事务的提交，这必然会出现数据的不一致。

2.3 zookeeper

2.3.1 Observer 角色

Observer 是 zookeeper3.3 开始引入的一个全新的服务器角色，从字面来理解，该角色充当 了观察者的角色。

观察 zookeeper 集群中的最新状态变化并将这些状态变化同步到 observer 服务器上。 Observer 的工作原理与 follower 角色基本一致，而它和 follower 角色唯一的不同在于 observer 不参与任何形式的投票，包括事物请求 Proposal 的投票和 leader 选举的投票。简单来说，observer 服务器只提供非事务请求服务，通常在于不影响集群事物处理能力的前提下提升集群非事务处理的能力。

2.3.2 leader 选举

当 leader 挂了，需要从其他 follower 节点中选择一个新的节点进行处理，这个时候就需要涉及到 leader 选举。

从这个过程中，我们推导处了 zookeeper 的一些设计思想。

2.3.3 集群组成

通常 zookeeper 是由 2n+1 台 server 组成，每个 server 都知道彼此的存在。每个 server 都维护的内存状态镜像以及持久化存储的事务日志和快照。

对于 2n+1 台 server，只要有 n+1 台(大多数)server 可用，整个系统保持可用。我们已经了解到，一个 zookeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信，基于这个特性，如果向搭建一个能够允许 F 台机器 down 掉的集群，那么就要部署 2*F+1 台服务器构成的 zookeeper 集群。

因此 3 台机器构成的 zookeeper 集群，能够在挂掉一台机器后依然正常工作。一个 5 台机器集群的服务，能够对 2 台机器挂掉的情况下进行容灾。 如果一台由 6 台服务构成的集群，同样只能挂掉 2 台机器。因此，5 台和 6 台在容灾能力上并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的 server 会选举出一台 server 为 Leader，其它的就作为 follower(这里先不考虑 observer 角色)。 之所以要满足这样一个等式，是因为一个节点要成为集群中的 leader，需要有超过集群中过半数的节点支持，这个涉及到 leader 选举算法。同时也涉及到事务请求的提交投票。