目录
1、Redisson介绍
Redisson是一个在Redis的基础上实现的Java驻内存数据网格(In-Memory Data Grid)。它不仅提供了一系列的分布式的Java常用对象,还提供了许多分布式服务。其中包括(BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, Bloom filter, Remote service, Spring cache, Executor service, Live Object service, Scheduler service) Redisson提供了使用Redis的最简单和最便捷的方法。Redisson的宗旨是促进使用者对Redis的关注分离(Separation of Concern),从而让使用者能够将精力更集中地放在处理业务逻辑上。
2、Redisson锁使用示例
public void testRedissonLock(RedissonClient redisson){
RLock lock = redisson.getLock("redisLock");
try{
// 1. 最常见的使用方法
//lock.lock();
// 2. 支持过期解锁功能,10秒钟以后自动解锁, 无需调用unlock方法手动解锁
//lock.lock(10, TimeUnit.SECONDS);
// 3. 尝试加锁,最多等待3秒,上锁以后10秒自动解锁
boolean flag = lock.tryLock(3, 10, TimeUnit.SECONDS);
if(flag){ //成功
// do something
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
3、Redisson锁实现原理
先通过一张图,来了解下加锁的流程
1.加锁
根据上图来看,客户端要加锁。如果该客户端面对的是一个redis cluster集群,它首先会根据hash节点选择一台机器。
注意,仅仅只是选择一台机器!紧接着,就会发送一段lua脚本到redis上,lua脚本如下所示:
"if (redis.call('exists', KEYS[1]) == 0) then " +
"redis.call('hset', KEYS[1], ARGV[2], 1); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
"redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
"return redis.call('pttl', KEYS[1]);"
为啥要用lua脚本呢?
因为一大坨复杂的业务逻辑,可以通过封装在lua脚本中发送给redis,保证这段复杂业务逻辑执行的原子性。
那么,这段lua脚本是什么意思呢?
给大家解释一下,第一段if判断语句,就是用“exists myLock”命令判断一下,如果要加锁的那个锁key不存在的话,就进行加锁。 如何加锁呢?很简单,用下面的命令:
hset myLock 3d7b5418-a86d-48c5-ae15-7fe13ef0034c:1
接着会执行“pexpire myLock 30000”命令,设置myLock这个锁key的生存时间是30秒。
这样加锁完成了。
几个参数所代表的意思:
KEYS[1]代表的是你加锁的那个key,比如说 RLock lock = redisson.getLock("myLock"),这里你自己设置了加锁的那个锁key就是“myLock”。
ARGV[1]代表的就是锁key的默认生存时间,默认30秒。
ARGV[2]代表的是加锁的客户端的ID,类似于这样: 3d7b5418-a86d-48c5-ae15-7fe13ef0034c:1
2.锁互斥机制
在这个时候,如果客户端2来尝试加锁,执行了同样的一段lua脚本,会咋样呢?
按照脚本流程,第一个if判断会执行“exists myLock”,发现myLock这个锁key已经存在了。
接着第二个if判断,判断一下,myLock锁key的hash数据结构中,是否包含客户端2的ID,但是明显客户端id不一致。
所以,客户端2会获取到pttl myLock返回的一个数字,这个数字代表了myLock这个锁key的剩余生存时间。
比如还剩15000毫秒的生存时间, 此时客户端2会进入一个while循环,不停的尝试加锁。
3.watch dog自动延期机制
客户端加锁的key默认生存时间是30秒,如果超过了30秒,客户端还想一直持有这把锁,怎么办呢?
只要客户端一旦加锁成功,就会启动一个watch dog看门狗,他是一个后台线程,每到过期时间1/3(默认生存时间是30s的话,就是10s)就去重新刷一次,如果客户端还持有锁key,那么就会不断的延长锁key的生存时间,如果key不存在则停止刷新。
4.可重入加锁机制
那如果客户端已经持有了这把锁,结果可重入的加锁会怎么样呢?
比如下面这种代码:
RLock lock = redisson.getLock("myLock");
lock.lock();
//do something
lock.lock();
//do something
lock.unlock();
lock.unlock();
这时我们来分析一下上面那段lua脚本。
第一个if判断肯定不成立,“exists myLock”会显示锁key已经存在了。
第二个if判断会成立,因为myLock的hash数据结构中包含的那个ID,就是客户端那个ID,也就是“3d7b5418-a86d-48c5-ae15-7fe13ef0034c:1” ,此时就会执行可重入加锁的逻辑,他会用: incrby myLock 3d7b5418-a86d-48c5-ae15-7fe13ef0034c:1 1
通过这个命令,对客户端1的加锁次数,累加1。
此时myLock数据结构变为下面这样: 大家看到了吧,那个myLock的hash数据结构中的那个客户端ID,就对应着加锁的次数
5.释放锁机制
如果执行lock.unlock(),就可以释放分布式锁,此时的业务逻辑其实很简单。
就是每次都对myLock数据结构中的那个加锁次数减1。
如果发现加锁次数是0了,说明这个客户端已经不再持有锁了,此时就会用: “del myLock”命令,从redis里删除这个key。
然后呢,另外的客户端就可以尝试完成加锁了。
这就是所谓的分布式锁的开源Redisson框架的实现机制。
参考文章:
https://www.cnblogs.com/AnXinliang/p/10019389.html
https://blog.csdn.net/loushuiyifan/article/details/82497455
https://www.jianshu.com/p/de5a69622e49