Zookeeper(网上资料整理)

参考:Zookeeper面试题

参考:zookeeper数据同步

参考:如果有人问你ZooKeeper是什么，就把这篇文章发给他

参考:理解zookeeper选举机制

参考:【zookeeper】事件 watch 机制 原理

参考:ZooKeeper Watch机制

参考:利用Zookeeper实现 - 分布式锁

文章目录

• 1.是什么
• 2.特性
• • 1.读写请求处理
  • 2.全局有序性
  • 3.通知机制
• 3.节点类型
• 4.集群角色
• • 1.Leader
  • 2.Follower
  • 3.Observer
• 5.工作原理
• • 1.ZAB协议
  • • 1.恢复模式（选主）-leader选举
    • 2.广播模式（同步）
  • 2.Server工作状态
  • 3.原子广播
• 5.watch机制
• • 1.概述
  • 2.特性
• 6.宕机处理
• 7.实际应用
• • 1.命名服务
  • 2.配置管理
  • 3.集群管理
  • 4.队列管理
  • 5.数据复制
  • 6.分布式锁
  • • 1.大致思想
    • 2.实现排他锁
    • 3.实现共享锁
    • 4.羊群效应与共享锁改进
    • 5.优点
    • 6.缺点

1.是什么

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

Zookeeper提供一个多层级的节点命名空间（节点称为znode）。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。

2.特性

1.读写请求处理

客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理。对于写请求，这些请求会同时发给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。

2.全局有序性

有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。

3.通知机制

client端会对某个znode建立一个watcher事件，当该znode发生变化时，这些client会收到zk的通知，然后client可以根据znode变化来做出业务上的改变等。

3.节点类型

• 1、PERSISTENT-持久化目录节点

  客户端与zookeeper断开连接后，该节点依旧存在

• 2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点

  客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

• 3、EPHEMERAL-临时目录节点

  客户端与zookeeper断开连接后，该节点被删除

• 4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点

  客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

  

4.集群角色

1.Leader

是整个 Zookeeper 集群工作机制中的核心 。Leader 作为整个 ZooKeeper 集群的主节点，负责响应所有对 ZooKeeper 状态变更的请求。

主要工作：

• 事务请求的唯一调度和处理，保障集群处理事务的顺序性。
• 集群内各服务器的调度者。

2.Follower

是 Zookeeper 集群状态的跟随者。他的逻辑就比较简单。除了响应本服务器上的读请求外，follower 还要处理leader 的提议，并在 leader 提交该提议时在本地也进行提交。另外需要注意的是，leader 和 follower 构成ZooKeeper 集群的法定人数，也就是说，只有他们才参与新 leader的选举、响应 leader 的提议。

3.Observer

Observer ：服务器充当一个观察者的角色。如果 ZooKeeper 集群的读取负载很高，或者客户端多到跨机房，可以设置一些 observer 服务器，以提高读取的吞吐量。Observer 和 Follower 比较相似，只有一些小区别：首先 observer 不属于法定人数，即不参加选举也不响应提议，也不参与写操作的“过半写成功”策略；其次是 observer 不需要将事务持久化到磁盘，一旦 observer 被重启，需要从 leader 重新同步整个名字空间。

5.工作原理

1.ZAB协议

ZAB协议包括两种基本的模式：恢复模式（选主）和广播模式（同步）。

1.恢复模式（选主）-leader选举

2.广播模式（同步）

整个集群完成Leader选举后，Learner会向Leader进行注册，当Learner向Leader完成注册后，就进入数据同步环节，同步过程就是Leader将那些没有在Learner服务器上提交过的事务请求同步给Learner服务器，大体过程如下:

在进行数据同步前，Leader服务器会完成数据同步初始化：

• peerLastZxid：从learner服务器注册时发送的ACKEPOCH消息中提取lastZxid（该Learner服务器最后处理的ZXID）
• minCommittedLog：Leader服务器Proposal缓存队列committedLog中最小ZXID
• maxCommittedLog：Leader服务器Proposal缓存队列committedLog中最大ZXID

对于集群数据同步而言，通常分为四类，直接差异化同步(DIFF同步)、先回滚再差异化同步(TRUNC+DIFF同步)、仅回滚同步(TRUNC同步)、全量同步(SNAP同步)，在初始化阶段，Leader会优先以全量同步方式来同步数据。同时，会根据Leader和Learner之间的数据差异情况来决定最终的数据同步方式。

• 直接差异化同步(DIFF同步，peerLastZxid介于minCommittedLog和maxCommittedLog之间)

  Leader首先向这个Learner发送一个DIFF指令，用于通知Learner进入差异化数据同步阶段，Leader即将把一些Proposal同步给自己，针对每个Proposal，Leader都会通过发送PROPOSAL内容数据包和COMMIT指令数据包来完成，

• 先回滚再差异化同步(TRUNC+DIFF同步，Leader已经将事务记录到本地事务日志中，但是没有成功发起Proposal流程)

  当Leader发现某个Learner包含了一条自己没有的事务记录，那么就需要该Learner进行事务回滚，回滚到Leader服务器上存在的，同时也是最接近于peerLastZxid的ZXID。

• 仅回滚同步(TRUNC同步，peerLastZxid大于maxCommittedLog)

  Leader要求Learner回滚到ZXID值为maxCommittedLog对应的事务操作。

• 全量同步(SNAP同步，peerLastZxid小于minCommittedLog或peerLastZxid不等于lastProcessedZxid)

  Leader无法直接使用提议缓存队列和Learner进行同步，因此只能进行全量同步。Leader将本机的全量内存数据同步给Learner。Leader首先向Learner发送一个SNAP指令，通知Learner即将进行全量同步，随后，Leader会从内存数据库中获取到全量的数据节点和会话超时时间记录器，将他们序列化后传输给Learner。Learner接收到该全量数据后，会对其反序列化后载入到内存数据库中。

2.Server工作状态

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

• LOOKING：当前Server不知道leader是谁，正在搜寻
• LEADING：当前Server即为选举出来的leader
• FOLLOWING：leader已经选举出来，当前Server与之同步
• OBSERVING：观察者状态。表明当前服务器角色是Observer。

3.原子广播

Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

5.watch机制

1.概述

zk的订阅发布也就是watch机制，是一个轻量级的设计。因为它采用了一种推拉结合的模式。一旦服务端感知主题变了，那么只会发送一个事件类型和节点信息给关注的客户端，而不会包括具体的变更内容，所以事件本身是轻量级的，这就是所谓的“推”部分。然后，收到变更通知的客户端需要自己去拉变更的数据，这就是“拉”部分。

Watch的整体流程如下图所示，客户端先向ZooKeeper服务端成功注册想要监听的节点状态，同时客户端本地会存储该监听器相关的信息在WatchManager中，当ZooKeeper服务端监听的数据状态发生变化时，ZooKeeper就会主动通知发送相应事件信息给相关会话客户端，客户端就会在本地响应式的回调相关Watcher的Handler。

2.特性

• Watch是一次性的，每次都需要重新注册.

  并且客户端在会话异常结束时不会收到任何通知，而快速重连接时仍不影响接收通知。

• Watch的回调执行都是顺序执行的

  并且客户端在没有收到关注数据的变化事件通知之前是不会看到最新的数据，另外需要注意不要在Watch回调逻辑中阻塞整个客户端的Watch回调

• Watch是轻量级的，WatchEvent是最小的通信单元

  结构上只包含通知状态、事件类型和节点路径。ZooKeeper服务端只会通知客户端发生了什么，并不会告诉具体内容。

• watcher event异步发送watcher的通知事件从server发送到client是异步的

  由于网络延迟或其他因素导致客户端在不通的时刻监听到事件，由于Zookeeper本身提供了ordering guarantee，即客户端监听事件后，才会感知它所监视znode发生了变化。所以我们使用Zookeeper不能期望能够监控到节点每次的变化。Zookeeper只能保证最终的一致性，而无法保证强一致性。

6.宕机处理

Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他节点会继续提供服务。

如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失；

如果是一个Leader宕机，Zookeeper会选举出新的Leader。

ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。

比如：

3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5)

2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)

7.实际应用

1.命名服务

前提：

• 唯一性

  由于zookeeper中的节点的结构和文件系统中的目录结构是类似的，想想我们自己的电脑，我们使用一个全路径是不是可以唯一定位到某个目录中的某个文件。如 /home/admin/hollis.txt是可以唯一定位到一个文件的。

• 自增性

  在zookeeper中可以创建顺序节点，在ZooKeeper中，每个父节点会为他的第一级子节点维护一份时序，会记录每个子节点创建的先后顺序。基于这个特性，在创建子节点的时候，可以设置这个属性，那么在创建节点过程中，ZooKeeper会自动为给定节点名加上一个数字后缀，作为新的节点名。如 /home/admin/hollis1 /home/admin/hollis2 /home/admin/hollis3

命名服务

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

2.配置管理

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

3.集群管理

新机器退出和加入

每个服务器启动时都向zk服务器提出创建临时节点的请求，并且使用getChildren设置父节点的观察，当该服务器挂掉之后，它创建的临时节点也被Zookeeper服务器删除，然后会触发监视器，其他服务器便得到通知。创建新节点也是同理。

选择master

zookeeper的节点有两种类型，持久节点跟临时节点。临时节点有个特性，就是如果注册这个节点的机器失去连接(通常是宕机)，那么这个节点会被zookeeper删除。选主过程就是利用这个特性，在服务器启动的时候，去zookeeper特定的一个目录下注册一个临时节点(这个节点作为master，谁注册了这个节点谁就是master)，注册的时候，如果发现该节点已经存在，则说明已经有别的服务器注册了(也就是有别的服务器已经抢主成功)，那么当前服务器只能放弃抢主，作为从机存在。同时，抢主失败的当前服务器需要订阅该临时节点的删除事件，以便该节点删除时(也就是注册该节点的服务器宕机了或者网络断了之类的)进行再次抢主操作。从机具体需要去哪里注册服务器列表的临时节点，节点保存什么信息，根据具体的业务不同自行约定。选主的过程，其实就是简单的争抢在zookeeper注册临时节点的操作，谁注册了约定的临时节点，谁就是master。

4.队列管理

两种队列：

• 同步队列

  当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达

  在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目

• 队列按照 FIFO 方式进行入队和出队操作

  入列有编号，出列按编号。在特定的目录下创建PERSISTENT_SEQUENTIAL节点，创建成功时Watcher通知等待的队列，队列删除序列号最小的节点用以消费。此场景下Zookeeper的znode用于消息存储，znode存储的数据就是消息队列中的消息内容，SEQUENTIAL序列号就是消息的编号，按序取出即可。由于创建的节点是持久化的，所以不必担心队列消息的丢失问题。

5.数据复制

从客户端读写访问的透明度来看，数据复制集群系统分下面两种：

• 写主(WriteMaster)

  对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离；

• 写任意(Write Any)

  对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明。

对zookeeper来说，它采用的方式是写任意。通过增加机器，它的读吞吐能力和响应能力扩展性非常好，而写，随着机器的增多吞吐能力肯定下降（这也是它建立observer的原因），而响应能力则取决于具体实现方式，是延迟复制保持最终一致性，还是立即复制快速响应。

6.分布式锁

1.大致思想

每个客户端对某个方法加锁时，在 Zookeeper 上与该方法对应的指定节点的目录下，生成一个唯一的临时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个临时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题

2.实现排他锁

排他锁核心是保证当前有且仅有一个事务获得锁，并且锁释放之后，所有正在等待获取锁的事务都能够被通知到。

Zookeeper 的强一致性特性，能够很好地保证在分布式高并发情况下节点的创建一定能够保证全局唯一性，即Zookeeper将会保证客户端无法重复创建一个已经存在的数据节点。可以利用Zookeeper这个特性，实现排他锁。

• 定义锁

  通过Zookeeper上的数据节点来表示一个锁

• 获取锁

  客户端通过调用 create 方法创建表示锁的临时节点，可以认为创建成功的客户端获得了锁，同时可以让没有获得锁的节点在该节点上注册Watcher监听，以便实时监听到lock节点的变更情况

• 释放锁
  • 当前获得锁的客户端发生宕机或异常，那么Zookeeper上这个临时节点就会被删除
  • 正常执行完业务逻辑，客户端主动删除自己创建的临时节点

    

3.实现共享锁

共享锁，又称读锁。如果事务T1对数据对象O1加上了共享锁，那么当前事务只能对O1进行读取操作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。

• 定义锁

  通过Zookeeper上的数据节点来表示一个锁，是一个类似于 /lockpath/[hostname]-请求类型-序号 的临时顺序节点

• 获取锁

  客户端通过调用 create 方法创建表示锁的临时顺序节点，如果是读请求，则创建 /lockpath/[hostname]-R-序号 节点，如果是写请求则创建 /lockpath/[hostname]-W-序号 节点

• 判断读写顺序
  • 创建完节点后，获取 /lockpath 节点下的所有子节点，并对该节点注册子节点变更的Watcher监听
  • 确定自己的节点序号在所有子节点中的顺序

    • 对于读请求：

      如果没有比自己序号更小的子节点，或者比自己序号小的子节点都是读请求，那么表明自己已经成功获取到了共享锁，同时开始执行读取逻辑

      如果有比自己序号小的子节点有写请求，那么等待

    • 对于写请求

      如果自己不是序号最小的节点，那么等待

• 接收到Watcher通知后，重复步骤1)

  

4.羊群效应与共享锁改进

在实现共享锁的 “判断读写顺序” 的第1个步骤是：创建完节点后，获取 /lockpath 节点下的所有子节点，并对该节点注册子节点变更的Watcher监听。

这样的话，任何一次客户端移除共享锁之后，Zookeeper将会发送子节点变更的Watcher通知给所有机器，系统中将有大量的 “Watcher通知” 和 “子节点列表获取” 这个操作重复执行，然后所有节点再判断自己是否是序号最小的节点(写请求)或者判断比自己序号小的子节点是否都是读请求(读请求)，从而继续等待下一次通知。

然而，这些重复操作很多都是 “无用的”，实际上每个锁竞争者只需要关注序号比自己小的那个节点是否存在即可

当集群规模比较大时，这些 “无用的” 操作不仅会对Zookeeper造成巨大的性能影响和网络冲击，更为严重的是，如果同一时间有多个客户端释放了共享锁，Zookeeper服务器就会在短时间内向其余客户端发送大量的事件通知–这就是所谓的 “羊群效应”。

改进后的分布式锁实现

• 客户端调用 create 方法创建一个类似于 /lockpath/[hostname]-请求类型-序号 的临时顺序节点
• 客户端调用 getChildren 方法获取所有已经创建的子节点列表(这里不注册任何Watcher)
• 如果无法获取任何共享锁，那么调用 exist 来对比自己小的那个节点注册Watcher
  • 读请求：向比自己序号小的最后一个写请求节点注册Watcher监听
  • 写请求：向比自己序号小的最后一个节点注册Watcher监听
• 等待Watcher监听，继续进入步骤2

5.优点

有效的解决单点问题，不可重入问题，非阻塞问题以及锁无法释放的问题

实现较为简单

6.缺点

性能上不如使用缓存实现的分布式锁，因为每次在创建锁和释放锁的过程中，都要动态创建、销毁临时节点来实现锁功能