分布式锁双重防死锁演进

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
我们设置的分布式锁,value是一个时间戳,但是并没有利用起来,但是V3要利用起来了,先把分布式锁的超时时间拿过来
/**
* 防死锁之分布式锁
* @throws InterruptedException
*/
//
@Scheduled(cron="0 */1 * * * ?")//每1分钟(每个1分钟的整数倍)
public void closeOrderTaskV3() throws InterruptedException {
//防死锁分布式锁
long lockTimeout = Long.parseLong(PropertiesUtil.getProperty("lock.timeout","50000"));
//锁50秒有效期
//项目由于历史数据关单订单比较多,需要处理,初次用50s时间,后续改成5s即可.
同时50s也为了讲课debug的时候时间长而设置。
//大家可以根据实际情况，如果历史订单都处理完毕，或者在外部进行洗数据ok，
这里的lock的时间应该设置小一些，例如1s 2s 3s 4s 5s就足够啦。
//这个时间如何用呢，看下面。和时间戳结合起来用。
Long setnxResult = RedisShardedPoolUtil.setnx(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK,
String.valueOf(System.currentTimeMillis()+lockTimeout));
if(setnxResult != null && setnxResult.intValue() == 1){
//如果返回值是1，代表设置成功，获取锁
closeOrder(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}else{
//如果setnxResult==null 或 setnxResult.intValue() ==0 即 != 1的时候
//未获取到锁，继续判断,判断时间戳,看是否可以重置获取到锁
String lockValueStr = RedisShardedPoolUtil.get(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
//如果lockValue不是空,并且当前时间大于锁的有效期,说明之前的lock的时间已超时,执行getset命令.
if(lockValueStr != null && System.currentTimeMillis() > Long.parseLong(lockValueStr)){
String getSetResult = RedisShardedPoolUtil
.getSet(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK,
String.valueOf(System.currentTimeMillis()+lockTimeout));
//再次用当前时间戳getset，
//返回给定 key 的旧值。
->旧值判断，是否可以获取锁
// 当 key 没有旧值时，即 key 不存在时，返回 nil 。 ->获取锁
//这里我们set了一个新的value值，获取旧的值。
if(getSetResult == null ||
(getSetResult !=null &&
StringUtils.equals(lockValueStr,getSetResult))){
//获取到锁
closeOrder(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}else{
log.info("没有获得分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}
}else{
log.info("没有获得分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}
}
}
然后同样的会调用setnx来设置这个分布式锁,他的value也是当前的时间,加上分布式锁的一个超时时间,如果成功,
那就关闭这个订单,主要看一下else,else代表没有获得分布式锁,也就是说这个值是存在的,然后才会走到else里边,
未获得到锁,继续判断,判断时间戳,看是否重置并获取到锁,这里就要把这个value用上了,首先我们拿到锁的value值,
这里面就要做一个判断了,如果里面的value不等于空,也就是最开始设置一个分布式锁,而这个锁的时间是5秒,也就是当前的
时间加上lockTimeOut,走到了这里,未获取到锁,我们再把这个锁的value拿出来,如果他不等于空,并且当前的时间已经大于
设置锁的时候设置的vaule值,那其实就可以代表这个锁是失效的了,我们认为这个value值这个时间,当前时间加上lockTimeout,
如果超过这个时间,其实我是有权利,即使我这个锁还没有设置,他的有效期,即使你这个key是永久的,ttl返回-1的话,
我们再重新set一个值,因为走到if里面,我可以来获取锁,那如果我满足获取锁的条件,我要重新设置这个锁,那再重新设置锁,
我还要把旧的值返回回来,所以我们要到Util里面封装一个方法,getset,
public static String getSet(String key,String value) {
ShardedJedis jedis = null;
String result = null;
try {
jedis = RedisShardedPool.getJedis();
result = jedis.getSet(key,value);
} catch (Exception e) {
log.error("getset key:{} error", key, e);
RedisShardedPool.returnBrokenResource(jedis);
return result;
}
RedisShardedPool.returnResource(jedis);
return result;
}
getset就是说,我设置一个新值,但是我要立刻拿到返回值,而不是我先get一个值,getset是具有原子性的,也就是说我在
set的同时,把旧的值返回回来,如果我们get再set是不具有原子性的,getset方法我们封装好了,这里是在set一个新值的
时候返回一个旧值,也就是我们执行完这条命令,分布式锁的时间会被重置,以现在的时间加上locktimeout,来重置这个value,
同时把旧的值,是因为我们是tomcat集群,另外一个应用这个值已经被改变了,所以我们不能用这个值来做判断了,我们要拿到
最新的一个旧值是多少,如果我们是一个tomcat,getSetResult和lockTimeout这个值是相等,但是我们是多个tomcat,是有可能
不想等的,因为有多个进程在执行这个任务,getset返回值是这样的,当key没有旧值时,即key不存在的时候,返回nil,这个是
官方的文档,nil在JAVA Jedis就是一个null,获取锁,目的都是为了获取锁,那也就是说,我在getset的时候,我set了一个新值,
但是我发现并没有拿到老的值,代表这个锁在redis里面已经不存在了,所以我就可以直接获取锁直接操作了,我们set了一个新的
value值,获取旧的值,如果getset的结果是一个空,这个值set了,get的时候那不到,在set之前这个锁已经消失了,消失了返回的
就是null,这种情况下我们会获取锁,哪还有一种情况是什么呢,StringUtils.equals(lockValueStr,getSetResult)),
如果他两个相等,就代表着,代码执行到这里,这个值没有被其他的进程set,代表我拿到的锁是安全的,
并且我也有权利去获取这个锁,首先我在这一行重新拿了这个值,然后在if里面判断了一下,
当前的时间已经超过原来设置的时间,再加上锁的超时时间,那进入if的就代表,
我可以有获取锁的权利,那然后我再set一个值,但是我要拿到旧的值,如果他们相同,就代表真正获取到锁,那在这里的时候就可以
真正执行,如果里面的value拿到之后,和现在的时间对比,发现并没有大于之前设置的分布式锁的value,那就代表着老的锁并没有失效,
是还在使用的,都是没有获取到分布式锁,回想我们之前讲的分布式锁的原理的时候,我们有一个流程图,我们一起来回想一下,
这样理解的就更深入,刚刚V2锁的缺陷已经说了,我们把同样的场景放在V3说一下,假设这个锁一直设置在这里边,没有被
expire,这个锁就一直存在reids当中了,那么下次我们进入task的时候,因为getnx会失败,这个时候我们把里面的value值拿出来了,
因为之前的locktimeout是50秒,假设现在已经过了一分钟,也就是说过了60秒,他肯定是不等于空的,因为这个锁存在才会走到else
里边,并且现在的时间,老的锁是锁了50秒,而现在刚好过了60秒,超过50秒了,所以当前的时间会大于锁的一个value,然后getset,
既然我要重新获取锁,我要使用之前,我就把他的时间重置,把它的value重置,所以我把他的value重置成新的时间,之前拿了一个旧值,
现在又拿了一个旧值,这个旧值又不等于空,如果旧值等于空,就代表我们在走if的时候,另外一个进程已经把这个锁删除了,
所以我拿不到老值,也没有关系,所以等于空的时候也会进来,接着说不等于空,不等于空接着走,不等于空的时候,和之前的
老的值,是否是一样呢,如果一样就代表着,我们这个锁并没有被其他进程获取到,代表着我可以用它了,在这里才是真正获取到锁,
我就开始执行closeOrder,else肯定是没有获取到锁,这个else也很好理解,我们这个锁是50秒,关闭了,重启好了,所以当前的时间并
不会大于这个,因为当前的时间并不会大于这个,并没有获取锁的一个权力,那其实在这个过程中,有可能会浪费一些时间,
所以说了,我们的locktimeout,不易设置过长,比如呢,现在是50秒,后续我们会把配置文件改成5秒,那我们现在就改一下吧,
把这个锁配置改成5秒,也就是说我这个timeout只用5秒,其实在expire的时候只用5秒就OK了,那如果5秒你的锁还没有执行
完你的任务的话,那我们可以把这个5秒的时间调大一些,避免了分布式锁出现问题的时候,占用的时间太长,那现在这种情况呢,
就不会发生死锁问题了,在closeOrder里面有一个expire,同时即使expire没有执行过,我们也会通过里面的value值,
进行一个判断,同时使用两个关键的方法,getset,和setnx,那分布式锁也是分布式项目的一个重点,希望可以把这个流程写下来,
可以独自把这个流程图画出来,这样对你的理解是非常有好处的,我们这个定时任务每次,只有一个来执行,并且分布式锁
是所有TOMCAT集群中的各个引用共享的,他们之间来竞争这个分布式锁,来保证我们这个定时任务,每次只有一个服务来
进行,这个非常重要,因为我们在写代码的时候,不可能说,我写了一个项目,当然Spring Schedule也可以放到xml里面来
配置