Zookeeper高频面试题整理（入门到精通）

文章目录

1、什么是Zookeeper？

Zookeeper 翻译过来就是动物园管理员，他是用来管 Hadoop (大象) 、Hive(蜜蜂)、Pig（小猪)的管理员，简称zk。

Zookeeper是 Apache Hadoop项目下的一个子项目，是一个开源的

分布式协调服务

。

提供的主要功能包括：

配置管理

、

命名服务

、

分布式同步

、

分布式锁

、

集群管理

。

2、ZooKeeper的基本数据结构是什么？

ZooKeeper使用

树形

数据结构，类似于

文件系统的目录结构

，拥有一个层次化结构，节点称为

Znode

。

每个Znode节点上都会保存自己的

数据

和

节点信息

,并且有一个

唯一的路径

。

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

每个节点的存放数据上限为1M

。

**

节点内容

**:二进制数组 (bvte data[]）
用来存储节点的数据、ACL访问控制、子节点数据 (因为临时节点不允许有子节点，所以其子节点字段为null)，记录自身状态信息的stat。
stat +节点路径可以查看状态信息
czxid:创建节点的事务id
mzxid:最后一次被更新的事务id
pzxid:子节点最后一次被修改的事务id
ctime: 创建时间
mtime:最后更新时间
version: 版本号、表示的是对节点数据内容，子节点信息或ACL信息的修改次数可以避免并发更新问题，使用之前获取的版本进行CAS操作更新
cversion:子节点版本号
aversion: acl的版本号
ephemeralOwner: 创建节点的sessionld，如果是持久节点、值为0dataLenght: 数据内容长度

3、Zookeeper的节点类型有哪些？

• 持久节点（Persistent znode）：创建后一直存在，直到显式删除。
• 临时节点（Ephemeral znode）：客户端会话存在期间存在，客户端会话结束后临时节点被删除。
• 持久顺序节点（Persistent Sequential znode）：顺序节点是在创建时自动分配一个顺序号，用于唯一标识。
• 临时顺序节点（Ephemeral Sequential znode）

持久节点适用于存储配置信息等长期数据，临时节点适用于存储临时状态等短期数据。

4、Zookeeper的特点

• 最终一致性：客户端看到的数据最终是一致的。
• 可靠性：服务器保存了消息，那么它就一直都存在。
• 实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据。
• 独立性（等待无关）：不同客户端直接互不影响。
• 原子性：更新要不成功要不失败，没有第三个状态。

5、ZooKeeper如何保证数据一致性？

通过分布式一致性算法ZAB (ZooKeeper Atomic Broadcast)。

6、什么是ZAB协议？

ZAB协议是一种

原子广播协议

，保证所有ZooKeeper服务器上的数据一致性。包含

崩溃恢复

和

消息广播

两部分。

ZAB协议的工作流程：

• 领导者选举： 系统初始化时或现有领导者失效时，所有节点通过选举过程选出新的领导者。选举过程依赖于Zookeeper的选举算法，如Fast Paxos变种。
• 数据同步： 新的领导者选出后，必须与跟随者同步数据。领导者会发送最新的事务日志给跟随者，确保所有节点的状态一致。
• 事务广播： 领导者接收到客户端的写请求后，将请求转换成事务，并将事务广播给所有跟随者。跟随者接收到事务后记录日志，并向领导者发送确认。
• 提交（Commit）： 一旦领导者接收到多数（过半数）跟随者的确认，便会提交该事务并将其应用到自己的状态机。随后，领导者会将提交通知发送给所有跟随者，指示它们也应用该事务。
• 故障恢复： 如果领导者失效，ZAB协议会通过重新选举新领导者来恢复系统的正常运行。新的领导者通过数据同步和事务广播机制确保系统继续保持一致性。

zk保证最终一致性
如果写请求落在了follow节点，也会转交给leader处理

7、Zookeeper的ACL机制是什么？

ACL（Access Control List）用于控制对znode的访问权限，分为创建、删除、读取、写入和管理权限。

ACL包括两个部分：scheme和id。scheme表示认证方案，如world、auth、digest等。id表示认证方案对应的标识符，如anyone、username、password等。Zookeeper提供了一些API来设置和获取ACL。

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

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

9、Zookeeper 常用命令

1）Zookeeper 服务端常用命令

启动 ZooKeeper 服务: ./zkServer.sh start
查看 ZooKeeper服务状态: ./zkServer.sh status
停止 ZooKeeper 服务: ./zkServer.sh stop
重启 ZooKeeper 服务: ./zkServer.sh restart

2）Zookeeper 客户端常用命令

链接服务端：

# 连接ZooKeeper服务端 
/zkCli.sh -server ip:port
# 查看指定节点下的子节点目录ls / #[zookeeper]# 继续查看下一级节点ls /zookeeper
# 创建节点app1 ，内容存test
create /app1 test# 获取节点app1内容
get /app1
# 修改节点app1 ，内容存test2set /app1 test2
# 删除节点
delete /app1
# 创建节点app1的子节点
create /app1/apppp1
create /app1/apppp2
# 删除apppp1
delete /app1/apppp1
# 删除带有子节点的节点
deleteall /app1

创建不同类型节点命令
# 创建临时节点
create -e /app1
# 创建顺序节点
create -s /app1
# 创建临时顺序节点
create -es /app1
# 查询节点详细信息ls-s /节点path

10、ZooKeeper JavaAPI 操作

常见的ZooKeeper Java APl:

• 原生Java API不好用
• ZkClient
• Curator

Curator项目的目标是简化ZooKeeper 客户端的使用.
Curator 最初是 Netfix研发的,后来捐献了 Apache基金会目前是Apache 的顶级项目。

注：Curator是 Apache ZooKeeper 的Java客户端库,所以使用时也要注意和zk的版本问题。

11、Zookeeper的Watcher机制是什么？

Zookeeper的Watcher机制是一种

事件通知机制

，用于监听Znode的变化。

当Znode发生变化时，Zookeeper会通知客户端，客户端可以注册Watcher来监听这些事件。

Watcher是一次性的

，即一旦触发一次事件，Watcher就失效了，需要重新注册。

Curator入了 Cache 来实现对 ZooKeeper 服务端事件的监听。ZooKeeper提供了三种Watcher:

• NodeCache: 只是监听某一个特定的节点
• PathChildrenCache:监控一个ZNode的子节点
• TreeCache:可以监控整个树上的所有节点，类似于PathChildrenCache和NodeCache的组合

newZooKeeper(String connectString,int sessionTimeout,Watcher watcher）
#这个watcher将作为整个ZooKeeper会话期间的上下文，一直被保存在客户端ZKWatchManager的defaultWatcher

也可以动态添加watcher: getData0,exists,getChildren会覆盖上边默认的watcher。

Zookeeper 允许客户端向服务端的某个 znode 注册一个 Watcher 监听，当服务端的一些指定事件，触发了这个 Watcher ，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。大致分为三个步骤：

客户端注册 Watcher

1、调用 getData、getChildren、exist 三个 API ，传入Watcher 对象。

2、标记请求request ，封装 Watcher 到 WatchRegistration 。

3、封装成 Packet 对象，发服务端发送request 。

4、收到服务端响应后，将 Watcher 注册到 ZKWatcherManager 中进行管理。

5、请求返回，完成注册。

服务端处理 Watcher

1、服务端接收 Watcher 并存储。

2、Watcher 触发

3、调用 process 方法来触发 Watcher 。

客户端回调 Watcher

1，客户端 SendThread 线程接收事件通知，交由 EventThread 线程回调Watcher 。

2，客户端的 Watcher 机制同样是一次性的，一旦被触发后，该 Watcher 就失效了。

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

12、ZooKeeper分布式锁原理

ZooKeeper分布式锁核心思想:当客户端要获取锁，则创建节点，使用完锁，则删除该节点。

ZooKeeper可以用于实现分布式锁，主要的思路是利用ZooKeeper的

临时

顺序

节点唯一性和顺序性的特点来实现。具体实现步骤:

1.创建一个ZooKeeper节点作为锁的根节点，例如 /locks
2.当一个线程需要获取锁时，它在锁的根节点下创建一个临时顺序节点，例如 /locks/lock-0001，
并尝试获取锁。
3.线程获取锁的过程是通过检查它创建的节点是否是锁节点下最小的节点，如果是，则表示该线程获得了锁;否则，线程监听它创建节点的前一个节点，等待前一个节点的释放。
4.当线程释放锁时，它删除自己创建的节点

这种方式实现的分布式锁具有一定的可靠性和性能，但需要确保ZooKeeper集群的可用性和性能足够好。同时，需要处理连接断开、会活过期等异常情况，以保证分布式锁的正确性。此外，还可以使用ZooKeeper的超时机制来处理死锁等问题.

如果持久化节点，宕机了锁就没办法删除，因为要找最小的，所以是顺序节点，而且用临时顺序节点，如果某个客户端创建临时顺序节点之后，自己宕机了，除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队。解决了惊群效应

13、ZooKeeper集群

在一个集群中，最少需要 3 台。或者保证 2N + 1 台，即奇数。

为什么保证奇数？主要是为了选举算法、稳定性和可用性。

集群搭建至少需要三套的zoo.cfg和三个myid文件
其中一个节点zoo.cfg配置内容为例：

tickTime=2000initLimit=10syncLimit=5dataDir=/tmp/zookeeper/data1
admin.serverPort=8081clientPort=2181server.1=192.168.65.66:1888:1887
server.2=192.168.65.66:2888:2887
server.3=192.168.65.66:3888:3887

启动一个节点是不可用的，启动2个以上才可用

在目录/tmp/zookeeper/data1下需要创建一个

myid

文件，文件内容为1
对应上边文件中的server.1中的1

选举PK：优先比zxid大小(zxid大的数据更新)，一样再比myid

14、ZooKeeper集群存在脑裂问题吗

ZooKeeper

脑裂

是指一个集群环境中

出现了多个Master节点

，导致数据不一致和数据问题。这种情况通常发生在网络故障导致集群中部分节点失去与Master节点的连接。而在这些节点看来，Master节点已经失效，因此它们会选举新的Master节点。在这个过程中，可能会出现多个Master节点，导致脑裂问题。

假设6个节点，部署两个机房：
第一种3-3分，如果一个机房挂掉，和leader保持心跳的节点不到半数以上了，也就是没有4个了，那就不会工作了，也就没有脑裂问题
另一种：4-2分，如果一个机房挂掉，leader节点通讯的节点仍然有4个，那么不影响任何，继续工作，也不会产生脑裂。

所以

ZooKeeper选举过半机制决定了不会产生脑裂问题

。

15、zk的初始化选举和崩溃选举过程

关键信息：zxld:事务id，sld:节点id

先对比zxld，再对比sld，先投自己，选票内容 (zxld，sld)，遇强改投

投票箱:每个节点在本地维护自己和其他节点的投票信息，改投时需要更新信息，并广播

节点状态:

• LOOKING，竞选状态。
• FOLLOWING，随从状态，同步leader状态，参与投票
• OBSERVING，观察状态,同步leader状态，不参与投票
• LEADING，领导者状态

初始化选举:没有历史数据，5个节点为例

• 节点1启动，此时只有一台服务器启动，它发出去的请求没有任何响应,所以它的选举状态一直是LOOKING状态
• 节点2启动，它与节点1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以serverld值较大的服务器2胜出,但是由于没有达到半数以上，所以服务器1,2还是继续保持LOOKING状态
• 节点3启动，与1、2节点通信交互数据，服务器3成为服务器1.2.3中的leader，此时有三台服务器选举了3，所以3成为leader
• 节点4启动，理论上服务器4应该是服务器1,2,3,4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能切换为follower

崩溃选举：

• leader故障后，follower进入looking状态变更状态
• 各节点投票，先投自己 (zxld，sld)，再广播投票
• 接收到投票，对比zxld和sld，如果本节点小、则将票改为接收的投票信息，并记录投票信息，重新广播。否则本节点大、则可不做处理
• 统计本地投票信息，超过半数，则切换为leading状态并广播

16、zk的数据同步原理

根据这三个参数的大小对比结果，选择对应的数据同步方式。

• peerLastZxid:(Follower或observer) 最后处理的zxid.【也就是从节点目前最新数据是什么】
• minCommittedLog: Leader服务器proposal缓存队列committedLog中的最小的zxid
• maxCommittedLog: Leader服务器proposal缓存队列committedLog中的最大的zxid

Zookeeper中数据同步一共有四类，如下

• DIFF: 直接差异化同步 peerlastZxid介于minCommittedLog和maxCommittedLog之间
• TRUNC+DIFF: 先回滚再差异化 当Leader服务器发现某个Learner包含了一条自己没有的事务记录那么就需要让该Learner进行事务回滚到Leader服务器上存在的
• TRUNC: 仅回滚同步 peerlastZxid大于maxCommittedLog，Leader会要求Learner回滚到ZXID值为maxCommitedLog对应的事务操作
• SNAP:全量同步
• peerLastZxid 小于minCommittedLog

17、Zookeeper 的典型应用场景

Zookeeper 的典型应用场景包括:

• 1.数据发布与订阅：这是 Zookeeper 的一种典型应用场景。发布者将数据发布到 Zookeeper 节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新
• 2.分布式锁: Zookeeper 可以用来实现分布式锁。利用 Zookeeper 的节点唯一性和顺序性特点，可以保证多个线程在尝试获取锁时按照一定的顺序进行
• 3.集群管理: Zookeeper 可以帮助构建分布式系统，提供集群管理的功能，包括节点监控、异常处理、状态同步等。
• 4.分布式协调: Zookeeper 可以为分布式系统中的各个参与者提供一个协调器，处理各种协调操作，例如任务分配、等待与通知等
• 5.命名服务: Zookeeper 可以作为一个分布式命名服务，为网络中的对象提供唯一的名称。

18、请谈谈ZooKeeper对事务性的支持

ZooKeeper对于事务性的支持主要依赖于四个函数，zoo_create_op init、zoo _delete_op init、zoo set op init以及zoo check op init。

每一个函数都会在客户端初始化一个operation，客户端程序有义务保留这些operations.当准备好一个事务中的所有操作后，可以使用

zoo_multi

来提交所有的操作，由zookeeper服务来保证这一系列操作的原子性。也就是说只要其中有一个操作失败了，相当于此次提交的任何一个操作都没有对服务端的数据造成影响。Zoo multi的返回值是第一个失败操作的状态信号

19、简述zk中的观察者机制

peerType=observer
server.1:locahost:2181:3181:observer

观察者的设计是希望能动态扩展zookeeper集群又不会降低写性能。

如果扩展节点是follower，则写入操作提交时需要同步的节点数会变多，导致写入性能下降，而follower又是参与投票的、也会导致投票成本增加

observer

是一种新的节点类型，解决扩展问题的同时，

不参与投票

、只获取投票结果，同时也可以处理读写请求，写请求转发给leader。负责接收leader同步过来的提交数据，

observer的节点故障也不会影响集群的可用性

。

跨数据中心部署。把节点分散到多个数据中心可能因为网络的延迟会极大拖慢系统。使用observer的话，更新操作都在一个单独的数据中心来外理，并发送到其他数据中心，让其他数据中心的节点消费数据.

无法完全消除数据中心之间的网络延迟，因为observer需要把更新请求转发到另一个数据中心的leader，并处理同步消息，网络速度极慢的话也会有影响，它的优势是

为本地读请求提供快速响应

。

20、 ZooKeeper 的持久化机制

ZooKeeper的持久化机制是保证数据可靠性和一致性的重要部分。持久化机制主要通过

事务日志

（Transaction Log）和

快照

（Snapshot）实现，确保在系统故障恢复时可以重新构建最新状态。

Zookeeper的持久化机制主要涉及两种数据存储方式: 内存存储和磁盘存储。

1.内存存储:这是ZooKeeper默认的存储方式。在内存存储中，ZooKeeper所有数据保存在内存中，而不是磁盘上。当ZooKeeper关闭或发生故障时、内存中的数据会丢失。为了提高性能ZooKeeper采用了

延迟写盘

的策路。即将数据先写入内存，再异步地写入磁盘。这种方式可以减少磁盘/0操作，提高系统的响应速度。

2.磁盘存储:为了解决内存存储数据丢失的问题，ZooKeeper提供了磁盘存储的持久化方式。在磁盘存储中，ZooKeeper将数据保存在磁盘上，并在启动时从磁盘加载数据。为了提高写入性能，Zookeeper采用了两种机制: 快照 (snapshot)和事务日志 (transaction log)。快照是Zookeeper数据树的一个完整拷贝，而事务日志记录了所有的数据更改操作。通过这两种机制，Zookeeper可以在系统故障时恢复数据。

ZooKeeper的持久化机制可以根据实际需求进行选择和设置。对于需要高可用性和实时性的场景，可以选择内存存储，对干需要更可靠性和可恢复性的场景，可以选择磁盘存储。