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 名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护。

知其然不知其所以然，大厂常问面试技术如何复习？

1、热门面试题及答案大全

面试前做足功夫，让你面试成功率提升一截，这里一份热门 350 道一线互联网常问面试题及答案助你拿 offer

2、多线程、高并发、缓存入门到实战项目 pdf 书籍

3、文中提到面试题答案整理

4、Java 核心知识面试宝典

覆盖了 JVM 、JAVA 集合、JAVA 多线程并发、JAVA 基础、Spring 原理、微服务、Netty 与 RPC、网络、日志、Zookeeper、Kafka、RabbitMQ、Hbase、MongoDB 、Cassandra、设计模式、负载均衡、数据库、一致性算法 、JAVA 算法、数据结构、算法、分布式缓存、Hadoop、Spark、Storm 的大量技术点且讲解的非常深入

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录