目录
- 分布式锁
- 一:基本原理和实现方式
- 二:分布式锁的实现
- 1:分布式锁的误删问题
- 2:解决误删问题
- 三:lua脚本解决多条命令原子性问题
- 调用lua脚本
- 四:Redisson
- 1:redisson入门
- 2:redisson可重入锁的原理
- 3:解决尝试等待,超时释放的问题(看门狗)
- 4:主从一致性问题
分布式锁
一:基本原理和实现方式
使用redis实现分布式锁:
我们实现分布式锁有两个基本方法:
一个是获取锁
一个是删除锁
获取我们使用setnx,只有不存在才会set成功作为互斥锁;
删除直接删除这个锁的键就行了;
但是要考虑一种情况,就是获取锁之后服务宕机了,那么就无法释放锁,也就会出现死锁,服务挂了,为了预防这种情况的发生我们要设置过期时间,就算服务宕机,过了过期时间锁也会释放;
还有一种情况就是设置锁,还没去设置锁的过期时间这个时候服务就宕机了,那么也会出现死锁,我们要保证获取锁和设置过期时间这个操作的原子性,redis种就提供了方法可以同时设置过期时间和互斥锁:
set lock t1 nx ex 10
二:分布式锁的实现
我们去实现这个接口:
public class SimpleRedisLock implements ILock{
//锁的名称
private String name;
private StringRedisTemplate stringRedisTemplate;
public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate) {
this.name = name;
this.stringRedisTemplate = stringRedisTemplate;
}
//锁的前缀是个常量
private static final String KEY_VALUE ="lock:";
/**
* 获取锁
* @param timeoutSec
* @return
*/
@Override
public boolean trylock(long timeoutSec) {
//获取当前线程id作为锁的value
long id = Thread.currentThread().getId();
//设值尝试获取锁,true是成功,false是失败
Boolean b = stringRedisTemplate.opsForValue().setIfAbsent
(KEY_VALUE + name, id + "", timeoutSec, TimeUnit.SECONDS);
//因为直接返回b的话jvm会自动装箱拆箱,可能会造成空指针异常,如果b为true返回就是true,如果b为false返回就是false,如果为空返回也是false;
return Boolean.TRUE.equals(b);
}
/**
* 释放锁
*/
@Override
public void unlock() {
stringRedisTemplate.delete(KEY_VALUE + name);
}
}
我们在一人一单的问题使用分布式锁:
Long id = UserHolder.getUser().getId();
SimpleRedisLock simpleRedisLock = new SimpleRedisLock("order" + id, stringRedisTemplate);
boolean trylock = simpleRedisLock.trylock(1200);
if (!trylock){
return Result.fail("一人只能下一单");
}
try {
IVoucherOrderService orderService = (IVoucherOrderService) AopContext.currentProxy();
return orderService.createVoucherOrder(voucherId);
} catch (IllegalStateException e) {
throw new RuntimeException(e);
}finally {
simpleRedisLock.unlock();
}
1:分布式锁的误删问题
存在的问题是这样的:
线程1去获取锁,但是呢,业务阻塞超时了,锁就自动释放了,这个时候线程2来了,因为锁释放了,线程2可以获取到锁,就在这时,线程1阻塞通过了,完成了业务之后就要释放锁了,这个时候释放的锁是线程2的锁,线程2还在执行,这个时候线程3也去获取锁成功了,那么就出现了线程2,3并发执行的情况,造成并发安全问题;
这里的问题是线程释放锁释放的不是自己的锁,所以我们解决办法就是在线程释放的时候判断一下是不是自己的锁,怎么判断呢,我们之前获取锁的时候存入的value是线程的id,这个就是线程的唯一标识,我们只需要判断当前线程id和存入的value是否一致就行;
2:解决误删问题
//锁的前缀是个常量
private static final String KEY_VALUE ="lock:";
//加上线程的前缀,保证不同集群不同线程的id是唯一
public static final String ID_VALUE= UUID.randomUUID().toString(true);
/**
* 获取锁
* @param timeoutSec
* @return
*/
@Override
public boolean trylock(long timeoutSec) {
//获取当前线程id作为锁的value
String id =ID_VALUE+ Thread.currentThread().getId();
//设值尝试获取锁,true是成功,false是失败
Boolean b = stringRedisTemplate.opsForValue().setIfAbsent
(KEY_VALUE + name, id + "", timeoutSec, TimeUnit.SECONDS);
//因为直接返回b的话jvm会自动装箱拆箱,可能会造成空指针异常,如果b为true返回就是true,如果b为false返回就是false,如果为空返回也是false;
return Boolean.TRUE.equals(b);
}
只要在锁获取的时候给线程加上唯一标识就行,我们原来用的是线程id,这样不能保证唯一,因为线程id是在同一个jvm内部是递增的,不同jvm的线程id可能相同,那么就需要加上前缀保证线程标识的唯一性,那么就可以使用uuid来保证每一台jvm的uuid是不同的,标识就是唯一的;
释放锁:
@Override
public void unlock() {
if (stringRedisTemplate.opsForValue().get(KEY_VALUE + name).equals(ID_VALUE+ Thread.currentThread().getId())){
stringRedisTemplate.delete(KEY_VALUE + name);
}
}
判断锁中的val和当前线程的标识是否一致;
这样就解决了误删的问题;
但是还有一个问题:
假设一个线程1获取锁之后执行业务,执行完之后,要释放锁,判断了当前锁是否是自己的(锁的value),在要执行删除操作的时候堵塞了,锁超时释放了,这个时候线程2获取锁,执行业务,就在这时,线程1阻塞结束,执行的代码在释放锁上,因为同一个业务锁的key都是一样的,所以线程一能够把锁释放,这时线程2还没执行结束,线程3来了,就出现了线程安全问题;
所以说我们要将判断锁和释放锁作为一个原子性事件,要么同时发生要么同时失败
这就要用lua了
三:lua脚本解决多条命令原子性问题
--获取当前key
local key =KEY[1]
--获取当前线程标识
local id =ARGV[1]
--获取锁中的标识
local _id=redis.call('get',key)
--判断是否是同一个标识:
if(id==_id) then
return redis.call("del",key)
end
return 0
在idea中我们执行lua
脚本我们可以在resouce中创建一个lua文件:
要安装插件才行:
插件名叫emmylua;
调用lua脚本
//声明一个DefaultRedisScript,原来调取lua脚本
public static final DefaultRedisScript UNLOCK_LUA;
static {
//初始化
UNLOCK_LUA=new DefaultRedisScript<>();
//定位到lua脚本的位置
UNLOCK_LUA.setLocation(new ClassPathResource("unlock.lua"));
//设置lua脚本的返回值
UNLOCK_LUA.setResultType(Long.class);
}
@Override
public void unlock() {
// Collections.singletonList创建单元素的集合
stringRedisTemplate.execute(UNLOCK_LUA,
Collections.singletonList(KEY_VALUE + name),
(ID_VALUE+ Thread.currentThread().getId()));
}
这样将判断标识和释放锁的命令写在lua脚本中,就能够保证命令执行的原子性,就不会出现之前说的误删的情况
我们实现分布式锁的思路:
获取锁:使用setnx,互斥的特性,获取值相当于设置锁,使用uuid保证线程的唯一性;
释放锁:释放之前判断锁释放是当前线程的锁,并且将判断锁和释放锁的命令写在一个lua脚本中保证执行命令的原子性;
四:Redisson
1:redisson入门
步骤1:
引入依赖:
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.33.0</version>
</dependency>
步骤二:
配置客户端:
@Configuration
public class RedissonConfig {
@Bean
public RedissonClient redissonClient(){
Config config = new Config();
config.useSingleServer().setAddress("redis://123.249.86.145:6379").setPassword("12345");
return Redisson.create(config);
}
}
2:redisson可重入锁的原理
可重入锁的逻辑:
获取锁:如果锁不存在就获取锁,然后设置过期时间,如果存在了,就判断锁的线程标识是否是自己,如果是自己,那么就让锁的value加一;
释放锁:释放锁的时候判断锁是否是自己的,如果不是自己的就返回空,如果是自己的就让value-1,然后再判断value是否大于0,如果大于0,就重置锁的时间,等于0就删除锁
3:解决尝试等待,超时释放的问题(看门狗)
redisson内部是如何解决重复尝试的呢?尝试解读一下:首先线程会尝试获取锁,获取锁成功就返回空,获取锁失败就返回ttl,也就是锁的超时释放时间,我们重复尝试肯定是建立在获取锁失败的基础上,当返回的是ttl时,我们会判断当前时间减去我们尝试获取锁的时刻的时间,也就是尝试获取锁使用的时间,是否大于我们设置的等待时间,如果大于我们设置的等待时间,那么就尝试获取锁失败,就返回false,如果还有时间,我们不是直接再去获取锁,而是通过订阅机制,我们等待释放锁的信号,如果等待时间超时就直接返回false,如果没抄时,我们在重新尝试锁,失败在判断是否还有时间然后定义然后重试,就这么循环下去,要么拿到锁,要么超过等待时间获取锁失败;这样就解决我们获取锁失败一次就返回失败,可以一直尝试;
然后再来讲一下超时释放问题,也就是过了设置的超时时间,业务还没执行完,锁就释放了,出现了并发安全问题,怎么解决的呢,我们如果没有设置这个锁的超时释放时间,那么redisson就会自动给我们的超时释放时间设置为-1,这个时候才会开启看门狗机制,具体是什么情况呢,就是内部会开启一个任务,这个任务会一直刷新锁的超时时间,一直无限的刷新,每10秒刷新一次,刷新一次延长30秒,也就会一直存在这个锁,知道完成任务释放锁才会取消这个看门狗任务;
那么释放锁的时候如果释放失败就返回异常,释放成功就要做两件事,一个是发送释放锁的信息给正在订阅尝试获取锁的,还有一件事就是将看门狗任务终止;
4:主从一致性问题
主从一致性问题:在redis集群中有主从关系,一个主节点有多个从节点,当主节点宕机时,会选一个从节点作为主节点;
主节点和从节点为了数据一样会做主从同步操作;有一个问题就是当java应用向主节点发送请求获取锁,获取锁成功了,但是在主从同步还没完成的时候,主节点宕机了,这个时候哨兵就会发现宕机,然后从从节点中选出一个作为主节点,而因为数据未同步,新的主节点中没有锁,也就是锁失效了,那么其他线程发送请求就能获取锁,这就是锁失效的问题
如何解决呢:我们不设置主从关系,只设置节点,每个节点都相当与主节点,而且获取锁的时候,必须要所有的节点都获取锁成功才算获取锁成功,如果有一个节点宕机了,他的从节点成为了新的节点,这个时候有线程来获取锁也是不成功的,因为要在所有节点中获取锁,而其他节点已经持有锁了;这就解决了主从一致性问题;
,获取锁成功了,但是在主从同步还没完成的时候,主节点宕机了,这个时候哨兵就会发现宕机,然后从从节点中选出一个作为主节点,而因为数据未同步,新的主节点中没有锁,也就是锁失效了,那么其他线程发送请求就能获取锁,这就是锁失效的问题
[外链图片转存中…(img-1BgOGPaG-1730426881642)]
如何解决呢:我们不设置主从关系,只设置节点,每个节点都相当与主节点,而且获取锁的时候,必须要所有的节点都获取锁成功才算获取锁成功,如果有一个节点宕机了,他的从节点成为了新的节点,这个时候有线程来获取锁也是不成功的,因为要在所有节点中获取锁,而其他节点已经持有锁了;这就解决了主从一致性问题;