上一篇演示了基于Redis的Redisson分布式锁实现,那今天我要再来说说基于Zookeeper的分布式现实。
Zookeeper分布式锁实现
要用Zookeeper实现分布式锁,我就不得不说说zookeeper的数据存储。首先zookeeper的核心保存结构是一个DataTree数据结构,其实内部是一个Map<String, DataNode> nodes的数据结构,其中key是path,DataNode才是真正保存数据的核心数据结构,DataNode核心字段包括byte data[]用于保存节点内容。
一,Zookeeper的节点
节点是zookeeper(zk)中数据存储的基础结构,zk中万物皆节点,就好比Java中万物皆对象一样。zk的数据模型就是基于节点的树形结构,但zk规定每个节点的引用规则是路径引用。每个节点中包含子节点引用、存储数据、访问权限以及节点元数据等四部分。
zookeeper中提供了节点类型主要有。
二,Zookeeper分布式锁实现
Zookeeper实现分布式锁的流程,假设锁空间的根节点为/zklock:
1,客户端连接zookeeper,并在/zklock下创建临时的且有序的子节点。
第一个客户端对应的子节点为:/zklock/test_lock_0000000000,第二个为:/zklock/test_lock_0000000001。以此类推。
2,客户端获取/zklock下的子节点列表,判断自己创建的子节点是否为当前子节点列表中序号最小的子节点,如果是则认为获得锁,否则监听/zklock的子节点变更消息,获得子节点变更通知后重复此步骤直至获得锁;
3,执行业务代码。
4,完成业务流程后,删除对应的子节点并释放锁。
实现代码
加锁实现:
阻塞等待上一个锁释放
释放锁
测试:
启动了5个线程来进行验证,输出结果如下。
注意:子节点的创建顺序一定是从小到大的,但是控制台输出结果中显示创建顺序是随机的,是由于创建节点和输出语句不是原子操作导致的。重点是锁的获取和释放,从输出结果中可以看出,每个线程只有在上一个节点被删除后才能执行,一个基于zk的简单的分布式锁就实现了。
三,Curator分布式锁实现
Zookeeper已经红火了这么多年,实际上基于zk的分布式锁目前已经有现成的实现框架,Curator就是Netflix开源的一套ZooKeeper客户端框架,它提供了zk场景的绝大部分实现,使用Curator就不必关心其内部算法,Curator提供了来实现分布式锁,用方法获取锁,以及用方法释放锁,同其他锁一样,方法需要放在finakky代码块中,确保锁能正确释放
Curator提供了四种分布式锁,分别是:
首先在pom里依赖引入
properties配置
配置中心
Controller里写测试接口。
分布式锁实现总结
前面讲了基于Redis的分布式锁实现,为什么这篇文章又要说基于Zookeeper的分布式锁现实呢?让我们先看看Redis和Zookeeper实现分布式锁的区别吧。
区别:
对比总结:Zookeeper分布式锁可靠性比redis强,但由于需要创建节点删除节点,所有效率相比Redis要低。那我在实际项目中我们如何选用呢?原则上如果并发量不是特别大,追求可靠性,那么首选zookeeper。而redis实现的分布式锁响应更快,对并发的支持性能更好,如果为了效率,首选redis实现。
推荐阅读:
SpringBoot电商项目实战 — Redis实现分布式锁
下期文章:分布式锁的Zookeeper实现方式,及微服务开发下的任务调度,事务处理更多相关内容。