基于缓存或zookeeper的分布式锁实现
缓存锁
我们常常将缓存作为分布式锁的解决方案,但是却不能单纯的判断某个 key 是否存在 来作为锁的获得依据,因为无论是 exists 和 get 命名都不是线程安全的,都无法保证只有一个线程可以获得锁,存在线程争抢,可能会有多个线程同时拿到锁的情况(经典的 Redis “读后写”的问题)。
incr 缓存锁
@Component
public class LockClient {
private StringRedisTemplate stringRedisTemplate;
private ValueOperations<String, String> valueOperations;
@Autowired
public void setStringRedisTemplate(StringRedisTemplate stringRedisTemplate) {
this.stringRedisTemplate = stringRedisTemplate;
this.valueOperations = stringRedisTemplate.opsForValue();
}
public void lockIncr() {
Long lockIncr = valueOperations.increment("lockIncr", 1);
// 说明拿到了锁
if (lockIncr == 1) {
// 业务操作
}
}
}
- incr:递增指定键对应的数值,如果不存在 key 对应的值,那么会先将 key 的值设置为 0,然后执行 incr 操作,返回递增的值。
- 这种锁的实现原理主要是利用 incr 命令的原子性,同一时间只会有一个线程操作这个命令。
- 这种锁的实现方式,不在乎结果数据。保证只有唯一线程能够执行到业务代码。
setnx 缓存锁
上面的锁实现方式,我们对资源做了隔离,保证只有唯一线程可以拿到资源并执行操作。但是如果资源并不是唯一线程执行的呢?存在多个线程争抢的情况下呢?
public void lockSetnx() {
String lock = "lockSetnx";
long millis = System.currentTimeMillis();
long timeout = millis + 3000L + 1;
try {
while (true) {
boolean setnx = valueOperations.setIfAbsent(lock, timeout + "");
if (setnx == true) {
break;
}
String oldTimeout = valueOperations.get(lock);
// 这一步是为了解决客户端异常宕机,锁没有被正常释放的时候。
// 当 p1、p2 同时执行到这里,发现锁的时间过期了。p1、p2 同时执行 getSet 命令。
// 假设 p1 先执行成功了,那么 p1 得到的值就是原来锁的过期时间(可以符合下面的判断式),表示争抢锁成功。
// 假设 p2 后执行成功了,那么 p2 得到的值就是 p1 set 进去的值(不会符合下面的表达式),表示争抢锁失败。
String oldValue = valueOperations.getAndSet(lock, timeout + "");
if (millis > Long.valueOf(oldTimeout) && millis > Long.valueOf(oldValue)) {
break;
}
// 休眠 100 毫秒,再去争抢锁
Thread.sleep(100);
}
// 执行业务代码
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
if (millis < timeout) {
stringRedisTemplate.delete(lock);
}
}
}
- setnx:只有第一个线程会执行成功,返回 true,其余线程执行失败,返回 false。
- getSet:返回 key 中的旧值,并把新的值 set 进去。
- 细细看来,好像似乎 setnx 命令就能够实现分布式锁了,为什么还要 getSet 命名呢?getSet 命令是为了解决客户端异常宕机,锁没有被正常释放的情况下,结合过期时间来保证线程安全。可以看看官网的介绍,有详细解释这个问题。
zookeeper 锁
zookeeper,天生的分布式协调工具,生来就是为了解决各种分布式的难题,比如分布式锁、分布式计数器、分布式队列等等。
zookeeper 分布式锁,如果自己实现的话,大抵的实现方式如下:
公平锁:
- 在 zookeeper 的指定节点(locks)下创建临时顺序节点 node_n ;
- 获取 locks 下面的所有子节点 children。
- 对子节点按节点自增序号从小到大排序。
- 判断本节点是不是第一个子节点,如果是,则获取到锁。如果不是,则监听比该节点小的那个节点的删除事件。
- 若监听事件生效,则回到第二步重新判断,直到获取到锁。
不公平锁
- 在 zookeeper 的某个节点(lock)上创建临时节点 znode。
- 创建成功,就表示获取到了这个锁;其他客户端来创建锁会失败,只能注册对这个锁的监听。
- 其他客户端监听到这个锁被释放(znode节点被删除),就会尝试加锁(创建节点),继续执行第二步。
幸运的是,zookeeper recipes 客户端为我们提供了多种分布式锁实现:
- InterProcessMutex(可重入排他锁)
- InterProcessSemaphoreMutex(不可重入排他锁)
- InterProcessReadWriteLock(分布式读写锁)
- InterProcessSemaphore(共享信号量 —— 设置最大并行数量)
zookeeper recipes 锁的简单使用:
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.4.14</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>4.0.1</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>4.0.1</version>
</dependency>
public InterProcessMutex interProcessMutex(String lockPath) {
CuratorFramework client = CuratorFrameworkFactory.newClient(zookeeper, new ExponentialBackoffRetry(1000, 3));
// 启用命名空间,做微服务间隔离
client.usingNamespace(namespace);
client.start();
return new InterProcessMutex(client, lockPath);
}
public void lockUse() {
InterProcessMutex interProcessMutex = interProcessMutex("/lockpath");
try {
// 获取锁
if (interProcessMutex.acquire(100, TimeUnit.MILLISECONDS)) {
// 执行业务代码
}
} catch (Exception e) {
e.printStackTrace();
} finally {
// 释放锁
try {
interProcessMutex.release();
} catch (Exception e) {
e.printStackTrace();
}
}
}
- 推荐一篇 zookeeper 介绍很全面的文章:https://www.cnblogs.com/shamo89/p/9800925.html
比较
- 缓存分布式锁,必须采用轮询的方式去尝试加锁,对性能浪费很大;zookeeper 分布式锁,可以通过监听的方式等待通知或超时,当有锁释放,通知使用者即可。
- 如果缓存获取锁的那个客户端宕机了,锁不会被释放,只能通过其它方式解决(上面的 getSet 判断);而 zookeeper 的话,因为创建的是临时 znode,只要客户端挂了,znode 就没了,此时就自动释放锁。
基于缓存或zookeeper的分布式锁实现的更多相关文章
- 基于 Zookeeper 的分布式锁实现
1. 背景 最近在学习 Zookeeper,在刚开始接触 Zookeeper 的时候,完全不知道 Zookeeper 有什么用.且很多资料都是将 Zookeeper 描述成一个“类 Unix/Linu ...
- 基于Zookeeper的分布式锁
实现分布式锁目前有三种流行方案,分别为基于数据库.Redis.Zookeeper的方案,其中前两种方案网络上有很多资料可以参考,本文不做展开.我们来看下使用Zookeeper如何实现分布式锁. 什么是 ...
- 10分钟看懂!基于Zookeeper的分布式锁
实现分布式锁目前有三种流行方案,分别为基于数据库.Redis.Zookeeper的方案,其中前两种方案网络上有很多资料可以参考,本文不做展开.我们来看下使用Zookeeper如何实现分布式锁. 什么是 ...
- 基于ZooKeeper实现——分布式锁与实现
引言 ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件.它是一个为分布式应用提供一致性服务的软件,提 ...
- 【连载】redis库存操作,分布式锁的四种实现方式[一]--基于zookeeper实现分布式锁
一.背景 在电商系统中,库存的概念一定是有的,例如配一些商品的库存,做商品秒杀活动等,而由于库存操作频繁且要求原子性操作,所以绝大多数电商系统都用Redis来实现库存的加减,最近公司项目做架构升级,以 ...
- 分布式锁(3) ----- 基于zookeeper的分布式锁
分布式锁系列文章 分布式锁(1) ----- 介绍和基于数据库的分布式锁 分布式锁(2) ----- 基于redis的分布式锁 分布式锁(3) ----- 基于zookeeper的分布式锁 代码:ht ...
- 基于Zookeeper的分布式锁(干干干货)
原文地址: https://juejin.im/post/5df883d96fb9a0163514d97f 介绍 为什么使用锁 锁的出现是为了解决资源争用问题,在单进程环境下的资源争夺可以使用 JDK ...
- 基于zookeeper实现分布式锁和基于redis实现分布所的区别
1,实现方式不同 zookeeper实现分布式锁:通过创建一个临时节点,创建的成功节点的服务则抢占到分布式锁,可做业务逻辑.当业务逻辑完成,连接中断,节点消失,继续下一轮的锁的抢占. redis实现分 ...
- java就业指南 zookeeper分布式系统 zookeeper实现分布式锁 有用
目前几乎很多大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题.分布式的CAP理论告诉我们“任何一个 分布式系统都无法同时满足一致性(Consistency).可用性 ...
随机推荐
- .Net中使用数据库(sqlite)的大体流程(简单向)
说来数据库,各种语言各种数据库在操作上大体无异,基本都是连接数据库.操作数据库.关闭数据库连接的流程,不过Sqlite由于是单文件数据库,相比其他服务器的数据库连接更简单,只需要给定数据库文件的路径即 ...
- Win10中解决Prolific PL2303出现错误代码10的问题
PL2303 是Prolific 公司生产的一种高度集成的RS232-USB接口转换器,在Win10中默认安装的驱动程序会出现错误代码10的问题,如下图所示: 下载Win10上可以用的PL2303驱动 ...
- QT 自定义消息(超级简单的一个例子)
#define TEST_EVENT QEvent::User + 100 class CVxActuatorMain : public QMainWindow { protected: ...
- Win10如何关闭自动更新服务
原文:Win10如何关闭自动更新服务 第一步: 小娜搜索"gpedit.msc",进入本地计算机策略设置. 第二步: 找到策略位置:本地计算机策略-计算机配置-管理模板-Windo ...
- Qt for windows消息循环、libqxt分析和wince快捷键处理
Qt for windows消息循环.libqxt分析和wince快捷键处理 利用Qt做windows图形界面开发和MFC相比,个人感觉还是比较简单好用的:首先利用Designer工具搞个ui文件:然 ...
- webform的图片防盗链
最近用到域的问题,不是同一主机的请求将不允许请求此页面. 这其实和图片防盗链的本质是一样的. 通过两个属性:由于当时用的aspx视图引擎,所以需要通过HttpContext.Current才能拿到ht ...
- 可以用GetObjectProp来获取对象的属性
原来可以用GetObjectProp来获取对象的属性,还有这用法,哈哈哈哈…… var SL: TStrings; UseDBTools: Boolean;begin SL := nil; if Me ...
- qt5.7交叉编译gstreamer-1.0
一.交叉编译glib1.提前需先交叉编译libffiCC=/home/mjl/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-gcc ...
- 开源代码分析工具 good
checkstyle - static code analysis tool for JavaPMD - A source code analyzer
- FMXUI中的三大杀器:TView、TLinearLayout、TRelativeLayout
好了,今天我们来介绍下FMXUI中的三大杀器:TView.TLinearLayout.TRelativeLayout. [名词定义] 非布局组件: 组件名不是以Layout结尾的组件,Delphi自带 ...