Zookeeper中分布式锁的原理是什么

发布时间:2021-08-09 14:49:09 作者:Leah
来源:亿速云 阅读:149

Zookeeper中分布式锁的原理是什么,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。

Zookeeper 的 ZNode 节点

在了解 Zookeeper 实现分布式锁之前,首先,我们需要了解 Zookeeper 里面节点相关的知识。

Zookeeper 里面的节点可以分为两大类,一种是临时节点,一种是持久化节点。

临时节点,指的是节点创建后,如果创建节点的客户端和 Zookeeper 服务端的会话失效(例如断开连接),那么节点就会被删除。

持久化节点指的是节点创建后,即使创建节点的客户端和 Zookeeper  服务端的会话失效(例如断开连接),节点也不会被删除,只有客户端主动发起删除节点的请求,节点才会被删除。

另外还有一种节点叫做有序节点,这种节点在创建时会有一个序号,这个序号是自增的。有序节点既可以是有序临时节点,也可以是有序持久化节点。

Zookeeper 中所有的数据都是通过节点来存储的,它的目录结构就像一个文件树,如下图。

Zookeeper中分布式锁的原理是什么

Zookeeper结构

图中的 locks、register、data 这几个目录自定义创建的,分别用来存储不同业务的数据,例如 locks  用来存放分布式锁相关的信息,register 用来存放注册中心相关的数据。

现在我们要获取一个分布式的所,那么假设这个锁的 K 叫做 K1,那么现在有一个客户端 a,然后去 JK 里面去创建一个分布式的,所创建 K1  这个分布式锁,那么他就会在 nex 这个目录下面创建一个叫做 K1 的文件夹,叫做 K1 的文件。现在我们要获取一个分布式的所,那么假设这个锁的 K 叫做  K1,那么现在有一个客户端 a,然后去 JK 里面去创建一个分布式的,所创建 K1 这个分布式锁,那么他就会在 nex 这个目录下面创建一个叫做 K1  的文件夹,叫做 K1 的文件。

如何实现

采用 Zookeeper 实现分布式锁,有两种方案:1. 基于临时节点实现;2. 基于临时顺序节点实现。下面以及介绍这种方案的实现原理。

首先,假设所有的分布式锁都存储在 locks 这个目录中。

方案一:基于临时节点实现(不推荐)

假设现在有客户端 A、B、C 均来获取同一把分布式锁:Key1。

首先,客户端 A 来获取分布式锁 Key1,那么它就会尝试在 locks 这个目录下去创建一个叫做 Key1 的 ZNode 节点。如果这个时候  locks 目录里面没有 Key1 这个 ZNode 节点,那么客户端 A 就能成功创建 Key1 节点,这就表示客户端 A 成功获取到了 Key1  这把锁锁。

Zookeeper中分布式锁的原理是什么

图1

同时,客户端 B 也来获取 Key1 这把锁。客户端 B 也需要去 locks 这个目录里面去创建 Key1 ZNode 节点,这个时候,由于 Key1  这个 ZNode 节点已经存在,所以客户端 B 就会创建失败。而创建失败就表示客户端 B 获取锁失败,所以这个时候客户端 B 就会向 Zookeeper  注册自己的监听器(Watcher),监听 Key1 这个 ZNode 节点的变化(当 Key1 节点发生变化时,Zookeeper 会通知到客户端  B)。

如果客户端 A 和客户端 B,是同时请求到 Zookeeper,那么 Zookeeper 它有一个机制,它会保证只会有其中一个客户端能创建成功 Key1  这个 ZNode 节点。

Zookeeper中分布式锁的原理是什么

图2

同理,此时客户端 C 来获取 Key1 锁时,也是无法获取到锁,也会把自己的 Watcher 注册到 ZK 中,监听 Key1 这个 ZNode  节点的变化。

当客户端 A 处理完自己的业务逻辑之后,那么就会执行释放锁的操作。释放锁时,客户端删除 Key1 节点,如果节点删除成功就表示锁释放成功。当 Key1  这个节点被删除后,Zookeeper 就会通知所有监听 Key1 这个节点的客户端,也就是客户端 B、C。

当客户端 B 和 C 接到通知以后,知道 Key1 节点发生了变化,这个时候它们就会重新去请求 Zookeeper,尝试在 locks 目录下面创建  Key1 节点,这个时候也只会有一个客户端能成功创建 Key1 节点。假如说是客户端 B 创建成功了,那么就表示客户端 B 成功获取到了锁.客户端 C  获取锁失败,那么就继续去监听 Key1 这个节点的变化。

Zookeeper中分布式锁的原理是什么

图3

为什么不推荐

以上就是基于临时节点这个方案去实现 Zookeeper  分布式锁,但是这个方案通常是不被推荐的。为什么呢?这是因为使用这个方案会存在一个很大的问题:羊群效应。

什么意思呢?

从上面的过程中我们可以看到,当客户端 A 释放锁成功以后,Zookeeper 需要去通知所有监听 Key1 这个节点的客户端。上面我们的例子中只有客户端  B 和客户端 C,但是在实际应用中可能有成百上千个客户端,甚至更多。Zookeeper  在这一瞬间需要发送成百上千个请求,首先这个效率显然是不高的,另外当分布式锁的竞争较为激烈时,极有可能在这一瞬间 Zookeeper  的网卡可能被撑爆。而且系统中可能并不仅仅存 Key1 这一把锁,还会存在 Key2、Key3、Key4...,这些锁也会存在竞争,Zookeeper  的压力会更大。

在这个过程中,我们很明显地能感觉到这是不合理的,因为获取分布式锁时肯定是只有其中一个客户端能获取到,那么当 Key1  这个节点被删除以后,需要通知其他的客户端来获取锁,这个时候我们有必要去通知所有的客户端吗?

显然是没有必要的,我们只需要通知其中一个客户端就可以了。因此方案二出现了。

方案二:基于临时顺序节点实现(推荐)

基于临时顺序节点去实现分布式锁时,就不是在 Linux 这个目录下面创建 Key1 这个临时节点了。而是先在 locks 这个目录下面创建一个 Key1  目录,然后在 Key1 目录里面去创建临时顺序节点。

假设现在客户端 a 来获取分布式锁 Key1,那么这个时候客户端 A 就会在 Key1 这个目录里面创建一个临时顺序节点,这个临时顺序节点的序号是  001。

然后客户端 A 会判断自己创建的这个临时顺序节点 001 在 Key1 这个目录里面,它的序号是不是最小的?如果是最小的,那么就表示客户端 A  获取锁成功。

接着客户端 B 也来获取 Key1 这个分布式锁,它也会在 Key1 这个目录下面去创建一个临时顺序节点,由于这个时候自增序号已经变为 002  了,因为之前已经创建过 001 了,所以客户端 B 会创建 002 这个临时顺序节点。

Zookeeper中分布式锁的原理是什么

图4

同理,客户端 B 也会判断自己当前创建的临时顺序节点 002,是不是当前 Key1 目录中序号最小的临时节点,显然不是,因为前面有一个 001  临时顺序节点,所以客户端 B 这个时候是获取锁失败。

当客户端 B 获取锁失败之后,它会把自己的监听器注册到 Zookeeper,它监听的是它前面一个临时顺序节点,也就是 001 这个顺序节点。

Zookeeper中分布式锁的原理是什么

图5

此时如果客户端 C 也来获取分布式锁 Key1,这个时候它就会在 Key 目录中创建临时顺序节点 003,同样 003  也不是序号最小的临时顺序节点,所以客户端 C 也获取锁失败,接着它会去监听 002 这个临时顺序节点。

当客户端 A 处理完业务逻辑之后,它就会去释放锁。释放锁的操作就是去删除 Key1 这个目录下面客户端 A 所创建的临时顺序节点,也就是删除 001  这个临时顺序节点。当 001 这个顺序节点被删除以后,Zookeeper 就会去通知监听 001 这个顺序节点的所有客户端,也就是通知客户端 B。客户端 B  接收到 Zookeeper 的通知之后,它就会去判断我当前创建的临时顺序节点 002 是不是当前 Key1 这个目录中序号最小的一个临时顺序节点。此时由于  001 这个顺序节点已经不存在了,显然 002 是最小的了,因此客户端 B 就获取锁成功。

Zookeeper中分布式锁的原理是什么

图6

同样当客户端 B 释放锁之后,就会将 002 删除,002 删除以后,Zookeeper 会通知客户端 C,客户端 C 发现我当前创建的临时顺序节点  003 是 Key1 这个目录里面最小的序号,所以客户端 C 获取锁成功。

看完上述内容,你们掌握Zookeeper中分布式锁的原理是什么的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注亿速云行业资讯频道,感谢各位的阅读!

推荐阅读:
  1. Zookeeper的核心原理是什么
  2. ZooKeeper的基本原理是什么

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

zookeeper

上一篇:MySQL中order by的实现原理是什么

下一篇:Java中怎么实现一个UML接口

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》