开篇介绍
大家好，我是 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 集群的场景下，对实现不同利用间的互相隔离十分有帮忙。