zookeeper面试题

1.Zookeeper的理解？

Zookeeper是一个开源的分布式协调服务框架，主要负责存储和管理数据，并且接受观察者的注册，一旦关注数据发生变化，zookeeper将通知在其数据注册的观察者。

2. zookeeper特点？

1)zookeeper集群中是由一个领导者，多个跟随着组成
2)集群中只要有半数以上节点存活，zookeeper集群就能正常服务。所以zookeeper适合安装奇数台服务器。
3)全局数据一致性:每个server保存一份相同的数据副本，Client无论连接到哪个server，数据都是一致的。
4)更新请求顺序执行:来自同一个Client的更新请求按其发送顺序依次执行。
5)数据更新原子性:一次数据更新要么成功，要么失败。
6)实时性:在一定时间范围内，Client能读到最新数据。

3.zookeeper集群的选举机制

假设有4台zookeeper节点组成集群

情况一：第一次启动

情况二：在zookeeper运行中的选举机制

①EPOCH大的直接胜出
②EPOCH相同，事务id大的胜出
③事务id相同，服务器id大的胜出

1.Zookeeper 下 Server 工作状态？

服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。
1)LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入 Leader选举状态。
2)FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。
Follower:
1.处理客户端的非事务请求，转发事务请求给Leader服务器
2.参与事务请求Proposal的投票
3.参与Leader投票
3)LEADING：领导者状态。表明当前服务器角色是 Leader。
Leader:
1.事务请求的唯一调度和处理者，保证集群事务处理的顺序性
2.集群内部服务的调度者
4)OBSERVING：观察者状态。表明当前服务器角色是 Observer。
1.3.0版本以后引入的一个服务角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力
2.处理客户端的非事务请求，转发事务请求给 Leader 服务器
3.不参与任何形式的投票

2.名词

SID：服务器ID。用来标识一台zookeeper集群中的机器，每台机器不能重复，和myid一致。
ZXID：事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致。
Epoch：每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟是相同的。每投完一次票这个数据就会增加。

4.zookeeper的ZAB协议？

ZAB的协议核心是在整个zookeeper集群中只有一个节点即Leader，将客户端的写操作转化为事物(或提议proposal)。
Leader节点在数据写完之后，向所有的follower节点发送数据广播请求(或数据复制)，等待所有的follower节点反馈。在ZAB协议中只要超过半数follower节点反馈OK，Leader节点就会像所有的follower服务器发送消息。即将leader节点上的数据同步到follower节点之上。
ZAB协议是专门为zookeeper实现分布式协调功能而设计。zookeeper主要是根据ZAB协议是实现分布式系统数据一致性。
zookeeper根据ZAB协议建立了主备模型完成zookeeper集群中数据的同步。
主备系统架构模型是指，在zookeeper集群中，只有一台leader负责处理外部客户端的事物请求(或写操作)，然后leader服务器将客户端的写操作数据同步到所有的follower节点中。

ZAB协议的两种模式：消息广播模式和崩溃恢复模式

消息广播模式下zookeeper处理模型

• 客户端发起一个写操作请求：
• Leader服务器将客户端的request请求转化为事物proposql提案，同时为每个proposal分配一个全局唯一的ID，即ZXID。
• leader服务器与每个follower之间都有一个队列，leader将消息发送到该队列
• follower机器从队列中取出消息处理完(写入本地事物日志中)毕后，向leader服务器发送ACK确认。
• leader服务器收到半数以上的follower的ACK后，即认为可以发送commit
• leader向所有的follower服务器发送消息。
  要注意的是zookeeper集群中只要有一台节点提交了，就要确保所有的服务器最终都能正确提交proposal，这也是CAP/BASE最终实现一致性的一个体现。
  zookeeper集群中leader与follower之间是通过单独队列进行收发消息的。

补充

BASE理论：
Basically Available(基本可用)、
Soft state(软状态)、
Eventuanlly consistent(最终一致性)
基本可用：系统出现不可预知的故障时，允许损失部分可用性。
弱（软）状态：数据的中间状态，并认为该状态存在不会影响系统整体可用性，允许不同节点数据副本数据同步过程中的延时。
最终一致性：系统中所有数据副本，在一段时间的同步后，最终数据能够到一致性的状态。

崩溃模式下的zookeeper处理模型

zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是leader服务器接受写请求，即使是follower服务器接受到客户端的请求，也会转发到leader服务器进行处理。
如果leader服务器发生崩溃，则zab协议要求zookeeper集群进行崩溃恢复和leader服务器选举。
ZAB协议崩溃恢复要求满足如下2个要求：
1.确保已经被leader提交的proposal必须最终被所有的follower节点提交。
2.确保丢弃已经被leader发出但是没有被提交的proposal。

根据上述要求，新选举出来的leader不能包含未提交的proposal，即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时，新选举的leader节点中含有最高的ZXID。这样做的好处就是可以避免了leader服务器检查proposal的提交和丢弃工作。

数据同步

在zookeeper集群中新的leader选举成功之后，leader会将自身的提交的最大proposal的事物ZXID发送给其他的follower节点。follower节点会根据leader的消息进行回退或者是数据同步操作。最终目的要保证集群中所有节点的数据副本保持一致。

zookeeper集群如何保证新选举的leader分配的ZXID是全局唯一？

ZXID是一个长度64位的数字，其中低32位是按照数字递增，即每次客户端发起一个proposal,低32位的数字简单加1。高32位是leader周期的epoch编号，每当选举出一个新的leader时，新的leader就从本地事物日志中取出ZXID,然后解析出高32位的epoch编号，进行加1，再将低32位的全部设置为0。这样就保证了每次新选举的leader后，保证了ZXID的唯一性而且是保证递增的。

5.zookeeper实现分布式锁？

zookeeper分布式锁1.0版本：

用zookeeper中一个临时节点代表锁
所有客户端争相创建此节点，但只有一个客户端创建成功
创建成功代表获取锁成功，此客户端执行业务逻辑
未创建成功的客户端，监听临时节点变更
获取锁的客户端执行完成后，删除临时节点，表示锁被释放
锁被释放后，其他监听锁节点变更的客户端得到通知，再次争相创建临时子节点（锁节点）

zookeeper分布式锁2.0版本：

每个客户端往/lock下创建有序临时节点/lock/lockq。
创建成功后/lock下面会有每个客户端对应的节点，如/lock/lockq000000001
客户端取得/lock下子节点，并进行排序，判断排在最前面的是否为自己。
如果自己的锁节点在第一位，代表获取锁成功，此客户端执行业务逻辑
如果自己的锁节点不在第一位，则监听自己前一位的锁节点。例如，自己锁节点lockq00000002，那么则监听lockq000000001.
当前一位锁节点（lockq000000001）对应的客户端执行完成，释放了锁，将会触发监听客户端（lockq000000002）的逻辑。
监听客户端重新执行第2步逻辑，判断自己是否获得了锁。

6.节点？

临时节点主要应用于服务器的注册，服务器连接断开临时节点便会自行清理，可以通过这个特点，判断zookeeper服务器之间是否连接，比如leader和follower之间有没有连接。
顺序节点则可以利用作为共享锁，利用顺序节点会自动配一个顺序id的特性。从而根据顺序控制来保证共享锁的机制。

1.持久节点

除非手动删除，否则节点一直存在于Zookeeper上

2.持久顺序节点

基本特性同持久节点，节点名后边会追加一个由父节点维护的自增整型数字

3.临时节点

客户端与Zookeeper断开连接后，该节点被删除

4.临时顺序节点

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

7.Watcher机制？

介绍？

ZooKeeper中的Watcher都是一次性的，即触发之后便失效，需要每次注册。
ZKClient则是通过内部封装改善了这个特点，内部通过使用执行事务之后便重新注册，使得wathcer一直都存在。

Watcher会引发数据变更的通知，因此ZooKeeper引入了Watcher机制来实现分布式的通知功能。比如分布式经典的应用就是数据发布/订阅功能。发布者将某个主题对象发布在ZooKeeper上，其余多个订阅者则在该节点上注册Watcher监听，等到节点发生变化，就会通知订阅者。

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

不是。一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。

为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，给网络和服务器造成很大压力。

一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。
在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。

8.zookeeper的数据结构？

zk的存储的数据的结构，类似于一个文件系统。
每个节点称为znode,每个znode都是一个类似于KV的结构，每个节点名称相当于key,每个节点中都保存了对应的数据，类似于key对应的value。每个znode下面都可以有多个子节点，

9.Zookeeper的架构与集群规则？

规则：
集群为2N+1台，N>0，比如N为1的情况就是3台。
为什么是3台而不是2台呢？因为集群需要一半以上的机器可用，所以，3台挂掉1台还能工作，2台不能。

10.ZAB协议经历哪些核心阶段？

1.Leader election(选举阶段)
节点在一开始都处于选举阶段，只要有一个节点得到超过半数节点的票数，它就可以当选准 Leader。
2.Discovery(发现阶段)
在这个阶段，Followers跟准Leader进行通信，同步Followers最近接收的事务提议。
3.Synchronization(同步阶段)
同步阶段主要是利用Leader前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后准Leader才会成为真正的Leader。
4.Broadcast(广播阶段)
到了这个阶段，Zookeeper集群才能正式对外提供事务服务，并且Leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。

13.哪些情况会导致ZAB进行恢复模式并选取新的Leader?

启动过程或Leader出现网络中断、崩溃退出与重启等异常情况时。
当选举出新的Leader后，同时集群中已有过半的机器与该Leader服务器完成了状态同步之后,ZAB就会退出恢复模式。

14.什么是会话Session?

指的是客户端会话，客户端启动时，会与服务器建立TCP连接，连接成功后，客户端的生命周期开始，客户端和服务器通过心跳检测保持有效的会话以及发请求并响应、监听Watch事件等。

15.在sessionTimeout之内的会话，因服务器压力大、网络故障或客户端主动断开情况下，之前的会话还有效吗？

有效

16.同进程组的两个进程消息网络通信有哪两个特性？

完整性：如果进程a受到进程b的消息msg，那么b一定发送了消息msg.
前置性：如果msg1是msg2的前置消息，那么当前进程务必先接收到msg1，后接收到msg2.

17.数据发布/订阅？

发布者将数据发布到Zookeeper上一个或多个节点上，订阅者从中订阅数据，从而动态获取数据的目的，实现配置信息的集中式管理和数据动态更新。

18.客户端如何获取配置信息？

启动时主动到服务端拉取信息，同时，在制定节点注册Watcher监听。一旦有配置变化，服务端就会实时通知订阅它的所有客户端。

19.分布式集群中为什么会有Master主节点？

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

20.zookeeper的功能？

1.集群管理：监控节点存活状态、运行请求等。
2.主节点选举：主节点挂掉了之后可以从备用的节点开始新一轮选主，主节点选举说的就是这个选举的过程，使用 Zookeeper 可以协助完成这个过程；
3.分布式锁：Zookeeper 提供两种锁：独占锁、共享锁。独占锁即一次只能有一个线程使用资源，共享锁是读锁共享，读写互斥，即可以有多线程同时读同一个资源，如果要使用写锁也只能有一个线程使用。Zookeeper 可以对分布式锁进行控制。
4.命名服务：在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。