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.命名服务:在分布式系统中,通过使用命名服务,客户端应用能够根据指定名字来获取资源或服务的地址,提供者等信息。
本文来自博客园,作者:jsqup,转载请注明原文链接:https://www.cnblogs.com/jsqup/p/16094757.html