十一、总结

1、zookeeper 是什么？

　　ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务 ，是 Google 的 Chubby 一个开源的实现，它是集群的管理者 ， 监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作 。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

　　客户端的读请求可以被集群中的任意一台机器处理 ，如果读请求在节点上注册了监听器，这个监听器也是由所连接的 zookeeper 机器来处理。对于写请求 ，这些请求会同时发给其他 zookeeper 机器并且达成一致后，请求才会返回成功 。因此，随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降 。 有序性是 zookeeper 中非常重要的一个特性，所有的更新都是全局有序的 ，每个更新都有一个唯一的时间戳 ， 这个时间戳称为 zxid（Zookeeper Transaction Id） 。而读请求只会相对于更新有序 ，也就是读请求的返回结果中会带有这个 zookeeper 最新的 zxid

2、事务编号 Zxid （事务请求计数器 + epoch ）

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

3、epoch

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

4、Zab 协议有两种模式 - 恢复模式（选主）、广播模式（同步)

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

5、ZAB 协议 4 阶段

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

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

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

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

6、ZAB 协议 JAVA 实现 （ FLE-发现阶段和同步合并为 Recovery Phase（恢复阶段） ）

　　协议的Java版本实现跟上面的定义有些不同，选举阶段使用的是FastLeaderElection（FLE），它包含了选举的发现职责。因为FLE会选举拥有最新提议历史的节点作为leader，这样就省去了发现最新提议的步骤。实际的实现将发现阶段和同步合并为RecoveryPhase（恢复阶段）。所以，ZAB的实现只有三个阶段：FastLeaderElection；RecoveryPhase；BroadcastPhase。

 7、Zookeeper  角色

　　Zookeeper 集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种

Leader：

• 一个 Zookeeper 集群同一时间只会有一个实际工作的 Leader，它会发起并维护与各 Follwer 及 Observer 间的心跳

• 所有的写操作必须要通过 Leader 完成再由 Leader 将写操作广播给其它服务器。只要有超过半数节点（不包括 observeer 节点）写入成功，该写请求就会被提交（类 2PC 协议）

Follower

• 一个 Zookeeper 集群可能同时存在多个 Follower，它会响应 Leader 的心跳，

• Follower 可直接处理并返回客户端的读请求，同时会将写请求转发给 Leader 处理，

• 并且负责在 Leader 处理写请求时对请求进行投票。

Observer

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

8、 zookeeper 提供了什么？

　　1、文件系统

　　2、通知机制

9、 zookeeper 文件系统

　　zookeeper提供一个类似unix文件系统目录的多层级节点命名空间（节点称为znode）。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。

10、zookeeper 通知机制

　　client 端会对某个 znode 建立一个watcher 事件，当该 znode 发生变化时，zk会主动通知 watch 这个 znode 的 client，然后 client 根据 znode 的变化来做出业务上的改变等。

watcher 的特点：

• 轻量级：一个 callback 函数。

• 异步性：不会 block 正常的读写请求。

• 主动推送：Watch 被触发时，由 Zookeeper 服务端主动将更新推送给客户端。

• 一次性：数据变化时，Watch 只会被触发一次。如果客户端想得到后续更新的通知，必须要在 Watch 被触发后重新注册一个 Watch。

• 仅通知：仅通知变更类型，不附带变更后的结果。

• 顺序性：如果多个更新触发了多个 Watch，那 Watch被触发的顺序与更新顺序一致。

使用 watch 的注意事项：

• 由于 watcher 是一次性的，所以需要自己去实现永久 watch。

• 如果被 watch 的节点频繁更新，会出现“丢数据”的情况。

• watcher 数量过多会导致性能下降

11、zookeeper 的四种类型的 znode

• PERSISTENT 持久化节点

• PERSISTENT_SEQUENTIAL 顺序自动编号持久化节点，这种节点会根据当前已存 在的节点数自动加 1

• EPHEMERAL 临时节点， 客户端 session 超时这类节点就会被自动删除

• EPHEMERAL_SEQUENTIAL 临时自动编号节点

12、zk的命名服务

　　命名服务是指通过指定的名字来获取资源或者服务的地址，利用zk创建一个全局的路径，即是唯一的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等

13、zk的配置管理服务

　　程序分布式的部署在不同的机器上，将程序的配置信息放在 zk 的 znode 下，当有配置发生改变时，也就是 znode 发生变化时，可以通过改变 zk 中某个目录节点的内容，利用 watcher 通知给各个客户端，从而更改配置。

14、zk的集群管理

　　所谓集群管理无在乎两点：是否有机器退出和加入、选举 master。 对于第一点，所有机器约定在父目录下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper 的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。

　　新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount 又有了，对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master 就好。

15、zk的分布式锁

　　有了 zookeeper 的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

　　保持独占，我们将 zookeeper 上的一个 znode 看作是一把锁，通过 createznode 的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的 distribute_lock 节点就释放出锁。

　　控制时序，/distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选 master 一样，编号最小的获得锁，用完删除，依次方便。

 16、获取分布式锁的流程

　　在获取分布式锁的时候在locker节点下创建临时顺序节点，释放锁的时候删除该临时节点。客户端调用createNode方法在locker下创建临时顺序节点，然后调用getChildren(“locker”)来获取locker下面的所有子节点，注意此时不用设置任何Watcher。客户端获取到所有的子节点path之后，如果发现自己创建的节点在所有创建的子节点序号最小，那么就认为该客户端获取到了锁。如果发现自己创建的节点并非locker所有子节点中最小的，说明自己还没有获取到锁，此时有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建/distribute_lock节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute_lock节点就释放出锁。对于第二类，/distribute_lock已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。

　　在获取分布式锁的时候在locker节点下创建临时顺序节点，释放锁的时候删除该临时节点。客户端调用createNode方法在locker下创建临时顺序节点，然后调用getChildren(“locker”)来获取locker下面的所有子节点，注意此时不用设置任何Watcher。客户端获取到所有的子节点path之后，如果发现自己创建的节点在所有创建的子节点序号最小，那么就认为该客户端获取到了锁。如果发现自己创建的节点并非locker所有子节点中最小的，说明自己还没有获取到锁，此时客户端需要找到比自己小的那个节点，然后对其调用exist()方法，同时对其注册事件监听器。之后，让这个被关注的节点删除，则客户端的Watcher会收到相应通知，此时再次判断自己创建的节点是否是locker子节点中序号最小的，如果是则获取到了锁，如果不是则重复以上步骤继续获取到比自己小的一个节点并注册监听。当前这个过程中还需要许多的逻辑判断。

　　代码的实现主要是基于互斥锁，获取分布式锁的重点逻辑在于BaseDistributedLock，实现了基于 Zookeeper 实现分布式锁的细节。客户端需要找到比自己小的那个节点，然后对其调用 exist()方法，同时对其注册事件监听器。之后，让这个被关注的节点删除，则客户端的 Watcher 会收到相应通知，此时再次判断自己创建的节点是否是 locker 子节点中序号最小的，如果是则获取到了锁，如果不是则重复以上步骤继续获取到比自己小的一个节点并注册监听。当前这个过程中还需要许多的逻辑判断。

　　代码的实现主要是基于互斥锁，获取分布式锁的重点逻辑在于BaseDistributedLock，实现了基于 Zookeeper 实现分布式锁的细节。

 17、zk 队列管理

　　两种类型的队列：

　　    1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目

　　    2、队列按照 FIFO 方式进行入队和出队操作。和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。在特定的目录下创建 PERSISTENT_SEQUENTIAL节点，创建成功时 Watcher 通知等待的队列，队列删除序列号最小的节点用以消费。此场景下 Zookeeper 的 znode 用于消息存储，znode 存储的数据就是消息队列中的消息内容，SEQUENTIAL 序列号就是消息的编号，按序取出即可。由于创建的节点是持久化的，所以不必担心队列消息的丢失问题。

18、zk 数据复制

　　Zookeeper 作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。数据复制的好处：

　　　　1、容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作；

　　　　 2、提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力；

　　　　 3、提高性能：让客户端本地访问就近的节点，提高用户访问速度。

　　从客户端读写访问的透明度来看，数据复制集群系统分下面两种：

　　1、写主(WriteMaster) ：对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离；

　　 2、写任意(Write Any)：对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明。

对 zookeeper 来说，它采用的方式是写任意。通过增加机器，它的读吞吐能力和响应能力扩展性非常好，而写，随着机器的增多吞吐能力肯定下降（这也是它建立 observer 的原因），而响应能力则取决于具体实现方式，是延迟复制保持最终一致性，还是立即复制快速响应。

19、zk 是如何保证事物的顺序一致性

　　zookeeper 采用了递增的事务 Id 来标识，所有的 proposal（提议）都在被提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字，高 32 位是 epoch（时期; 纪元; 世; 新时代）用来标识 leader 是否发生改变，如果有新的 leader产生出来，epoch 会自增，低 32 位用来递增计数。当新产生 proposal 的时候，会依据数据库的两阶段过程，首先会向其他的 server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

20、zk 集群下 server 工作状态

　　每个 Server 在工作过程中有四种状态：

• •  LOOKING：当前 Server 不知道 leader 是谁，正在搜寻

  •  LEADING：当前 server 角色为 leader

  •  FOLLOWING：当前 server 角色为 follower

  •  OBSERVING：当前 server 角色为 observer

21、zk 是如何选举 Leader 的？ 

　　当 leader 崩溃或者 leader 失去大多数的 follower，这时 zk 进入恢复模式，恢复模式需要重新选举出一个新的 leader，让所有的 Server 都恢复到一个正确的状态。Zk 的选举算法有两种：一种是基于 basic paxos 实现的，另外一种是基于 fastpaxos 算法实现的。系统默认的选举算法为 fast paxos。

1、Zookeeper 选主流程(basic paxos)

1. 1. 选举线程由当前 Server 发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的 Server；
   2. 选举线程首先向所有 Server 发起一次询问(包括自己)；
   3. 选举线程收到回复后，验证是否是自己发起的询问(验证 zxid 是否一致)，然后获取对方的 id(myid)，并 存储到当前询问对象列表中，最后获取对方提议的 leader 相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；
   4. 收到所有 Server 回复以后，就计算出 zxid 最大的那个 Server，并将这个 Server 相关信息设置成下一次要投票的 Server；
   5. 线程将当前 zxid 最大的 Server 设置为当前 Server 要推荐的Leader，如果此时获胜的 Server 获得 n/2 + 1 的 Server 票数，设置当前推荐的leader 为获胜的 Server，将根据获胜的 Server 相关信息设置自己的状态，否则，继续这个过程，直到 leader 被选举出来。 通过流程分析我们可以得　　出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于 n+1. 每个 Server 启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的 server 还会从磁盘快照中恢复数据和会 话信息，zk 会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。

　　目前有 5 台服务器，每台服务器均没有数据，它们的编号分别是 1,2,3,4,5,按编号依次启动，它们 的选择举过程如下：

1. 1. 服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器 1 的状态一直属于 Looking。

   2. 服务器 2 启动，给自己投票，同时与之前启动的服务器 1 交换结果，由于服务器 2 的编号 大所以服务器 2 胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是 LOOKING。

   3. 服务器 3 启动，给自己投票，同时与之前启动的服务器 1,2 交换信息，由于服务器 3 的编 号最大所以服务器 3 胜出，此时投票数正好大于半数，所以服务器 3 成为领导者，服务器 1,2 成为小弟。

   4. 服务器 4 启动，给自己投票，同时与之前启动的服务器 1,2,3 交换信息，尽管服务器 4 的 编号大，但之前服务器 3 已经胜出，所以服务器 4 只能成为小弟。

   5. 服务器 5 启动，后面的逻辑同服务器 4 成为小弟。

 2、Zookeeper 选主流程(fast paxos) fast paxos 流程是在选举过程中，某 Server首先向所有 Server 提议自己要成为 leader，当其它 Server 收到提议以后，解决epoch 和 zxid 的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出 Leader。

22、zk 同步流程

　　选完 Leader 以后，zk 就进入状态同步过程。

1. 1. Leader 等待 Follower 和 Observer 连接；

   2. Follower 连接 leader，将最大的 zxid 发送给 leader；

   3. Leader 根据 follower 的 zxid 确定同步点；

   4. 完成同步后通知 follower 已经成为 uptodate 状态；

   5. Follower 收到 uptodate 消息后，又可以重新接受 client 的请求进行服务 了

数据同步的 4 种方式：

　　1、SNAP-全量同步

　　　　• 条件：peerLastZxid<minCommittedLog

　　　　• 说明：证明二者数据差异太大，follower 数据过于陈旧，leader 发送快照 SNAP 指令给 follower 全量同步数据，即 leader 将所有数据全量同步到 follower

　　2、DIFF-增量同步

　　　　• 条件：minCommittedLog<=peerLastZxid<=maxCommittedLog

　　　　• 说明：证明二者数据差异不大，follower 上有一些 leader 上已经提交的提议 proposal未同步，此时需要增量提交这些提议即可

　　3、TRUNC-仅回滚同步

　　　　• 条件：peerLastZxid>minCommittedLog

　　　　• 说明：证明 follower 上有些提议 proposal 并未在 leader 上提交，follower 需要回滚到 zxid 为 minCommittedLog 对应的事务操作

　　4、TRUNC+DIFF-回滚+增量同步

　　　　• 条件：minCommittedLog<=peerLastZxid<=maxCommittedLog

　　　　• 说明：leader a 已经将事务 truncA 提交到本地事务日志中，但没有成功发起 proposal协议进行投票就宕机了；然后集群中剔除原 leader a 重新选举出新 leader b，又提交了若干新的提议 proposal，然后原 leader a 重新服务又加入到集群中说明：此时a,b 都有一些对方未提交的事务，若 b 是 leader, a 需要先回滚 truncA 然后增量同步新 leader b 上的数据。

23、分布式通知和协调

　　对于系统调度来说：操作人员发送通知实际是通过控制台改变某个节点的状态，然后 zk 将这些变化发送给注册了这个节点的 watcher 的所有客户端。对于执行情况汇报：每个工作进程都在某个目录下创建一个临时节点。并携带工作的进度数据，这样汇总的进程可以监控目录子节点的变化获得工作进度的实时 的全局情况。

24、Zookeeper 工作原理

1. Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。
2. 当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。
3. 状态同步保证了leader和server具有相同的系统状态Java研发军团整理https://www.ycbbs.vip=
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都恢复到一个正确的状态

25、zookeeper watch 机制

Watch机制官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。Zookeeper机制的特点：　　

　　1、一次性触发数据发生改变时，一个watcherevent会被发送到client，但是client只会收到一次这样的信息。　　

　　2、watcherevent异步发送watcher的通知事件从server发送到client是异步的，这就存在一个问题，不同的客户端和服务器之间通过socket进行通信，由于网络延迟或其他因素导致客户端在不通的时刻监听到事件，由于Zookeeper本身提供了orderingguarantee，即客户端监听事件后，才会感知它所监视znode发生了变化。所以我们使用Zookeeper不能期望能够监控到节点每次的变化。Zookeeper只能保证最终的一致性，而无法保证强一致性。　　

　　3、数据监视Zookeeper有数据监视和子数据监视getdata()andexists()设置数据监视，getchildren()设置了子节点监视。　　

　　4、注册watchergetData、exists、getChildren　　5、触发watchercreate、delete、setData　　

　　6、setData()会触发znode上设置的datawatch（如果set成功的话）。一个成功的create()操作会触发被创建的znode上的数据watch，以及其父节点上的childwatch。而一个成功的delete()操作将会同时触发一个znode的datawatch和childwatch（因为这样就没有子节点了），同时也会触发其父节点的childwatch。　　

　　7、当一个客户端连接到一个新的服务器上时，watch将会被以任意会话事件触发。当与一个服务器失去连接的时候，是无法接收到watch的。而当client重新连接时，如果需要的话，所有先前注册过的watch，都会被重新注册。通常这是完全透明的。只有在一个特殊情况下，watch可能会丢失：对于一个未创建的znode的existwatch，如果在客户端断开连接期间被创建了，并且随后在客户端连接上之前又删除了，这种情况下，这个watch事件可能会被丢失。　　

　　8、Watch是轻量级的，其实就是本地JVM的Callback，服务器端只是存了是否有设置了Watcher的布尔类型

26、zookeeper 负载均衡和 nginx 负载均衡区别

　　zk 的负载均衡是可以调控，nginx 只是能调权重，其他需要可控的都需要自己写插件；但是 nginx 的吞吐量比zk 大很多，应该说按业务选择用哪种方式

27、机器中为什么会有 leader？

　　在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行， 其他的机器可以共享这个结果 ，这样可以大大 减少重复计算 ， 提高性能 ，于是就需要进行 leader 选举。

28、zk节点宕机如何处理？

　　Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他节点会继续提供服务。如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失；如果是一个Leader宕机，Zookeeper会选举出新的Leader。ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。所以3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5)2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)

29、集群支持动态添加机器吗？

　　其实就是水平扩容了，Zookeeper 在这方面不太好。两种方式：

• 全部重启：关闭所有 Zookeeper 服务，修改配置之后启动。不影响之前客户端的会话。
• 逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。

　　3.5 版本开始支持动态扩容

30、Zookeeper对节点的watch监听通知是永久的吗？为什么不是永久的?

　　不是。官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，给网络和服务器造成很大压力。一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可

31、ZAB和Paxos算法的联系与区别？

相同点：

　　1、两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行

　　2、Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交

　　3、ZAB协议中，每个Proposal中都包含一个epoch值来代表当前的Leader周期，Paxos中名字为Ballot

不同点：

　　ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。