ZK(ZooKeeper)分布式锁实现(1)

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: ZK(ZooKeeper)分布式锁实现

准备

本文会使用到 三台 独立服务器,可以自行提前搭建好。

不知道如何搭建的,可以看我之前 ZooKeeper集群 搭建:Zookeeper 集群部署的那些事儿

关于ZooKeeper 一些基础命令可以看这篇:Zookeeper入门看这篇就够了

前言


在平时我们对锁的使用,在针对单个服务,我们可以用 Java 自带的一些锁来实现,资源的顺序访问,但是随着业务的发展,现在基本上公司的服务都是多个,单纯的 Lock或者Synchronize 只能解决单个JVM线程的问题,那么针对于单个服务的 Java 的锁是无法满足我们业务的需要的,为了解决多个服务跨服务访问共享资源,于是就有了分布锁,分布式锁产生的原因就是集群。


屏幕快照 2022-05-11 上午11.44.09.png

正文


实现分布式锁的方式有哪些呢?


分布式锁的实现方式主要以(ZooKeeper、Reids、Mysql)这三种为主

今天我们主要讲解的是使用 ZooKeeper来实现分布式锁,ZooKeeper的应用场景主要包含这几个方面:


服务注册与订阅(共用节点)

分布式通知(监听ZNode)

服务命令(ZNode特性)

数据订阅、发布(Watcher)

分布式锁(临时节点)

ZooKeeper实现分布式锁,主要是得益于ZooKeeper 保证了数据的强一致性,锁的服务可以分为两大类:


保持独占


所有试图来获取当前锁的客户端,最终有且只有一个能够成功得到当前锁的钥匙,通常我们会把 ZooKeeper 上的节点(ZNode)看做一把锁,通过 create临时节点的方式来实现,当多个客户端都去创建一把锁的时候,那么只有成功创建了那个客户端才能拥有这把锁

控制时序


所有试图获取锁的客户端,都是被顺序执行,只是会有一个序号(zxid),我们会有一个节点,例如:/testLock,所有临时节点都在这个下面去创建,ZK的父节点(/testLock) 维持了一个序号,这个是ZK自带的属性,他保证了子节点创建的时序性,从而也形成了每个客户端的一个 全局时序

ZK锁机制


在实现ZooKeeper 分布式锁之前我们有必要了解一下,关于ZooKeeper分布式锁机制的实现流程和原理,不然各位宝贝,出去面试的时候怎么和面试官侃侃而谈~


临时顺序节点


基于ZooKeeper的临时顺序节点 ,ZooKeeper比较适合来实现分布式锁:


顺序发号器: ZooKeeper的每一个节点,都是自带顺序生成器:在每个节点下面创建临时节点,新的子节点后面,会添加一个次序编号,这个生成的编号,会在上一次的编号进行 +1 操作

有序递增: ZooKeeper节点有序递增,可以保证锁的公平性,我们只需要在一个持久父节点下,创建对应的临时顺序节点,每个线程在尝试占用锁之前,会调用watch,判断自己当前的序号是不是在当前父节点最小,如果是,那么获取锁

Znode监听: 每个线程在抢占所之前,会创建属于当前线程的ZNode节点,在释放锁的时候,会删除创建的ZNode,当我们创建的序号不是最小的时候,会等待watch通知,也就是上一个ZNode的状态通知,当前一个ZNode删除的时候,会触发回调机制,告诉下一个ZNode,你可以获取锁开始工作了

临时节点自动删除:ZooKeeper还有一个好处,当我们客户端断开连接之后,我们出创建的临时节点会进行自动删除操作,所以我们在使用分布式锁的时候,一般都是会去创建临时节点,这样可以避免因为网络异常等原因,造成的死锁。

羊群效应: ZooKeeper节点的顺序访问性,后面监听前面的方式,可以有效的避免 羊群效应,什么是羊群效应:当某一个节点挂掉了,所有的节点都要去监听,然后做出回应,这样会给服务器带来比较大压力,如果有了临时顺序节点,当一个节点挂掉了,只有它后面的那一个节点才做出反应。

我们现在看一下下面一张图:


屏幕快照 2022-05-11 上午11.44.51.png

在上图中,ZooKeeper里面有一把锁节点 testLock,这个锁就是ZooKeeper的一个节点,当两个客户端来获取这把锁的时候,会对ZooKeeper进行加锁的请求,也就是我们所说的 临时顺序节点。


当我们在 /testLock目录下创建了一个顺序临时节点后,ZK会自动对这个临时节点维护 一个节点序号,并且这个节点是递增的,比如我们 clientA 创建了一个临时顺序节点,ZK内部会生成一个序号:/lock0000000001,那么 clientB 也生成了一个临时顺序节点,ZK会生成一个序号为 /lock0000000002,在这里数字都是依次递增的,从1开始递增,ZK内部会维护这个顺序。


下图所示:


屏幕快照 2022-05-11 上午11.45.02.png


这时候,ClientA会进行监听判断,在父节点下,我是不是最小的,如果是的话,那么俺就可以加锁了,因为我是最小的,其他的都比我大。我自己可以进行加锁,**你已经是一个成熟的临时节点了,要学会自己加锁。**咳,那么ZK是怎么进行判断的呢?宝贝,您往下看:

屏幕快照 2022-05-11 上午11.43.57.png

这个是cleintA已经加锁完成了,这个时候clientB也要过来加锁,那么他也要在/testLock,创建一个属于自己的临时节点,那么这个时候他的序号就会变成/lock0000000002,如下图所示:

屏幕快照 2022-05-11 上午11.45.39.png

clientA 加锁成功后,会进行自己的业务处理,当 clientA 处理完工作后,说我完事了,下一个,那么 clientA 是怎么完事的呢,他多长时间?不是,具体流程是怎样的?小农你不对劲,说什么呢!!!真羞涩


上面我们不是说了,当 clientB 加锁失败后,会给前一个节点(clientA)加上一个监听,当clientA被删除以后,就表示有人释放了锁,这个时候就会通知 clientB重新去获取锁。

屏幕快照 2022-05-11 上午11.46.05.png

这个时候clientB重新获取锁的时候,发现自己就是当前父节点下面最小的那个,于是clientB就开始加锁,开始工作等一系列操作,当clientB 完事以后,释放锁,也说了一句,下一个。

如下图所示:屏幕快照 2022-05-11 上午11.46.21.png

当然除了 clientA、clientB还有C\D\E等,这字母看着好奇怪又好熟悉,原理都是一样的,都是最小节点进行解锁,如果不是,监听前一个节点是否释放,如果释放了,再次尝试加锁。如果前一节节点释放了,自己就是最小了,就排到前面去了,有点类似于 银行取号 的操作。

相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
目录
相关文章
|
2月前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
2月前
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1
|
27天前
|
分布式计算 NoSQL Java
Hadoop-32 ZooKeeper 分布式锁问题 分布式锁Java实现 附带案例和实现思路代码
Hadoop-32 ZooKeeper 分布式锁问题 分布式锁Java实现 附带案例和实现思路代码
40 2
|
27天前
|
分布式计算 Java Hadoop
Hadoop-30 ZooKeeper集群 JavaAPI 客户端 POM Java操作ZK 监听节点 监听数据变化 创建节点 删除节点
Hadoop-30 ZooKeeper集群 JavaAPI 客户端 POM Java操作ZK 监听节点 监听数据变化 创建节点 删除节点
58 1
|
27天前
|
分布式计算 监控 Hadoop
Hadoop-29 ZooKeeper集群 Watcher机制 工作原理 与 ZK基本命令 测试集群效果 3台公网云服务器
Hadoop-29 ZooKeeper集群 Watcher机制 工作原理 与 ZK基本命令 测试集群效果 3台公网云服务器
35 1
|
27天前
|
分布式计算 Hadoop
Hadoop-27 ZooKeeper集群 集群配置启动 3台云服务器 myid集群 zoo.cfg多节点配置 分布式协调框架 Leader Follower Observer
Hadoop-27 ZooKeeper集群 集群配置启动 3台云服务器 myid集群 zoo.cfg多节点配置 分布式协调框架 Leader Follower Observer
39 1
|
27天前
|
存储 SQL 消息中间件
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
41 0
|
2月前
|
Java
分布式-Zookeeper-分布式锁
分布式-Zookeeper-分布式锁
|
2月前
|
存储 负载均衡 算法
分布式-Zookeeper-Master选举
分布式-Zookeeper-Master选举
|
19天前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?

热门文章

最新文章