获取：10万字的面试小抄

面试的时候，面试官只有看到你简历的上写的有Zookeeper（相熟、把握）之类，那你至多要筹备接下来的11连问。

NO1：说说zookeeper是什么？

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

Zookeeper一个最罕用的应用场景就是用于负责服务生产者和服务消费者的注册核心，服务生产者将本人提供的服务注册到Zookeeper核心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据，简略示例图如下：

NO2：理解Zookeeper的零碎架构吗？

ZooKeeper 的架构图中咱们须要理解和把握的次要有：

（1）ZooKeeper分为服务器端（Server） 和客户端（Client），客户端能够连贯到整个 ZooKeeper服务的任意服务器上（除非 leaderServes 参数被显式设置， leader 不容许承受客户端连贯）。

（2）客户端应用并保护一个 TCP 连贯，通过这个连贯发送申请、承受响应、获取察看的事件以及发送心跳。如果这个 TCP 连贯中断，客户端将主动尝试连贯到另外的 ZooKeeper服务器。客户端第一次连贯到 ZooKeeper服务时，承受这个连贯的 ZooKeeper服务器会为这个客户端建设一个会话。当这个客户端连贯到另外的服务器时，这个会话会被新的服务器从新建设。

（3）上图中每一个Server代表一个装置Zookeeper服务的机器，即是整个提供Zookeeper服务的集群（或者是由伪集群组成）；

（4）组成ZooKeeper服务的服务器必须彼此理解。它们保护一个内存中的状态图像，以及长久存储中的事务日志和快照， 只有大多数服务器可用，ZooKeeper服务就可用；

（5）ZooKeeper 启动时，将从实例中选举一个 leader，Leader 负责解决数据更新等操作，一个更新操作胜利的标记是当且仅当大多数Server在内存中胜利批改数据。每个Server 在内存中存储了一份数据。

（6）Zookeeper是能够集群复制的，集群间通过Zab协定（Zookeeper Atomic Broadcast）来保持数据的一致性；

（7）Zab协定蕴含两个阶段：leader election阶段和Atomic Brodcast阶段。

  • a) 集群中将选举出一个leader，其余的机器则称为follower，所有的写操作都被传送给leader，并通过brodcast将所有的更新通知给follower。
  • b) 当leader解体或者leader失去大多数的follower时，须要从新选举出一个新的leader，让所有的服务器都复原到一个正确的状态。
  • c) 当leader被选举进去，且大多数服务器实现了 和leader的状态同步后，leadder election 的过程就完结了，就将会进入到Atomic brodcast的过程。
  • d) Atomic Brodcast同步leader和follower之间的信息，保障leader和follower具备形同的零碎状态。

NO3：能说说Zookeeper的工作原理？

Zookeeper的外围是原子播送，这个机制保障了各个Server之间的同步。实现这个机制的协定叫做Zab协定。

Zab协定有两种模式，它们 别离是恢复模式（选主）和播送模式（同步）。

Zab协定 的全称是 Zookeeper Atomic Broadcast** （Zookeeper原子播送）。Zookeeper 是通过 Zab 协定来保障分布式事务的最终一致性。Zab协定要求每个 Leader 都要经验三个阶段：发现，同步，播送。

当服务启动或者在领导者解体后，Zab就进入了恢复模式，当领导者被选举进去，且大多数Server实现了和 leader的状态同步当前，恢复模式就完结了。状态同步保障了leader和Server具备雷同的零碎状态。

为了保障事务的程序一致性，zookeeper采纳了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加 上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否扭转，每次一个leader被选出来，它都会有一 个新的epoch，标识以后属于那个leader的统治期间。低32位用于递增计数。

epoch：能够了解为皇帝的年号，当新的皇帝leader产生后，将有一个新的epoch年号。

每个Server在工作过程中有三种状态：

  • LOOKING：以后Server不晓得leader是谁，正在搜查。
  • LEADING：以后Server即为选举进去的leader。
  • FOLLOWING：leader曾经选举进去，以后Server与之同步。

NO4：Zookeeper为什么要这么设计？

ZooKeeper设计的目标是提供高性能、高可用、程序一致性的分布式协调服务、保证数据最终一致性。

高性能（简略的数据模型）

  1. 采纳树形构造组织数据节点；
  2. 全量数据节点，都存储在内存中；
  3. Follower 和 Observer 间接解决非事务申请；

高可用（构建集群）

  1. 半数以上机器存活，服务就能失常运行
  2. 主动进行 Leader 选举

程序一致性（事务操作的程序）

  1. 每个事务申请，都会转发给 Leader 解决
  2. 每个事务，会调配全局惟一的递增id（zxid，64位：epoch + 自增 id）

最终一致性

  1. 通过提议投票形式，保障事务提交的可靠性
  2. 提议投票形式，只能保障 Client 收到事务提交胜利后，半数以上节点可能看到最新数据

NO5：你晓得Zookeeper中有哪些角色？

零碎模型：

领导者（leader）

Leader服务器为客户端提供读服务和写服务。负责进行投票的发动和决定，更新零碎状态。

学习者（learner）

  • 跟随者（follower） Follower服务器为客户端提供读服务，参加Leader选举过程，参加写操作“过半写胜利”策略。
  • 观察者（observer） Observer服务器为客户端提供读服务，不参加Leader选举过程，不参加写操作“过半写胜利”策略。用于在不影响写性能的前提下晋升集群的读性能。

客户端（client）：服务申请发起方。

NO6：你相熟Zookeeper节点ZNode和相干属性吗？

节点有哪些类型？

Znode两种类型：

长久的（persistent）：客户端和服务器端断开连接后，创立的节点不删除（默认）。

短暂的（ephemeral）：客户端和服务器端断开连接后，创立的节点本人删除。

Znode有四种模式：

  • 长久化目录节点（PERSISTENT）：客户端与Zookeeper断开连接后，该节点仍旧存在长久化程序编号目录节点（PERSISTENT_SEQUENTIAL）
  • 客户端与Zookeeper断开连接后，该节点仍旧存在，只是Zookeeper给该节点名称进行程序编号：长期目录节点（EPHEMERAL）
  • 客户端与Zookeeper断开连接后，该节点被删除：长期程序编号目录节点（EPHEMERAL_SEQUENTIAL）
  • 客户端与Zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行程序编号

「留神」：创立ZNode时设置程序标识，ZNode名称后会附加一个值，顺序号是一个枯燥递增的计数器，由父节点保护。

节点属性有哪些

一个znode节点不仅能够存储数据，还有一些其余特地的属性。接下来咱们创立一个/test节点剖析一下它各个属性的含意。

 [zk: localhost:2181(CONNECTED) 6] get /test    456    cZxid = 0x59ac //    ctime = Mon Mar 30 15:20:08 CST 2020    mZxid = 0x59ad    mtime = Mon Mar 30 15:22:25 CST 2020    pZxid = 0x59ac    cversion = 0    dataVersion = 2    aclVersion = 0    ephemeralOwner = 0x0    dataLength = 3    numChildren = 0

属性阐明

NO7：请简述Zookeeper的选主流程

Zookeeper的外围是原子播送，这个机制保障了各个Server之间的同步。实现这个机制的协定叫做Zab协定。Zab协定有两种模式，它们别离是恢复模式（选主）和播送模式（同步）。当服务启动或者在领导者解体后，Zab就进入了恢复模式，当领导者被选举进去，且大多数Server实现了和leader的状态同步当前，恢复模式就完结了。状态同步保障了leader和Server具备雷同的零碎状态。leader选举是保障分布式数据一致性的要害。

呈现选举次要是两种场景：初始化、leader不可用。

当zk集群中的一台服务器呈现以下两种状况之一时，就会开始leader选举。

（1）服务器初始化启动。

（2）服务器运行期间无奈和leader放弃连贯。

而当一台机器进入leader选举流程时，以后集群也可能处于以下两种状态。

（1）集群中原本就曾经存在一个leader。

（2）集群中的确不存在leader。

首先第一种状况，通常是集群中某一台机器启动比拟晚，在它启动之前，集群曾经失常工作，即曾经存在一台leader服务器。当该机器试图去选举leader时，会被告知以后服务器的leader信息，它仅仅须要和leader机器建设连贯，并进行状态同步即可。

重点是leader不可用了，此时的选主制度。

投票信息中蕴含两个最根本的信息。

sid：即server id，用来标识该机器在集群中的机器序号。

zxid：即zookeeper事务id号。

ZooKeeper状态的每一次扭转, 都对应着一个递增的Transaction id,，该id称为zxid.，因为zxid的递增性质, 如果zxid1小于zxid2,，那么zxid1必定先于zxid2产生。创立任意节点，或者更新任意节点的数据， 或者删除任意节点，都会导致Zookeeper状态产生扭转，从而导致zxid的值减少。

以（sid，zxid）的模式来标识一次投票信息。

例如：如果以后服务器要推举sid为1，zxid为8的服务器成为leader，那么投票信息能够示意为（1，8）

集群中的每台机器收回本人的投票后，也会承受来自集群中其余机器的投票。每台机器都会依据肯定的规定，来解决收到的其余机器的投票，以此来决定是否须要变更本人的投票。

规定如下：

（1）初始阶段，都会给本人投票。

（2）当接管到来自其余服务器的投票时，都须要将他人的投票和本人的投票进行pk，规定如下：

优先查看zxid。zxid比拟大的服务器优先作为leader。如果zxid雷同的话，就比拟sid，sid比拟大的服务器作为leader。

NO8：有理解过watch机制吗？

简略地说：client端会对某个znode 注册一个watcher事件，当该znode发生变化时，这些client会收到ZooKeeper的告诉，而后client能够依据znode变动来做出业务上的扭转等。

经典应用场景：zookeeper为dubbo提供服务的注册与发现，作为注册核心，然而大家有没有想过zookeeper为啥可能实现服务的注册与发现吗？

这就不得不说一下zookeeper的灵魂 Watcher（监听者）。

什么是watcher？

watcher 是zooKeeper中一个十分外围性能 ，客户端watcher 能够监控节点的数据变动以及它子节点的变动，一旦这些状态发生变化，zooKeeper服务端就会告诉所有在这个节点上设置过watcher的客户端 ，从而每个客户端都很快感知，它所监听的节点状态发生变化，而做出对应的逻辑解决。

简略的介绍了一下watcher ，那么咱们来剖析一下，zookeeper是如何实现服务的注册与发现。zookeeper的服务注册与发现，次要利用的是zookeeper的znode节点数据模型和watcher机制，大抵的流程如下：

  • 服务注册：服务提供者（Provider）启动时，会向zookeeper服务端注册服务信息，也就是创立一个节点，例如：用户注册服务com.xxx.user.register，并在节点上存储服务的相干数据（如服务提供者的ip地址、端口等）。
  • 服务发现：服务消费者（Consumer）启动时，依据本身配置的依赖服务信息，向zookeeper服务端获取注册的服务信息并设置watch监听，获取到注册的服务信息之后，将服务提供者的信息缓存在本地，并进行服务的调用。
  • 服务告诉：一旦服务提供者因某种原因宕机不再提供服务之后，客户端与zookeeper服务端断开连接，zookeeper服务端上服务提供者对应服务节点会被删除（例如：用户注册服务com.xxx.user.register），随后zookeeper服务端会异步向所有生产用户注册服务com.xxx.user.register，且设置了watch监听的服务消费者收回节点被删除的告诉，消费者依据收到的告诉拉取最新服务列表，更新本地缓存的服务列表。

上边的过程就是zookeeper能够实现服务注册与发现的大抵原理。

watcher有哪些类型？

znode节点能够设置两类watch，一种是DataWatches，基于znode节点的数据变更从而触发 watch 事件，触发条件getData()、exists()、setData()、 create()。

另一种是Child Watches，基于znode的孩子节点产生变更触发的watch事件，触发条件 getChildren()、 create()。

而在调用 delete() 办法删除znode时，则会同时触发Data Watches和Child Watches，如果被删除的节点还有父节点，则父节点会触发一个Child Watches。

watcher有什么个性？

watch对节点的监听事件是一次性的！客户端在指定的节点设置了监听watch，一旦该节点数据产生变更告诉一次客户端后，客户端对该节点的监听事件就生效了。

如果还要持续监听这个节点，就须要咱们在客户端的监听回调中，再次对节点的监听watch事件设置为True。否则客户端只能接管到一次该节点的变更告诉。

NO9：那你说说Zookeeper有哪些利用场景？

数据公布与订阅

公布与订阅即所谓的配置管理，顾名思义就是将数据公布到ZooKeeper节点上，供订阅者动静获取数据，实现配置信息的集中式治理和动静更新。例如全局的配置信息，地址列表等就非常适合应用。

数据公布/订阅的一个常见的场景是配置核心，发布者把数据公布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动静获取数据的目标。

配置信息个别有几个特点:

  1. 数据量小的KV
  2. 数据内容在运行时会产生动态变化
  3. 集群机器共享，配置统一

ZooKeeper 采纳的是推拉联合的形式。

  1. 推: 服务端会推给注册了监控节点的客户端 Wathcer 事件告诉
  2. 拉: 客户端取得告诉后，而后被动到服务端拉取最新的数据
命名服务

作为分布式命名服务，命名服务是指通过指定的名字来获取资源或者服务的地址，利用ZooKeeper创立一个全局的门路，这个门路就能够作为一个名字，指向集群中的集群，提供的服务的地址，或者一个近程的对象等等。

对立命名服务的命名结构图如下所示：

1、在分布式环境下，常常须要对利用/服务进行对立命名，便于辨认不同服务。

  • 相似于域名与IP之间对应关系，IP不容易记住，而域名容易记住。
  • 通过名称来获取资源或服务的地址，提供者等信息。

2、依照层次结构组织服务/利用名称。

  • 可将服务名称以及地址信息写到ZooKeeper上，客户端通过ZooKeeper获取可用服务列表类。
配置管理

程序分布式的部署在不同的机器上，将程序的配置信息放在ZooKeeper的znode下，当有配置产生扭转时，也就是znode发生变化时，能够通过扭转zk中某个目录节点的内容，利用watch告诉给各个客户端 从而更改配置。

ZooKeeper配置管理结构图如下所示：

1、分布式环境下，配置文件治理和同步是一个常见问题。

  • 一个集群中，所有节点的配置信息是统一的，比方 Hadoop 集群。
  • 对配置文件批改后，心愿可能疾速同步到各个节点上。

2、配置管理可交由ZooKeeper实现。

  • 可将配置信息写入ZooKeeper上的一个Znode。
  • 各个节点监听这个Znode。
  • 一旦Znode中的数据被批改，ZooKeeper将告诉各个节点。
集群治理

所谓集群治理就是：是否有机器退出和退出、选举master。

集群治理次要指集群监控和集群管制两个方面。前者侧重于集群运行时的状态的收集，后者则是对集群进行操作与管制。开发和运维中，面对集群，常常有如下需要:

  1. 心愿晓得集群中到底有多少机器在工作
  2. 对集群中的每台机器的运行时状态进行数据收集
  3. 对集群中机器进行高低线的操作

集群治理结构图如下所示：

1、分布式环境中，实时把握每个节点的状态是必要的，可依据节点实时状态做出一些调整。

2、可交由ZooKeeper实现。

  • 可将节点信息写入ZooKeeper上的一个Znode。
  • 监听这个Znode可获取它的实时状态变动。

3、典型利用

  • Hbase中Master状态监控与选举。

利用ZooKeeper的强一致性，可能保障在分布式高并发状况下节点创立的全局唯一性，即：同时有多个客户端申请创立 /currentMaster 节点，最终肯定只有一个客户端申请可能创立胜利

分布式告诉与协调

1、分布式环境中，常常存在一个服务须要晓得它所治理的子服务的状态。

a）NameNode需晓得各个Datanode的状态。

b）JobTracker需晓得各个TaskTracker的状态。

2、心跳检测机制可通过ZooKeeper来实现。

3、信息推送可由ZooKeeper来实现，ZooKeeper相当于一个公布/订阅零碎。

分布式锁

处于不同节点上不同的服务，它们可能须要程序的拜访一些资源，这里须要一把分布式的锁。

分布式锁具备以下个性：写锁、读锁、时序锁。

写锁：在zk上创立的一个长期的无编号的节点。因为是无序编号，在创立时不会主动编号，导致只能客户端有一个客户端失去锁，而后进行写入。

读锁：在zk上创立一个长期的有编号的节点，这样即便下次有客户端退出是同时创立雷同的节点时，他也会主动编号，也能够取得锁对象，而后对其进行读取。

时序锁：在zk上创立的一个长期的有编号的节点依据编号的大小管制锁。

分布式队列

分布式队列分为两种：

1、当一个队列的成员都聚齐时，这个队列才可用，否则始终期待所有成员达到，这种是同步队列。

a）一个job由多个task组成，只有所有工作实现后，job才运行实现。

b）可为job创立一个/job目录，而后在该目录下，为每个实现的task创立一个长期的Znode，一旦长期节点数目达到task总数，则表明job运行实现。

2、队列依照FIFO形式进行入队和出队操作，例如实现生产者和消费者模型。

NO10：晓得监听器的原理吗？

  1. 创立一个Main()线程。
  2. 在Main()线程中创立两个线程，一个负责网络连接通信（connect），一个负责监听（listener）。
  3. 通过connect线程将注册的监听事件发送给Zookeeper。
  4. 将注册的监听事件增加到Zookeeper的注册监听器列表中。
  5. Zookeeper监听到有数据或门路发生变化时，把这条音讯发送给Listener线程。
  6. Listener线程外部调用process()办法。

NO11：为什么Zookeeper集群的数目，个别为奇数个？

首先须要明确zookeeper选举的规定：leader选举，要求可用节点数量 > 总节点数量/2。

比方：标记一个写是否胜利是要在超过一半节点发送写申请胜利时才认为无效。同样，Zookeeper抉择领导者节点也是在超过一半节点批准时才无效。最初，Zookeeper是否失常是要依据是否超过一半的节点失常才算失常。这是基于CAP的一致性原理。

zookeeper有这样一个个性：集群中只有有过半的机器是失常工作的，那么整个集群对外就是可用的。

也就是说如果有2个zookeeper，那么只有有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；

同理，要是有3个zookeeper，一个死了，还剩下2个失常的，过半了，所以3个zookeeper的容忍度为1；

同理：

  • 2->0；两个zookeeper，最多0个zookeeper能够不可用。
  • 3->1；三个zookeeper，最多1个zookeeper能够不可用。
  • 4->1；四个zookeeper，最多1个zookeeper能够不可用。
  • 5->2；五个zookeeper，最多2个zookeeper能够不可用。
  • 6->2；两个zookeeper，最多0个zookeeper能够不可用。

....

会发现一个法则，2n和2n-1的容忍度是一样的，都是n-1，所以为了更加高效，何必减少那一个不必要的zookeeper呢。

zookeeper的选举策略也是须要半数以上的节点批准能力入选leader，如果是偶数节点可能导致票数雷同的状况。

总结

很多面试官，面试套路根本就是这个，从背景到原理，到架构体系，再到Zookeeper固有特点、最初要求面试者能说出Zookeeper的理论利用场景。

「你多学一样本事，就少说一句求人的话。」

举荐浏览

把握Mybatis动静映射，我可是下了功夫的

2020所有原创

写给大忙人看的JAVA核心技术.pdf下载

图解多线程

京东面试：说说MySQL的架构体系