Zookeeper相关整理

Zookeeper

1 、说说 Zookeeper 是什么？

直译：从名字上直译就是动物管理员，动物指的是 Hadoop，Hive 一类的分布式软件，管理员三个字体现了 ZooKeeper 的特点：维护、协调、管理、监控。

简述：有些软件你想做成集群或者分布式，你可以用 ZooKeeper 帮你来辅助实现。

特点：

1. 最终一致性：客户端看到的数据最终是一致的。
2. 可靠性：服务器保存了消息，那么它就一直都存在。
3. 实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据。
4. 独立性（等待无关）：不同客户端直接互不影响。
5. 原子性：更新要不成功要不失败，没有第三个状态。

2、ZooKeeper 有哪些应用场景？

2.1、数据发布与订阅

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

ZooKeeper 采用的是推拉结合的方式。

1. 推: 服务端会推给注册了监控节点的客户端 Wathcer 事件通知

2. 拉: 客户端获得通知后，然后主动到服务端拉取最新的数据

2.2、命名服务

命名服务是指通过指定的名字来获取资源或者服务的地址，利用ZooKeeper创建一个全局的路径，这个路径就可以作为一个名字，指向集群中提供的服务地址，或者一个远程的对象等等。

1、在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。类似于域名与IP之间对应关系，IP不容易记住，而域名容易记住。通过名称来获取资源或服务的地址，提供者等信息。

2、按照层次结构组织服务/应用名称。可将服务名称以及地址信息写到ZooKeeper上，客户端通过ZooKeeper获取可用服务列表类。

2.3集群管理

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

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

1. 希望知道集群中究竟有多少机器在工作

2. 对集群中的每台机器的运行时状态进行数据收集

3. 对集群中机器进行上下线的操作

2.4、分布式通知与协调

1、分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态。

a）NameNode需知道各个Datanode的状态。

b）JobTracker需知道各个TaskTracker的状态。

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

3、信息推送可由ZooKeeper来实现，ZooKeeper相当于一个发布/订阅系统

2.5、分布式锁

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

分布式锁具有以下特性：写锁、读锁、时序锁。

1. 写锁：在zk上创建的一个临时的无编号的节点。由于是无序编号，在创建时不会自动编号，导致只能客户端有一个客户端得到锁，然后进行写入。
2. 读锁：在zk上创建一个临时的有编号的节点，这样即使下次有客户端加入是同时创建相同的节点时，他也会自动编号，也可以获得锁对象，然后对其进行读取。
3. 时序锁：在zk上创建的一个临时的有编号的节点根据编号的大小控制锁

2.6、分布式队列

分布式队列分为两种：

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

a) 一个job由多个task组成，只有所有任务完成后，job才运行完成。

b) 可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时的Znode，一旦临时节点数目达到task总数，则表明job运行完成。

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

3 说说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位用于递增计数。

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

1. LOOKING：当前Server不知道leader是谁，正在搜寻。
2. LEADING：当前Server即为选举出来的leader。
3. FOLLOWING：leader已经选举出来，当前Server与之同步。

4 请描述一下 Zookeeper 的通知机制是什么？

Zookeeper 允许客户端向服务端的某个 znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher ，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。

大致分为三个步骤：

1、客户端注册 Watcher

1、调用 getData、getChildren、exist 三个 API ，传入Watcher 对象。

2、标记请求request ，封装 Watcher 到 WatchRegistration 。

3、封装成 Packet 对象，发服务端发送request 。

4、收到服务端响应后，将 Watcher 注册到 ZKWatcherManager 中进行管理。

5、请求返回，完成注册。

2、服务端处理 Watcher

1、服务端接收 Watcher 并存储。

2、Watcher 触发

      3、调用 process 方法来触发 Watcher 。

3、客户端回调 Watcher

1、客户端 SendThread 线程接收事件通知，交由 EventThread 线程回调Watcher 。

       2、客户端的 Watcher 机制同样是一次性的，一旦被触发后，该 Watcher 就失效了。

5  Zookeeper 对节点的 watch 监听通知是永久的吗？

不是永久的，是一次性的。

无论是服务端还是客户端，一旦一个 Watcher 被触发， Zookeeper 都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力，不然对于更新非常频繁的节点，服务端会不断的向客户端发送事件通知，无论对于网络还是服务端的压力都非常大。

6 Zookeeper 集群中Server有哪些工作状态？

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

7 Zookeeper 是如何保证事务的顺序一致性的呢？

Zookeeper 采用了递增的事务 id 来识别，所有的 proposal （提议）都在被提出的时候加上了zxid 。 zxid 实际上是一个 64 位数字。高 32 位是 epoch 用来标识 Leader 是否发生了改变，如果有新的Leader 产生出来， epoch 会自增。 低 32 位用来递增计数。 当新产生的 proposal 的时候，会依据数据库的两阶段过程，首先会向其他的 Server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

8 ZooKeeper 集群中个服务器之间是怎样通信的？

Leader 服务器会和每一个 Follower/Observer 服务器都建立 TCP 连接，同时为每个Follower/Observer 都创建一个叫做 LearnerHandler 的实体。

LearnerHandler 主要负责 Leader 和Follower/Observer 之间的网络通讯，包括数据同步，请求转发和 proposal 提议的投票等。

Leader 服务器保存了所有 Follower/Observer 的 LearnerHandler 。

9 ZooKeeper 分布式锁怎么实现的？

如果有客户端1、客户端2等N个客户端争抢一个 Zookeeper 分布式锁。大致如下：

1. 大家都是上来直接创建一个锁节点下的一个接一个的临时有序节点

2. 如果自己不是第一个节点，就对自己上一个节点加监听器

3. 只要上一个节点释放锁，自己就排到前面去了，相当于是一个排队机制。而且用临时顺序节的

另外一个用意就是，如果某个客户端创建临时顺序节点之后，不小心自己宕机了也没关系，Zookeeper 感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队。

本地锁，可以用 JDK 实现，但是分布式锁就必须要用到分布式的组件。比如 ZooKeeper、Redis。

关于分布式锁有几个需要注意的地方如下。

1. 死锁问题：锁不能因为意外就变成死锁，所以要用 ZK 的临时节点，客户端连接失效了，锁就自动释放了。
2. 锁等待问题：锁有排队的需求，所以要 ZK 的顺序节点。
3. 锁管理问题：一个使用释放了锁，需要通知其他使用者，所以需要用到监听。
4. 监听的羊群效应：比如有 1000 个锁竞争者，锁释放了，1000 个竞争者就得到了通知，然后判断，最终序号最小的那个拿到了锁。其它 999 个竞争者重新注册监听。这就是羊群效应，出点事，就会惊动整个羊群。应该每个竞争者只监听自己前面的那个节点。比如 2 号释放了锁，那么只有 3 号得到了通知。

10 说一说Zookeeper监听器的原理？

1. 创建一个Main()线程。

2. 在Main()线程中创建两个线程，一个负责网络连接通信（connect），一个负责监听（listener）。

3. 通过connect线程将注册的监听事件发送给Zookeeper。

4. 将注册的监听事件添加到Zookeeper的注册监听器列表中。

5. Zookeeper监听到有数据或路径发生变化时，把这条消息发送给Listener线程。

6. Listener线程内部调用process()方法

11 说说 Zookeeper 的 CAP 问题上做的取舍？

一致性 C：Zookeeper 是强一致性系统，为了保证较强的可用性，“一半以上成功即成功”的数据同步方式可能会导致部分节点的数据不一致。所以 Zookeeper 还提供了 sync() 操作来做所有节点的数据同步，这就关于 C 和 A 的选择问题交给了用户，因为使用 sync()势必会延长同步时间，可用性会有一些损失。

可用性 A：Zookeeper 数据存储在内存中，且各个节点都可以相应读请求，具有好的响应性能。Zookeeper 保证了数据总是可用的，没有锁。并且有一大半的节点所拥有的数据是最新的。

分区容忍性 P：Follower 节点过多会导致增大数据同步的延时（需要半数以上 follower 写完提交）。同时选举过程的收敛速度会变慢，可用性降低。Zookeeper 通过引入 observer 节点缓解了这个问题，增加 observer 节点后集群可接受 client 请求的节点多了，而且 observer 不参与投票，可以提高可用性和扩展性，但是节点多数据同步总归是个问题，所以一致性会有所降低。

12 ZooKeeper 负载均衡和 Nginx 负载均衡有什么区别？

ZooKeeper：

不存在单点问题，zab 机制保证单点故障可重新选举一个 Leader

只负责服务的注册与发现，不负责转发，减少一次数据交换（消费方与服务方直接通信）

需要自己实现相应的负载均衡算法

Nginx：

存在单点问题，单点负载高数据量大，需要通过 KeepAlived 辅助实现高可用

每次负载，都充当一次中间人转发角色，本身是个反向代理服务器

自带负载均衡算法

13简述Leader选举算法和流程？

选举算法和流程：FastLeaderElection(默认提供的选举算法)

⽬前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：

一：服务器1启动，给⾃⼰投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态⼀直属于Looking。

二：服务器2启动，给⾃⼰投票，同时与之前启动的服务器1交换结果，由于服务器2的编号⼤所以服务器2胜出，但此时投票数没有⼤于半数，所以两个服务器的状态依然是LOOKING。

三：服务器3启动，给⾃⼰投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最⼤所以服务器3胜出，此时投票数正好⼤于半数，所以服务器3成为leader，服务器1,2成为follower。

四：服务器4启动，给⾃⼰投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号⼤，但之前服务器3已经胜出，所以服务器4只能成为follower。

五：服务器5启动，后⾯的逻辑同服务器4成为follower。

如果一个节点收到了超过一半的投票，就认为自己成为了新的Leader，

并开始向其他节点发送消息，宣布自己是Leader，并开始接受客户端的请求。

如果没有节点收到超过一半的投票，选举失败，需要重新开始新一轮的Leader选举。

总之，Leader选举算法的目的是为了在集群中选出一个节点成为Leader，保证系统的高可用性和数据一致性。它的流程是一个不断循环的过程，直到选出一个新的Leader或者选举失败

14 什么是ZAB协议？

ZAB（ZooKeeper Atomic Broadcast）协议是ZooKeeper的核心算法，用于保证ZooKeeper集群的数据一致性和高可用性。

在ZooKeeper中，所有的数据操作都必须经过ZAB协议进行广播，然后由所有的服务器按照相同的顺序执行，从而保证集群中所有服务器的数据状态是一致的。ZAB协议主要包括两个阶段：

1.Leader选举阶段：集群中的所有服务器通过竞选Leader的方式，选出一个Leader来负责数据的同步和更新。

2.数据同步阶段：Leader负责将客户端的请求广播给集群中的所有服务器，并根据一定的顺序进行数据同步和更新。

ZAB协议的核心思想是，保证集群中所有服务器的数据状态是一致的，并且在Leader故障时能够快速选举新的Leader，从而保证集群的高可用性。

15、Zookeeper中有几种节点类型？

1. 持久节点（Persistent Nodes）：这种节点在创建后，会一直存在于Zookeeper中，直到被显示删除。
2. 临时节点（Ephemeral Nodes）：这种节点在创建它的客户端会话结束时被自动删除。如果客户端因为某种原因（比如网络问题）而断开连接，那么与之关联的临时节点也会被删除。
3. 持久顺序节点（Persistent Sequential Nodes）：这种节点在创建时会自动分配一个递增的编号，编号是唯一的。节点的名称是由用户指定的前缀和分配的编号组成的。这种节点的特点是它们在同级节点中按照编号的顺序排列。
4. 临时顺序节点（Ephemeral Sequential Nodes）：这种节点结合了临时节点和持久顺序节点的特点。它们在客户端会话结束时被删除，并按照编号的顺序排列。