开篇介绍

大家好，我是Java最全面试题库的提裤姐，明天这篇是JavaEE面试题系列的第十二篇，次要总结了ZooKeeper相干的面试题；在后续，会沿着第一篇开篇的常识线路始终总结上来，做到日更！如果我能做到百日百更，心愿你也能够跟着百日百刷，一百天养成一个好习惯。

ZooKeeper是什么？

ZooKeeper是一个开放源码的分布式协调服务，它是集群的管理者，监督着集群中各个节点的状态依据节点提交的反馈进行下一步正当操作。最终，将简略易用的接口和性能高效、性能稳固的零碎提供给用户。

分布式应用程序能够基于Zookeeper实现诸如数据公布/订阅、负载平衡、命名服务、分布式协调/告诉、集群治理、Master选举、分布式锁和分布式队列等性能。

Zookeeper保障了如下分布式一致性个性：

  • 程序一致性
  • 原子性
  • 繁多视图
  • 可靠性
  • 实时性（最终一致性）

客户端的读申请能够被集群中的任意一台机器解决，如果读申请在节点上注册了监听器，这个监听器也是由所连贯的zookeeper机器来解决。对于写申请，这些申请会同时发给其余zookeeper机器并且达成统一后，申请才会返回胜利。因而，随着zookeeper的集群机器增多，读申请的吞吐会进步然而写申请的吞吐会降落。

有序性是zookeeper中十分重要的一个个性，所有的更新都是全局有序的，每个更新都有一个惟一的工夫戳，这个工夫戳称为zxid（Zookeeper Transaction Id）。而读申请只会绝对于更新有序，也就是读申请的返回后果中会带有这个zookeeper最新的zxid。

ZooKeeper和dubbo的区别？

Zookeeper:
zookeeper用来注册服务和进行负载平衡，哪一个服务由哪一个机器来提供必须让调用者晓得，
简略来说就是ip地址和服务名称的对应关系。当然也能够通过硬编码的形式把这种对应关系在调用方业务代码中实现，然而如果提供服务的机器挂掉，调用者无奈通晓，如果不更改代码会持续申请挂掉的机器提供服务。 zookeeper通过心跳机制能够检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。至于反对高并发,简略来说就是横向扩大,在不更改代码的状况通过增加机器来进步运算能力。通过增加新的机器向 zookeeper注册服务，服务的提供者多了能服务的客户就多了。

dubbo:
是治理中间层的工具，在业务层到数据仓库间有十分多服务的接入和服务提供者须要调度，dubbo提供一个框架解决这个问题。

zookeeper和 dubbo的关系：
Dubbo将注册核心进行形象，它能够外接不同的存储媒介给注册核心提供服务，有 ZooKeeper, Memcached, Redis等。

留神这里的 dubbo只是一个框架，这个框架中要实现调度必须要有一个分布式的注册核心，贮存所有服务的元数据，能够用zk，也能够用别的。

Zookeeper的java客户端都有哪些?

  • zk自带的 zkclient
  • Apache开源的 Curator

ZooKeeper提供了什么？

  • 文件系统
  • 告诉机制

说说ZooKeeper文件系统

Zookeeper提供一个多层级的节点命名空间(节点称为 znode)。与文件系统不同的是，这些节点都能够设置关联的数据，而文件系统中只有文件节点能够存放数据而目录节点不行。

Zookeeper为了保障高吞吐和低提早，在内存中保护了这个树状的目录构造，这种个性使得 Zookeeper不能用于寄存大量的数据,每个节点的存放数据下限为1M。

说说ZAB协定？

ZAB协定是为分布式协调服务Zookeeper专门设计的一种反对解体复原的原子播送协定。

ZAB协定包含两种根本的模式：解体复原和音讯播送。

当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器放弃失常通信时，所有过程（服务器）进入解体恢复模式，首先选举产生新的Leader服务器，而后集群中Follower服务器开始与新的Leader服务器进行数据同步，当集群中超过半数机器与该Leader服务器实现数据同步之后，退出恢复模式进入音讯播送模式，Leader服务器开始接管客户端的事务申请生成事物提案来进行事务申请解决。

Znode有哪些类型

  • PERSISTENT-长久节点

除非手动删除，否则节点始终存在于Zookeeper上

  • EPHEMERAL-长期节点

长期节点的生命周期与客户端会话绑定，一旦客户端会话生效（客户端与zookeeper连贯断开不肯定会话生效），那么这个客户端创立的所有长期节点都会被移除。

  • PERSISTENT_SEQUENTIAL-长久程序节点

根本个性同长久节点，只是减少了程序属性，节点名后边会追加一个由父节点保护的自增整型数字。

  • EPHEMERAL_SEQUENTIAL-长期程序节点

根本个性同长期节点，减少了程序属性，节点名后边会追加一个由父节点保护的自增整型数字。

Zookeeper节点宕机如何解决？

Zookeeper自身也是集群，举荐配置不少于3个服务器。Zookeeper本身也要保障当一个节点宕机时，其余节点会持续提供服务。
如果是一个Follower宕机，还有2台服务器提供拜访，因为Zookeeper上的数据是有多个正本的，数据并不会失落；
如果是一个Leader宕机，Zookeeper会选举出新的Leader。

ZK集群的机制是只有超过半数的节点失常，集群就能失常提供服务。
只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才生效。

所以：

  • 3个节点的cluster能够挂掉1个节点(leader能够失去2票>1.5)
  • 2个节点的cluster不能挂掉任何1个节点(leader能够失去1票<=1)

Zookeeper有哪几种几种部署模式?

Zookeeper有三种部署模式：

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

Zookeeper的典型利用场景？

Zookeeper是一个典型的公布/订阅模式的分布式数据管理与协调框架，开发人员能够应用它来进行分布式数据的公布和订阅。
通过对 Zookeeper中丰盛的数据节点进行穿插应用，配合 Watcher事件告诉机制，能够十分不便的构建一系列分布式应用，会波及的外围性能：

  • 数据公布/订阅
  • 负载平衡
  • 命名服务
  • 分布式协调/告诉
  • 集群治理
  • Master选举
  • 分布式锁
  • 分布式队列

说一下Zookeeper Watcher机制

Zookeeper容许客户端向服务端的某个 Znode注册个 Watcher监听，当服务端的一些指定事件触发了这个 Watcher，服务端会向指定客户端发送一个事件告诉来实现分布式的告诉性能，客户端依据 Watcher告诉状态和事件类型做出业务上的扭转。

工作机制：

  • 客户端注册 watcher
  • 服务端解决watcher
  • 客户端回调 watcher

客户端注册Watcher的流程？

1、客户端注册Watcher实现
2、调用getData()/getChildren()/exist()三个API，传入Watcher对象
3、标记申请request，封装Watcher到WatchRegistration
4、封装成Packet对象，发服务端发送request
5、收到服务端响应后，将Watcher注册到ZKWatcherManager中进行治理
6、申请返回，实现注册。

服务端解决Watcher的流程？

1、服务端接管Watcher并存储
接管到客户端申请，解决申请判断是否须要注册Watcher，需要的话将数据节点的节点门路和ServerCnxn（ServerCnxn代表一个客户端和服务端的连贯，实现了Watcher的process接口，此时能够看成一个Watcher对象）存储在WatcherManager的WatchTable和watch2Paths中去。

2、Watcher触发

  • 以服务端接管到 setData() 事务申请触发NodeDataChanged事件为例：
  • 封装WatchedEvent
  • 将告诉状态（SyncConnected）、事件类型（NodeDataChanged）以及节点门路封装成一个WatchedEvent对象
  • 查问Watcher
  • 从WatchTable中依据节点门路查找Watcher

没找到；阐明没有客户端在该数据节点上注册过Watcher
找到；提取并从WatchTable和Watch2Paths中删除对应Watcher（从这里能够看出Watcher在服务端是一次性的，触发一次就生效了）

3、调用process办法来触发Watcher
这里process次要就是通过ServerCnxn对应的TCP连贯发送Watcher事件告诉。

客户端回调 Watcher流程？

1、客户端SendThread线程接管事件告诉，交由 EventThread线程回调 Watcher。
2、客户端的Watcher机制同样是一次性的，一旦被触发后，该 Watcher就生效了。

Zookeeper对节点的 watch监听告诉是永恒的吗?为什么不是永恒的?

不是永恒的。
官网申明：一个 Watch事件是一个次性的触发器，当被设置了 Watch的数据产生了扭转的时候，则服务器将这个扭转发送给设置了 Watch的客户端，以便告诉它们。

起因：
如果服务端变动频繁，而监听的客户端很多状况下，每次变动都要告诉到所有的客户端，给网络和服务器造成很大压力。个别是客户端执行getData（“/节点”，true），如果节点A产生了变更或删除，客户端会失去它的 watch事件，然而在之后节点A又产生了变更，而客户端又没有设置 watch事件，就不再给客户端发送。

在理论利用中，很多状况下，咱们的客户端不须要晓得服务端的每一次变动，我只有最新的数据即可。

说说ACL权限管制机制

1、权限模式（Scheme）
IP：从IP地址粒度进行权限管制
Digest：最罕用，用相似于 username:password 的权限标识来进行权限配置，便于辨别不同利用来进行权限管制
World：最凋谢的权限管制形式，是一种非凡的digest模式，只有一个权限标识“world:anyone”
Super：超级用户

2、受权对象
受权对象指的是权限赋予的用户或一个指定实体，例如IP地址或是机器灯。

3、权限 Permission

  • CREATE：数据节点创立权限，容许受权对象在该Znode下创立子节点
  • DELETE：子节点删除权限，容许受权对象删除该数据节点的子节点
  • READ：数据节点的读取权限，容许受权对象拜访该数据节点并读取其数据内容或子节点列表等
  • WRITE：数据节点更新权限，容许受权对象对该数据节点进行更新操作
  • ADMIN：数据节点管理权限，容许受权对象对该数据节点进行ACL相干设置操作

服务器有哪些角色？

1、Leader
事务申请的惟一调度和解决者，保障集群事务处理的程序性
集群外部各服务的调度者

2、Follower
解决客户端的非事务申请，转发事务申请给Leader服务器
参加事务申请Proposal的投票
参加Leader选举投票

3、Observer
解决客户端的非事务申请，转发事务申请给Leader服务器
不参加任何模式的投票

Zookeeper 下 Server工作状态有哪些？

1、LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为以后集群中没有Leader，因而须要进入Leader选举状态。
2、FOLLOWING：跟随者状态。表明以后服务器角色是Follower。
3、LEADING：领导者状态。表明以后服务器角色是Leader。
4、OBSERVING：观察者状态。表明以后服务器角色是Observer。

集群反对动静增加机器吗？

其实就是程度扩容，Zookeeper在这方面不太好。
两种形式：

  • 全副重启：敞开所有 Zookeeper服务，批改配置之后启动。不影响之前客户端的会话。
  • 一一重启：在过半存活即可用的准则下一台机器重启不影响整个集群对外提供服务。（这是比拟罕用的形式）
3.5版本开始反对动静扩容。

什么是Chroot？

3.2.0版本后，增加了个性，该个性容许每个客户端为本人设置一个命名空间。如果一个客户端设置了 Chroot，那么该客户端对服务器的任何操作，都将会被限度在其本人的命名空间下。

通过设置 Chroot，可能将一个客户端利用与 Zookeeper服务端的一颗子树绝对应，在那些多个利用专用一个 Zookeeper集群的场景下，对实现不同利用间的互相隔离十分有帮忙。