Redis分布式锁（Redisson）实现原理分析

目录

 

1、Redisson介绍

2、Redisson锁使用示例

3、Redisson锁实现原理

1.加锁

2.锁互斥机制

3.watch dog自动延期机制

4.可重入加锁机制

5.释放锁机制

---

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

---