面试的时候，面试官只要看到你简历的上写的有Zookeeper（熟悉、掌握）之类，那你至少要准备接下来的11连问。
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现（Chubby是不开源的），它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户 。
Zookeeper一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到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阶段。
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在工作过程中有三种状态：
ZooKeeper设计的目的是提供高性能、高可用、顺序一致性的分布式协调服务、保证数据最终一致性。
高性能（简单的数据模型）
高可用（构建集群）
顺序一致性（事务操作的顺序）
最终一致性
系统模型：
领导者（leader）
Leader服务器为客户端提供读服务和写服务。负责进行投票的发起和决议，更新系统状态。
学习者（learner）
客户端（client）：服务请求发起方。
节点有哪些类型？
Znode两种类型：
持久的（persistent）：客户端和服务器端断开连接后，创建的节点不删除（默认）。
短暂的（ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除。
Znode有四种形式：
「注意」：创建ZNode时设置顺序标识，ZNode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护。
节点属性有哪些
一个znode节点不仅可以存储数据，还有一些其他特别的属性。接下来我们创建一个/test节点分析一下它各个属性的含义。
属性说明
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。
简单地说：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机制，大致的流程如下：
上边的过程就是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。否则客户端只能接收到一次该节点的变更通知。
数据发布与订阅
发布与订阅即所谓的配置管理，顾名思义就是将数据发布到ZooKeeper节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用。
数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。
配置信息一般有几个特点:
ZooKeeper 采用的是推拉结合的方式。
命名服务
作为分布式命名服务，命名服务是指通过指定的名字来获取资源或者服务的地址，利用ZooKeeper创建一个全局的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。
统一命名服务的命名结构图如下所示：
1、在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。
2、按照层次结构组织服务/应用名称。
配置管理
程序分布式的部署在不同的机器上，将程序的配置信息放在ZooKeeper的znode下，当有配置发生改变时，也就是znode发生变化时，可以通过改变zk中某个目录节点的内容，利用watch通知给各个客户端 从而更改配置。
ZooKeeper配置管理结构图如下所示：
1、分布式环境下，配置文件管理和同步是一个常见问题。
2、配置管理可交由ZooKeeper实现。
集群管理
所谓集群管理就是：是否有机器退出和加入、选举master。
集群管理主要指集群监控和集群控制两个方面。前者侧重于集群运行时的状态的收集，后者则是对集群进行操作与控制。开发和运维中，面对集群，经常有如下需求:
集群管理结构图如下所示：
1、分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。
2、可交由ZooKeeper实现。
3、典型应用
利用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方式进行入队和出队操作，例如实现生产者和消费者模型。
首先需要明确zookeeper选举的规则：leader选举，要求可用节点数量 > 总节点数量/2。
比如：标记一个写是否成功是要在超过一半节点发送写请求成功时才认为有效。同样，Zookeeper选择领导者节点也是在超过一半节点同意时才有效。最后，Zookeeper是否正常是要根据是否超过一半的节点正常才算正常。这是基于CAP的一致性原理。
zookeeper有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。
也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；
同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；
同理：
…
会发现一个规律，2n和2n-1的容忍度是一样的，都是n-1，所以为了更加高效，何必增加那一个不必要的zookeeper呢。
zookeeper的选举策略也是需要半数以上的节点同意才能当选leader，如果是偶数节点可能导致票数相同的情况。
很多面试官，面试套路基本就是这个，从背景到原理，到架构体系，再到Zookeeper固有特点、最后要求面试者能说出Zookeeper的实际应用场景。
参考资料：
- https://www.toutiao.com/i6919076858403521028/?tt_from=mobile_qq&utm_campaign=client_share×tamp=1615301227&app=news_article&utm_source=mobile_qq&utm_medium=toutiao_android&use_new_style=1&req_id=20210309224707010151217101560FAE87&share_token=f4778d79-6f89-4a1a-84d2-7a6a68fd91e9&group_id=6919076858403521028