答应我,不会这些概念,简历不要写 “熟悉” zookeeper

整理了一些Java方面的架构、面试资料(微服务、集群、分布式、中间件等),有需要的小伙伴可以关注公众号【程序员内点事】,无套路自行领取

唠唠叨叨

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

面试官:用过 zookeeper 吗?

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

面试官:知道 zookeeper 是什么吗?

我:知道啊,注册中心嘛

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

我:就在 springbootapplication.properties 配置文件里添加一个 zookeeper 服务地址就行了。。。

.

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

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

一、zookeeper初识?

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

1、zookeeper数据模型

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

由于 zookeeper 是目录节点结构,在获取和创建节点时,必须要以 “/” 开头,否则在获取节点时会报错 Path must start with / character

[zk: localhost:2181(CONNECTED) 13] get test
Command failed: java.lang.IllegalArgumentException: Path must start with / character

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

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

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

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

2、znode节点属性

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

[zk: localhost:2181(CONNECTED) 6] get /test
456
cZxid = 0x59ac //
ctime = Mon Mar 30 15:20:08 CST 2020
mZxid = 0x59ad
mtime = Mon Mar 30 15:22:25 CST 2020
pZxid = 0x59ac
cversion = 0
dataVersion = 2
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 3
numChildren = 0
节点属性 注解
cZxid 该数据节点被创建时的事务Id
mZxid 该数据节点被修改时最新的事物Id
pZxid 当前节点的父级节点事务Id
ctime 该数据节点创建时间
mtime 该数据节点最后修改时间
dataVersion 当前节点版本号(每修改一次值+1递增)
cversion 子节点版本号(子节点修改次数,每修改一次值+1递增)
aclVersion 当前节点acl版本号(节点被修改acl权限,每修改一次值+1递增)
ephemeralOwner 临时节点标示,当前节点如果是临时节点,则存储的创建者的会话id(sessionId),如果不是,那么值=0
dataLength 当前节点所存储的数据长度
numChildren 当前节点下子节点的个数

我们看到一个 znode 节点的属性比较多,但比较主要的属性还是 zxidversionacl 这三个。

Zxid:

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

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

Version:

znode 属性中一共有三个版本号 dataversion (数据版本号)、 cversion (子节点版本号)、 aclversion (节点所拥有的ACL权限版本号)。

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

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

[zk: localhost:2181(CONNECTED) 10] set /test 8888
cZxid = 0x59ac
ctime = Mon Mar 30 15:20:08 CST 2020
mZxid = 0x59b6
mtime = Mon Mar 30 16:58:08 CST 2020
pZxid = 0x59ac
cversion = 0
dataVersion = 3
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0

3、znode的类型

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

zookeeper.create("/公众号/程序员内点事", "".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
  • PERSISTENT -持久化目录节点 :client创建节点后,与zookeeper断开连接该节点将被持久化,当client再次连接后节点依旧存在。

  • PERSISTENT_SEQUENTIAL -持久化顺序节点 :client创建节点后,与zookeeper断开连接该节点将被持久化,再次连接节点还存在,zookeeper会给该节点名称进行顺序编号,例如:/lock/0000000001、/lock/0000000002、/lock/0000000003。

  • EPHEMERAL -临时目录节点 : client与zookeeper断开连接后,该节点即会被删除

  • EPHEMERAL_SEQUENTIAL -临时顺序节点 : client与zookeeper断开连接后,该节点被删除,会给该节点名称进行顺序编号,例如:/lock/0000000001、/lock/0000000002、/lock/0000000003。

二、节点的ACL权限控制

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

zookeeper 中设置ACL权限的格式由 :: 三段组成。

schema:表示授权的方式

world
auth
digest
host/ip

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

acl:给一个节点赋予哪些权限,节点的权限有create,、delete、write、read、admin 统称 cdwra

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

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

[zk: localhost:2181(CONNECTED) 12] getAcl /test
'world,'anyone
: cdrwa

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

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

setAcl /test world:anyone:crdwa

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

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

addauth digest test:password(明文)

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

[zk: localhost:2181(CONNECTED) 2] addauth digest user:user //用户名:密码
[zk: localhost:2181(CONNECTED) 5] setAcl /test auth:user:crdwa
[zk: localhost:2181(CONNECTED) 6] getAcl /test
'digest,'user:ben+k/3JomjGj4mfd4fYsfM6p0A=
: cdrwa

实际上我们这样设置以后,就是将这个节点开放给所有认证的用户, setAcl /test auth:user:crdwa 相当于 setAcl /test auth::crdwa

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

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

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

setAcl  digest:::

setAcl /test digest:user:jalRr+knv/6L2uXdenC93dEDNuE=:crdwa

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

通过 shell 命令加密

echo -n : | openssl dgst -binary -sha1 | openssl base64

使用 zookeeper 自带的类库 org.apache.zookeeper.server.auth.DigestAuthenticationProvider 生成

java -cp /zookeeper-3.4.13/zookeeper-3.4.13.jar:/zookeeper-3.4.13/lib/slf4j-api-1.7.25.jar \
  org.apache.zookeeper.server.auth.DigestAuthenticationProvider \
  root:root
root:root->root:qiTlqPLK7XM2ht3HMn02qRpkKIE=

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

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

[zk: localhost:2181(CONNECTED) 3] setAcl /test0000000014 ip:127.0.0.1:crdwa
cZxid = 0x59ac
ctime = Mon Mar 30 15:20:08 CST 2020
mZxid = 0x59b6
mtime = Mon Mar 30 16:58:08 CST 2020
pZxid = 0x59ac
cversion = 0
dataVersion = 3
aclVersion = 3 // 这个版本一直在增加
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0

三、zookeeper的灵魂 watcher

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

1、watcher是个啥?

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

简单的介绍了一下 watcher ,那么我们来分析一下, zookeeper 是如何实现服务的注册与发现。

zookeeper 的服务注册与发现,主要应用的是 zookeeperznode 节点数据模型和 watcher 机制,大致的流程如下:

  • 服务注册:服务提供者( Provider )启动时,会向 zookeeper服务端 注册服务信息,也就是创建一个节点,例如:用户注册服务 com.xxx.user.register ,并在节点上存储服务的相关数据(如服务提供者的ip地址、端口等)。

  • 服务发现:服务消费者( Consumer )启动时,根据自身配置的依赖服务信息,向 zookeeper服务端 获取注册的服务信息并设置 watch监听 ,获取到注册的服务信息之后,将服务提供者的信息缓存在本地,并进行服务的调用。

  • 服务通知:一旦服务提供者因某种原因宕机不再提供服务之后,客户端与 zookeeper 服务端断开连接, zookeeper 服务端上服务提供者对应服务节点会被删除(例如:用户注册服务 com.xxx.user.register ),随后 zookeeper 服务端会异步向所有消费用户注册服务 com.xxx.user.register ,且设置了 watch监听 的服务消费者发出节点被删除的通知,消费者根据收到的通知拉取最新服务列表,更新本地缓存的服务列表。

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

2、watcher类型

znode 节点可以设置两类 watch ,一种是 DataWatches ,基于znode节点的数据变更从而触发 watch 事件,触发条件 getData()exists()setData()create()

另一种是 Child Watches ,基于znode的孩子节点发生变更触发的watch事件,触发条件 getChildren()create()

而在调用 delete() 方法删除znode时,则会同时触发 Data WatchesChild Watches ,如果被删除的节点还有父节点,则父节点会触发一个 Child Watches

3、watcher特性

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

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

四、zookeeper能实现哪些功能

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

1、分布式锁

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

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

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

这里我们让 /test/lock/seq-00000002 节点监听 /test/lock/seq-00000001 节点,一旦 /test/lock/seq-00000001 节点删除,则通知 /test/lock/seq-00000002 节点,让它再次判断自己是不是最小的节点,是则拿到锁,不是继续等通知。

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

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

2、分布式队列

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

3、配置管理

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

4、命名服务

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

总结

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

今天就说这么多,如果本文对您有一点帮助,希望能得到您一个点赞:+1:哦

您的认可才是我写作的动力!

小福利:

通过合法手段,获取到一些极客付费课程 ,嘘~, 免费 送给小伙伴们。关注公众号回复【 极客 】自行领取