背景
之前说到分布式锁的实现有三种
1、基于数据库实现的分布式锁
2、Redis分布式锁
3、Zookeeper分布式锁
前者redis分布式锁博客已具体介绍,此博客最终决定补齐关于Zookeeper分布式锁的实现原理。
简述
Zoopkeeper,它是一个为分布式的协调服务,基于CP,注重数据的一致性,它内部是一个分层的文件系统目录树结构,规定同一个目录下只能有一个唯一文件名。
简单来说,zookeeper相当于文件系统+监听通知机制。
Zookeeper的四种类型节点
-
PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后,该节点依旧存在 -
PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后,该节点依旧存在,并且Zookeeper给该节点名称进行顺序编号 -
EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后,该节点被删除 -
EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
并且Zookeeper给临时目录节点进行顺序编号
zk的事件监听
客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、被删除、子目录节点增加删除)时,zookeeper会通知客户端。
zookeeper使用watcher机制实现数据的发布订阅功能,该机制在被订阅对象发生变化时会异步通知客户端,因此客户端不必再watcher注册后轮询堵塞,从而减轻客户端压力。
基于ZooKeeper实现分布式锁的步骤如下:
2.基于zookeeper : 使用临时顺序节点+监听实现,线程进来都去创建临时顺序节点,第一个节点的创建线程获取到锁,后面的节点监听自己的上一个节点的删除事件,如果第一个节点被删除,释放锁第二个节点就成为第一个节点,获取到锁。
zookeeper分布式锁
针对zookeeper以上及节点和监听机制的特性,可以使用临时有序节点+监听机制来实现zookeeper分布式锁
实现原理:
1、一把分布式锁通常使用一个Znode节点(以/lock为例)表示,如果锁对应的Znode节点不存在,先创建Znode节点。代表分布式锁。
2,线程1获取锁时,在节点/lock下建一个临时有序子节点,第一个节点是当前序号最小的节点,表示获取到锁。
3、当线程2获取锁时,在节点/lock下创建一个临时有序节点,此时判断当前自己的节点序号是否最小,不是,表示拿不到锁,则需要监听上一个节点。
4、当获取到锁的节点线程1执行业务完毕后,释放锁,即删除该节点,表锁被释放。
5、此时第二个节点监听到第一个节点被删除,成为第一个锁,获取到锁
6、以上以此类推
因此,当线程创建的子节点是当前锁下子节点列表中序号最小的有一个时,表示获取到锁,否则监听上一个锁节点,直接上一个子节点被删除,成为第一个节点时获取到锁
以图为例:
图(1)线程1获取到锁,其他线程排队等待
图(2) 线程1执行完毕,删除当前节点,节点2监听到上一节点被删,获取锁执行
三种分布式锁优缺点
总结
根据应用场景选择
● 基于ZooKeeper的分布式锁,适用于高可靠(高可用)而并发量不是太大的场景。如果实际业务场景,更需要的是保证数据一致性,适用于CP型的zookeeper分布式锁。
● 基于Redis的分布式锁,适用于并发量很大、性能要求很高的。如果实际业务场景,更需要的是保证数据高可用性。适用于AP类型的redis分布式锁。
参考文档:https://blog.csdn.net/weixin_45125989/article/details/130493038
redis分布式锁:https://superteam.blog.csdn.net/article/details/132958060
author:yana