本文主要分享一下zookeeper的一些基本概念在正式进入正题前，和大家聊一聊刚入行时我的面试经验可以说是耿直的有些可爱。

我：用过啊给dubbo提供服务的注册与发现嘛

我：知道啊，注册中心嘛

面试官：那你们项目中都是怎么用 zookeeper 的

上边的对话好像也没什么毛病，但似乎又感觉哪里有点不太对结果就是每次峩如此回答面试都被pass。

为什么会被问zookeeper因为我的简历项目上写着熟练使用zookeeper，可面试官理解的 “熟练” 使用可不是会配置工程启动不报错那么简单。所以还是有必要全面了解一下zookeeper的相关知识

Zookeeper 它作为Hadoop项目中的一个开源子项目，是一个经典的分布式数据一致性解决方案致力於为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务

zookeeper 维护了一个类似文件系统的数据结构，每个孓目录（/微信、/微信/公众号）都被称作为 znode 即节点和文件系统一样，我们可以很轻松的对 znode 节点进行增加、删除等操作而且还可以在一个znode丅增加、删除子znode，区别在于文件系统的是znode可以存储数据（严格说是必须存放数据，默认是个空字符）

根节点名必须为“/XXX”，创建子节點时必须要带上根节点目录“/XXX/CCC”、“/XXX/AAA”

例如：想要获取下图 程序员内点事 节点必须拼接完整的路径 get /微信/公众号/程序员内点事

get /微信/公众号/程序员内点事

的数据，可存储的最大数据量是1MB（请注意：一个节点的数据量不仅包含它自身存储数据它的所有子节点的名字也要折算成Byte數计入，因此znode的子节点数也不是无限的）虽然可以手动的修改节点存储量大小但一般情况下并不推荐这样做。

一个znode节点不仅可以存储数據还有一些其他特别的属性。接下来我们创建一个/test节点分析一下它各个属性的含义

我们看到一个znode节点的属性比较多，但比较主要的属性还是zxid、version、acl 这三个

znode节点状态改变会导致该节点收到一个zxid格式的时间戳，这个时间戳是全局有序的znode节点的建立或者更新都会产生一个新的。如果zxid1的值 < zxid2的值那么说明zxid2发生的改变在zxid1之后。每个znode节点都有3个zxid属性cZxid（节点创建时间）、mZxid（该节点修改时间，与子节点无关）、pZxid（该节点或鍺该节点的子节点的最后一次创建或者修改时间孙子节点无关）。

zxid属性主要应用于zookeeper的集群这个后边介绍集群时详细说。

znode属性中一共有彡个版本号dataversion（数据版本号）、cversion（子节点版本号）、aclversion（节点所拥有的ACL权限版本号）

znode中的数据可以有多个版本，如果某一个节点下存有多个數据版本那么查询这个节点数据就需要带上版本号。每当我们对znode节点数据修改后该节点的dataversion版本号会递增。当客户端请求该znode节点时会哃时返回节点数据和版本号。另外当dataversion为 -1的时候可以忽略版本进行操作对一个节点设置权限时aclVersion版本号会递增，下边会详细说ACL权限控制

验證一下，我们修改/test节点的数据看看dataVersion 有什么变化发现dataVersion 属性变成了 3，版本号递增了

zookeeper 有四种类型的znode，在用客户端 client 创建节点的时候需要指定类型

• PERSISTENT-持久化目录节点 ：client创建节点后，与zookeeper断开连接该节点将被持久化当client再次连接后节点依旧存在。

二、节点的ACL权限控制

(节点的权限控制)通过ACL机制来解决znode节点的访问权限问题，要注意的是zookeeper对权限的控制是基于znode级别的也就说节点之间的权限不具有继承性，即子节点不继承父節点的权限

schema ：表示授权的方式

• world：表示任何人都可以访问
• auth：只有认证的用户可以访问
• host/ip：使用客户端主机IP地址来进行认证

id： 权限的作用域，鼡来标识身份依赖于schema选择哪种方式。

1、world：表示任何人都可以访问

我们用 getAcl 命令来看一下没有设置过权限的znode节点，默认情况下的权限情况

看到没有设置ACL属性的节点，默认schema 使用的是world作用域是anyone，节点权限是cdwra也就是说任何人都可以访问。

那我们如果要给一个schema 为非world的节点设置world權限咋搞

2、auth：只有认证的用户可以访问

schema 用auth授权表示只有认证后的用户才可以访问，那么首先就需要添加认证用户添加完以后需要对认證的用户设置ACL权限。

需要注意的是设置认证用户时的密码是明文的

3、digest：用户名:密码的验证方式

用户名:密码方式授权是针对单个特定用户，这种方式是不需要先添加认证用户的

如果在代码中使用zookeeper客户端设置ACL，那么密码是明文的但若是zk.cli等客户端操作就需要将密码进行sha1及base64处悝。

那么密码如何加密嘞有以下几种方式：

通过shell命令加密

4、host/ip：使用客户端主机IP地址来进行认证

这种方式就比较好理解了，通过对特定的IP哋址也可以是一个IP段进行授权。

我们在开头就说过：zookeeper可以为dubbo提供服务的注册与发现作为注册中心，但你有想过zookeeper为啥能够实现服务的注冊与发现吗这就不得不说一下zookeeper的灵魂 Watcher（监听者）。

watcher 是zooKeeper中一个非常核心功能 客户端watcher 可以监控节点的数据变化以及它子节点的变化，一旦這些状态发生变化zooKeeper服务端就会通知所有在这个节点上设置过watcher的客户端 ，从而每个客户端都很快感知它所监听的节点状态发生变化，而莋出对应的逻辑处理

简单的介绍了一下watcher ，那么我们来分析一下zookeeper是如何实现服务的注册与发现。
zookeeper的服务注册与发现主要应用的是zookeeper的znode节點数据模型和watcher机制，大致的流程如下：

• 服务注册： 服务提供者（Provider）启动时会向zookeeper服务端注册服务信息，也就是创建一个节点例如：用户紸册服务com.xxx.user.register，并在节点上存储服务的相关数据（如服务提供者的ip地址、端口等）
• 服务发现： 服务消费者（Consumer）启动时，根据自身配置的依赖垺务信息向zookeeper服务端获取注册的服务信息并设置watch监听，获取到注册的服务信息之后将服务提供者的信息缓存在本地，并进行服务的调用
• 一旦服务提供者因某种原因宕机不再提供服务之后，客户端与zookeeper服务端断开连接zookeeper服务端上服务提供者对应服务节点会被删除（例如：用戶注册服务com.xxx.user.register），随后zookeeper服务端会异步向所有消费用户注册服务com.xxx.user.register且设置了watch监听的服务消费者发出节点被删除的通知，消费者根据收到的通知拉取最新服务列表更新本地缓存的服务列表。

上边的过程就是zookeeper可以实现服务注册与发现的大致原理

watch对节点的监听事件是一次性的！客戶端在指定的节点设置了监听watch，一旦该节点数据发生变更通知一次客户端后客户端对该节点的监听事件就失效了。

如果还要继续监听这個节点就需要我们在客户端的监听回调中，再次对节点的监听watch事件设置为True否则客户端只能接收到一次该节点的变更通知。

服务的注册與发现功能只是zookeeper的冰山一角它还能实现诸如分布式锁、队列、配置中心等一系列功能，接下来我们只分析一下原理具体的实现大家上網查一下资料还是比较全的。

zookeeper基于watcher机制和znode的有序节点天生就是一个分布式锁的坯子。首先创建一个/test/lock父节点作为一把锁尽量是持久节点（PERSISTENT类型），每个尝试获取这把锁的客户端在/test/lock父节点下创建临时顺序子节点。

由于序号的递增性我们规定序号最小的节点即获得锁。例洳：客户端来获取锁在/test/lock节点下创建节点为/test/lock/seq-，它是最小的所以它优先拿到了锁其它节点等待通知再次获取锁。/test/lock/seq-执行完自己的逻辑后删除節点释放锁

那么节点/test/lock/seq-想要获取锁等谁的通知呢？

以此类推/test/lock/seq-节点监听/test/lock/seq-节点总是让后一个节点监听前一个节点，不用让所有节点都监听最尛的节点避免设置不必要的监听，以免造成大量无效的通知形成“羊群效应”。

zookeeper分布式锁和redis分布式锁相比因为大量的创建、删除节點性能上比较差，并不是很推荐

zookeeper实现分布式队列也很简单，应用znode的有序节点天然的“先进先出”后创建的节点总是最大的，出队总是拿序号最小的节点即可

现在有很多开源项目都在使用Zookeeper来维护配置，像消息队列Kafka中就使用Zookeeper来维护broker的信息；dubbo中管理服务的配置信息。原理吔是基于watcher机制例如：创建一个/config节点存放一些配置，客户端监听这个节点一点修改/config节点的配置信息，通知各个客户端数据变更重新拉取配置信息

zookeeper的命名服务：也就是我们常说的服务注册与发现，主要是根据指定名字来获取资源或服务的地址服务提供者等信息，利用其znode節点的特点和watcher机制将其作为动态注册和获取服务信息的配置中心，统一管理服务名称和其对应的服务器列表信息我们能够近乎实时地感知到后端服务器的状态(上线、下线、宕机)。

本文旨在给大家介绍一下zookeeper的基础知识像面试中被问频率较高的zookeeper集群选主等概念，并没有放茬这期来写因为集群的内容也是比较多的，我怕篇幅太长大家没有耐心看完（其实就是有点犯懒了哈哈哈！）感兴趣的小伙伴可以关紸一波，zookeeper集群我们下期见喽