ZooKeeper 的功能和原理初探

Posted 2023-04-12

参考技术A 在公司核心系统的开发过程中用到了ZooKeeper，简称zk，用于搭建分布式核心环境，开发过程中也经常会遇到zk出现的问题，看了几篇博客了解和总结一下zk的基本原理。

ZooKeeper 主要有几个重要的概念，简单总结下：

ZooKeeper 中主要有三种角色：Leader、Follower、Observer

一个 ZooKeeper 集群同一时刻只会有一个 Leader，其他都是 Follower 或 Observer。

ZooKeeper 集群的所有机器通过一个 Leader 选举过程来选定一台被称为『Leader』的机器，Leader服务器为客户端提供读和写服务。

Follower 和 Observer 都能提供读服务，不能提供写服务。两者唯一的区别在于，Observer机器不参与 Leader 选举过程，也不参与写操作的『过半写成功』策略，因此 Observer 可以在不影响写性能的情况下提升集群的读性能。

每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。 

Session 是指客户端会话。在ZooKeeper 中，一个客户端连接是指客户端和 ZooKeeper 服务器之间的TCP长连接。

ZooKeeper 对外的服务端口默认是2181，客户端启动时，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测和服务器保持有效的会话，也能够向 ZooKeeper 服务器发送请求并接受响应，同时还能通过该连接接收来自服务器的 Watch 事件通知。

Session 的 SessionTimeout 值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在SessionTimeout 规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

zookeeper的结构其实就是一个树形结构，leader就相当于其中的根结点，其它节点就相当于follow节点，每个节点都保留自己的内容。

zookeeper的节点分两类： 持久节点 和 临时节点

持久节点：所谓持久节点是指一旦这个 树形结构上被创建了，除非主动进行对树节点的移除操作，否则这个 节点将一直保存在 ZooKeeper 上。

临时节点：临时节点的生命周期跟客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。

有四种类型的znode： 

1、PERSISTENT-持久化目录节点 

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

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

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

3、EPHEMERAL-临时目录节点 

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

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

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

每个 节点除了存储数据内容之外，还存储了 节点本身的一些状态信息。用 get 命令可以同时获得某个 节点的内容和状态信息

在 ZooKeeper 中，version 属性是用来实现乐观锁机制中的『写入校验』的（保证分布式数据原子性操作）。

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

在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。对应每一个事务请求，为了保证事务的顺序一致性，ZooKeeper都会为其分配一个全局唯一的事务ID，用 ZXID 表示，通常是一个64位的数字。每一个 ZXID对应一次更新操作，从这些 ZXID 中可以间接地识别出 ZooKeeper 处理这些事务操作请求的全局顺序。

ZooKeeper允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去。该机制是 ZooKeeper 实现分布式协调服务的重要特性。

搞懂分布式技术3：初探分布式协调服务zookeeper

搞懂分布式技术3：初探分布式协调服务zookeeper

1.Zookeepr是什么

Zookeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅，负载均衡，命名服务，分布式协调/通知。集群管理，Master选举，分布式锁和分布式队列等功能。

2.zookeeper可以保证的分布式一致性

a.顺序一致性

从一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到zookeeper中去

b.原子性

所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的。

c.单一视图

任意客户端看到的服务器数据模型都是一致的

d.可靠性

一旦服务成功的应用了一个事务，并完成对客户端响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非另一个事务又对其进行变更

e.实时性

Zookeeper仅仅保证在一定时间内，客户端最终一定能够从服务器上读取到最新的数据状态。

3.zookeeper的设计目标

目标一：简单的数据模型

Zookeeper可以让分布式程序能通过一个共享的、树型结构的名字空间来进行相互协调（和windows系统的文件结构相同，是有一系列的ZNode节点之间的层级关系构成）

 

目标二：可构建集群

3到5台机器就可以组成一个可用的zookeeper集群

 

目标三：顺序访问

对于来自客户端的每一个更新请求，zookeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序。

目标四：高性能

Zookeeper把所有的节点数据都存储在内存中（提高了服务器吞吐、减少了延迟），并直接服务于客户端所有非事务请求，因此尤其适用于以读操作为主的应用场景。

4.zookeeper的基本概念

集群角色

在 zookeeper 集群中，各个节点总共有三种角色，分别是：leader，follower，observer

而不是Master/slave（主备机模式）

会话（session）

Session是指客户端的会话，Zookeeper对外的端口默认2181，可以通过sessionTimeout设置会话超时时间，由于服务器压力、网络原因或客户端主动断开等原因使客户端链接断开，只要在sessionTimeout规定时间内就能够重新链接上集群的任意一台服务器，之前的会话仍然有效。

数据节点（ZNode）

ZNode保存在zookeeper内存中，数据模型是一个树（ZNode Tree）由（/）进行分割路径

版本

每个节点都会存储数据，zookeeper会为其维护一个Stat的数据结构，其中包括三个版本信息

cversion= 0 子节点的版本号

aclVersion= 0 表示acl的版本号，修改节点权限

dataVersion= 1 表示的是当前节点数据的版本号

 

Watcher

Watcher(事件监听器)，非常重要的特性。Zookeeper允许用户在指点节点上注册一些Watcher，并在一些特定的事件触发的时候，通知客户端（可实现分布式协调服务）

 

Zookeeper的Watcher VS JVM?

从某种角度来说，可以这样对比（个人看法，可以讨论），ZooKeeper对等于JVM，ZooKeeper包含状态对象（ZNode）和分布式进程的底层执行引擎Zab，而JVM内部包含堆（多线程共享的大量对象存放区域）和多线程执行正确性约束规范JMM（Java内存模型），JMM确保了多线程的执行顺序是正确的。Zab协议使得ZooKeeper的内部修改状态操作直接是有序串行的，而JVM内部则是乱序并行的，需要添加额外的机制才能保证时序（内存屏障、处理器原子指令），而状态读取时，JVM和ZooKeeper都存在直接读取时读到旧数据，但ZooKeeper有Watch机制使得响应式读取更高效，而JVM只能使用底层的内存屏障刷新共享状态，以便其他线程再次读取时获得正确的新数据。

ZooKeeper提供的接口使得所有的分布式进程的执行都是异步非阻塞的（WaitFree算法），内部是基于Version的CAS操作，而JVM提供了阻塞的和非阻塞的多种接口，有Synchronized、Volatile、AtomicOperations。基于接口之上构建线程或分布式进程之间更复杂的同步或协调功能时，Java并发库直接提供了闭锁、循环栅栏、信号量等同步工具以及基础的抽象队列同步器，而ZooKeeper则需要用户基于接口自行构建各种分布式协调功能（分布式锁、分布式发布订阅、集群成员关系管理）

对比:

        ZooKeeper                       JVM

共享状态对象: ZNode 堆中对象

底层执行模式: Zab顺序执行 多处理器并发执行（内存屏障、原子机器指令）

API接口: Get、Watch_Get、Cas_Set、Exist Synchronized、volatile、final、Atomic

协调或同步功能: 分布式发布订阅、锁、读写锁 并发库同步工具、基于抽象队列同步器构建的同步组件

Zookepper的Watcher架构?

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

Zookeeper的Watcher机制主要包括客户端线程、客户端WatcherManager、Zookeeper服务器三部分。客户端在向Zookeeper服务器注册的同时，会将Watcher对象存储在客户端的WatcherManager当中。当Zookeeper服务器触发Watcher事件后，会向客户端发送通知，客户端线程从WatcherManager中取出对应的Watcher对象来执行回调逻辑。

Zookepper的Watcher的特性?

1.Watch是一次性的，每次都需要重新注册，并且客户端在会话异常结束时不会收到任何通知，而快速重连接时仍不影响接收通知。

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

3.Watch是轻量级的，WatchEvent是最小的通信单元，结构上只包含通知状态、事件类型和节点路径。ZooKeeper服务端只会通知客户端发生了什么，并不会告诉具体内容。

 

ACL

access control list

权限控制

CREATE:创建子节点的权限

READ：获取子节点数据和子节点列表的权限

WRITE：更新节点数据的权限

DELETE：删除节点数据的权限

ADMIN：设置节点ACL的权限