Zookeeper：常见的面试题和答案

请关注微信公众号：拾荒的小海螺

1、什么是Zookeeper？它的作用是什么？

答： Zookeeper是一个开源的分布式协调服务，提供了一些基本的分布式服务，如配置管理、分布式锁、分布式队列等。其主要作用是帮助分布式应用程序进行协调和管理，确保分布式环境下的数据一致性。

分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。

Zookeeper保证了如下分布式一致性特性：

• 顺序一致性
• 原子性
• 单一视图
• 可靠性
• 实时性（最终一致性）

2、Zookeeper的数据模型是什么？

答： Zookeeper的数据模型是一个分层的命名空间，类似于文件系统的目录结构。每个节点称为一个Znode，Znode可以包含数据和子节点。Znode可以是持久的，也可以是临时的。Zookeeper提供了一些API来操作Znode，如创建、删除、读取和更新等。

Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。

3、 Zookeeper的选举算法是什么？

答： Zookeeper使用的选举算法是基于Paxos协议的Zab（Zookeeper Atomic Broadcast）协议。在一个Zookeeper集群中，有一个Leader节点和多个Follower节点。Leader节点负责处理客户端的读写请求，Follower节点负责与Leader节点保持数据一致性。如果Leader节点故障，则集群会自动选举一个新的Leader节点。

4、Zookeeper的Watcher机制是什么？

答： Zookeeper的Watcher机制是一种事件通知机制，用于监听Znode的变化。当Znode发生变化时，Zookeeper会通知客户端，客户端可以注册Watcher来监听这些事件。Watcher是一次性的，即一旦触发一次事件，Watcher就失效了，需要重新注册。

5、Zookeeper的ACL（访问控制列表）是什么？

答： Zookeeper的ACL是一种权限控制机制，用于限制对Znode的访问。ACL包括两个部分：scheme和id。scheme表示认证方案，如world、auth、digest等。id表示认证方案对应的标识符，如anyone、username、password等。Zookeeper提供了一些API来设置和获取ACL。

6、Zookeeper的持久节点和临时节点有什么区别？

答： 持久节点是指一旦创建，就一直存在，直到主动删除。临时节点是指在客户端与Zookeeper连接断开时，节点会被自动删除。持久节点适用于存储配置信息等长期数据，临时节点适用于存储临时状态等短期数据。

7、Zookeeper的事务日志是什么？

答： Zookeeper的事务日志是一种持久化存储数据的机制，用于保证数据的一致性。当客户端向Zookeeper发送写请求时，Zookeeper会将这些请求写入事务日志中，并在写入成功后才响应客户端。这样可以确保数据的一致性，即使Zookeeper节点发生故障，数据也不会丢失。

8、Zookeeper的Watcher机制有什么缺点？

答： Zookeeper的Watcher机制是一种一次性的事件通知机制，当触发一次事件后，Watcher就会失效。这样可能导致客户端需要重新注册Watcher，增加了客户端的负担。此外，Watcher机制不能保证事件的顺序，有可能出现事件丢失的情况。

9、Zookeeper的会话超时是什么？如何处理会话超时？

答： Zookeeper的会话超时是指客户端与Zookeeper之间的连接超时时间，如果在这个时间内没有收到来自客户端的心跳包，Zookeeper会认为客户端已经断开连接。会话超时的处理方式取决于客户端的实现，一般会有重新连接、重新注册Watcher等操作。

10、Zookeeper的ACL是如何实现的？

答： Zookeeper的ACL是通过一种基于访问控制列表的机制来实现的。Zookeeper将ACL信息存储在每个Znode的metadata中，当客户端发送写请求时，Zookeeper会检查ACL信息，如果不符合要求，会拒绝请求。ACL信息是在创建Znode时设置的，并可以通过setACL方法进行修改。

11、Zookeeper的Observer模式是什么？

答： Zookeeper的Observer模式是一种观察者模式，用于监听Znode的变化。当Znode发生变化时，Zookeeper会通知观察者，观察者可以注册回调函数来处理这些事件。Observer模式是一种异步的事件通知机制，可以提高系统的性能和吞吐量。

12、ZooKeeper提供了什么？

• 文件系统
• 通知机制

13、什么是ZAB协议？

ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。

ZAB协议包括两种基本的模式：崩溃恢复和消息广播。

当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式，首先选举产生新的Leader服务器，然后集群中Follower服务器开始与新的Leader服务器进行数据同步，当集群中超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式，Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。

14、四种类型的数据节点 Znode

• PERSISTENT-持久节点
  除非手动删除，否则节点一直存在于Zookeeper上

• EPHEMERAL-临时节点
  临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。

• PERSISTENT_SEQUENTIAL-持久顺序节点
  基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。

• EPHEMERAL_SEQUENTIAL-临时顺序节点
  基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。

15、Zookeeper 下 Server有哪些工作状态？

答：服务器具有四种状态，分别是LOOKING、FOLLOWING、LEADING、OBSERVING。

• LOOKING： 寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。
• FOLLOWING： 跟随者状态。表明当前服务器角色是Follower。
• LEADING： 领导者状态。表明当前服务器角色是Leader。
• OBSERVING： 观察者状态。表明当前服务器角色是Observer。

16、Zookeeper是如何保证事务的顺序一致性的？

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

17、Zookeeper有哪几种几种部署模式？

答：Zookeeper 有三种部署模式：

• 单机部署：一台集群上运行；

• 集群部署：多台集群运行；

• 伪集群部署：一台集群启动多个 Zookeeper 实例运行。

18、集群最少要几台机器，集群规则是怎样的?

答：集群规则为2N+1台，N>0，即3台。

19、Zookeeper的java客户端都有哪些？

答：zk自带的zkclient及Apache开源的Curator

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

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

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

21、Zookeeper负载均衡和Nginx负载均衡区别

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

• Nginx是反向代理服务器，被广泛用于负载均衡服务器。
  Nginx配置负载均衡非常简单，将多个web service配置到Nginx中，用户访问Nginx时会自动分配一个web service 。
  随着系统的演进，集群中服务器的增加，暴露出Nginx使用弊端：
  a.因为节点变多，配置维护的成本变高；
  b.因为热点服务的访问量很高，所以单点故障的风险增加了；如果这个服务集群内的负载均衡服务出现问题，这个服务将失效。

• Zookeeper是分布式协调服务框架，也会用于负载均衡。
  Zookeeper负载均衡实现思路：把Zookeeper作为一个服务注册中心，在其中登记每个服务，每台服务器知道自己属于哪个服务，在服务器启动时，自己向所属服务进行登记（呈现出一个树形结构）。
  服务的调用者到注册中心里面查找：能提供所需服务的服务器列表，然后自己根据负载均衡算法，从中选取一台服务器进行连接；由于ZooKeeper并没有内置负载均衡策略，需要调用者自己实现。

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

• 相同点：
  （1）两者都存在一个类似于 Leader 进程的角色，由其负责协调多个 Follower 进程的运行
  （2）Leader 进程都会等待超过半数的 Follower 做出正确的反馈后，才会将一个提案进行提交
  （3）ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的 Leader周期，Paxos 中名字为 Ballot
• 不同点：
  ZAB 用来构建高可用的分布式数据主备系统（Zookeeper），Paxos 是用来构建分布式一致性状态机系统。

23、说说Zookeeper中的ACL 权限控制机制

答：UGO（User/Group/Others）目前在 Linux/Unix 文件系统中使用，也是使用最广泛的权限控制方式。是一种粗粒度的文件系统权限控制模式。
ACL（Access Control List）访问控制列表包括三个方面：

• 权限模式（Scheme）
  （1）IP：从 IP 地址粒度进行权限控制
  （2）Digest：最常用，用类似于 username:password 的权限标识来进行权限配置，便于区分不同应用来进行权限控制
  （3）World：最开放的权限控制方式，是一种特殊的 digest 模式，只有一个权限标识“world:anyone”
  （4）Super：超级用户

• 授权对象
  授权对象指的是权限赋予的用户或一个指定实体，例如 IP 地址或是机器码。

• 权限 Permission
  （1）CREATE：数据节点创建权限，允许授权对象在该 Znode 下创建子节点
  （2）DELETE：子节点删除权限，允许授权对象删除该数据节点的子节点
  （3）READ：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内容或子节点列表等
  （4）WRITE：数据节点更新权限，允许授权对象对该数据节点进行更新操作
  （5）ADMIN：数据节点管理权限，允许授权对象对该数据节点进行 ACL 相关设置操作

24、Zookeeper脑裂是什么原因导致的？

答：主要原因是Zookeeper集群和Zookeeper client判断超时并不能做到完全同步，也就是说可能一前一后，如果是集群先于client发现，那就会出现上面的情况。同时，在发现并切换后通知各个客户端也有先后快慢。一般出现这种情况的几率很小，需要leader节点与Zookeeper集群网络断开，但是与其他集群角色之间的网络没有问题，还要满足上面那些情况，但是一旦出现就会引起很严重的后果，数据不一致。

25、Zookeeper 是如何解决脑裂问题的？

答：要解决Split-Brain脑裂的问题，一般有下面几种种方法：

• Quorums (法定人数) 方式:
  比如3个节点的集群，Quorums = 2, 也就是说集群可以容忍1个节点失效，这时候还能选举出1个lead，集群还可用。比如4个节点的集群，它的Quorums = 3，Quorums要超过3，相当于集群的容忍度还是1，如果2个节点失效，那么整个集群还是无效的。这是zookeeper防止"脑裂"默认采用的方法。

• Redundant communications (冗余通信)方式：
  集群中采用多种通信方式，防止一种通信方式失效导致集群中的节点无法通信。

• Fencing (共享资源) 方式：
  比如能看到共享资源就表示在集群中，能够获得共享资源的锁的就是Leader，看不到共享资源的，就不在集群中。要想避免zookeeper"脑裂"情况其实也很简单，follower节点切换的时候不在检查到老的leader节点出现问题后马上切换，而是在休眠一段足够的时间，确保老的leader已经获知变更并且做了相关的shutdown清理工作了然后再注册成为master就能避免这类问题了，这个休眠时间一般定义为与zookeeper定义的超时时间就够了，但是这段时间内系统可能是不可用的，但是相对于数据不一致的后果来说还是值得的。

A、Quorums方式

zooKeeper默认采用了Quorums这种方式来防止"脑裂"现象。即只有集群中超过半数节点投票才能选举出Leader。这样的方式可以确保leader的唯一性,要么选出唯一的一个leader,要么选举失败。在zookeeper中Quorums作用如下：*集群中最少的节点数用来选举leader保证集群可用。通知客户端数据已经安全保存前集群中最少数量的节点数已经保存了该数据。*一旦这些节点保存了该数据，客户端将被通知已经安全保存了，可以继续其他任务。而集群中剩余的节点将会最终也保存了该数据。

假设某个leader假死，其余的followers选举出了一个新的leader。这时，旧的leader复活并且仍然认为自己是leader，这个时候它向其他followers发出写请求也是会被拒绝的。因为每当新leader产生时，会生成一个epoch标号(标识当前属于那个leader的统治时期)，这个epoch是递增的，followers如果确认了新的leader存在，知道其epoch，就会拒绝epoch小于现任leader epoch的所有请求。那有没有follower不知道新的leader存在呢，有可能，但肯定不是大多数，否则新leader无法产生。Zookeeper的写也遵循quorum机制，因此，得不到大多数支持的写是无效的，旧leader即使各种认为自己是leader，依然没有什么作用。zookeeper除了可以采用上面默认的Quorums方式来避免出现"脑裂"，还可以可采用下面的预防措施：

B、添加冗余的心跳线，例如双线条线，尽量减少“脑裂”发生机会。

C、启用磁盘锁。

正在服务一方锁住共享磁盘，“脑裂"发生时，让对方完全"抢不走"共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动"解锁”，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了"智能"锁。即正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。

D、设置仲裁机制。

例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下 参考IP，不通则表明断点就出在本端，不仅"心跳"、还兼对外"服务"的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。

26、Zookeeper 是如何数据同步的？

答：整个集群完成Leader选举之后，Learner（Follower和Observer的统称）会向Leader服务器进行注册。当Learner服务器向Leader服务器完成注册后，进入数据同步环节。

数据同步流程：（均以消息传递的方式进行）

• Learner向Learder注册
• 数据同步
• 同步确认

Zookeeper的数据同步通常分为四类：

• 直接差异化同步（DIFF同步）
• 先回滚再差异化同步（TRUNC+DIFF同步）
• 仅回滚同步（TRUNC同步）
• 全量同步（SNAP同步）

在进行数据同步前，Leader服务器会完成数据同步初始化：

peerLastZxid：从learner服务器注册时发送的ACKEPOCH消息中提取lastZxid（该Learner服务器最后处理的ZXID）
minCommittedLog：Leader服务器Proposal缓存队列committedLog中最小ZXID
maxCommittedLog：Leader服务器Proposal缓存队列committedLog中最大ZXID

• 直接差异化同步（DIFF同步）
  场景：peerLastZxid介于minCommittedLog和maxCommittedLog之间

• 先回滚再差异化同步（TRUNC+DIFF同步）
  场景：当新的Leader服务器发现某个Learner服务器包含了一条自己没有的事务记录，那么就需要让该Learner服务器进行事务回滚–回滚到Leader服务器上存在的，同时也是最接近于peerLastZxid的ZXID

• 仅回滚同步（TRUNC同步）
  场景：peerLastZxid 大于 maxCommittedLog

• 全量同步（SNAP同步）
  场景一：peerLastZxid 小于 minCommittedLog
  场景二：Leader服务器上没有Proposal缓存队列且peerLastZxid不等于lastProcessZxid

27、Zookeeper的使用场景有哪些？

答： Zookeeper的主要使用场景包括配置管理、分布式锁、分布式队列、分布式事务等。Zookeeper提供了一些基本的分布式服务，可以帮助分布式应用程序进行协调和管理，确保数据的一致性。
通过对Zookeeper中丰富的数据节点进行交叉使用，配合Watcher事件通知机制，可以非常方便的构建一系列分布式应用中年都会涉及的核心功能，如：

• 数据发布/订阅
• 负载均衡
• 命名服务
• 分布式协调/通知
• 集群管理
• Master选举
• 分布式锁
• 分布式队列