Redis进阶-Redisson分布式锁实现原理及源码解析

​

 

​

前言

1、分布式锁的概念和使用场景

整理了一张redis知识图谱分享给你们：

​

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。

在分布式系统中，经常须要协调他们的动做。若是不一样的系统或是同一个系统的不一样主机之间共享了一个或一组资源，那么访问这些资源的时候，每每须要互斥来防止彼此干扰来保证，这个时候，便须要使用到分布式锁。

2、将redis官网对于分布式锁（红锁）的定义和Redisson实现作归纳性总结

该部分能够先粗略的浏览一下，领略其官方的理论定义，读完后续内容会对该环节有更清晰的理解。

对于Redis分布式锁（红锁）官网定义：

​

中文对如上5点作出解释：

redis红锁算法：

在Redis的分布式环境中，咱们假设有N个Redis master。这些节点彻底互相独立，不存在主从复制或者其余集群协调机制。咱们确保将在N个实例上使用与在Redis单实例下相同方法获取和释放锁。如今咱们假设有5个Redis master节点，同时咱们须要在5台服务器上面运行这些Redis实例，这样保证他们不会同时都宕掉。

为了取到锁，客户端应该执行如下操做:

• 获取当前时间，以毫秒为单位。

• 依次尝试从5个实例，使用相同的key和随机值（Redisson中给出的是UUID + ThreadId）获取锁。当向Redis请求获取锁时，客户端应该设置一个网络链接和响应超时时间（咱们接下来会在加锁的环节屡次提到这个时间），这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为10秒，则超时时间应该在5-50毫秒之间。这样能够避免服务器端Redis已经挂掉的状况下，客户端还在一直等待响应结果。若是服务器端没有在规定时间内响应，客户端应该尽快尝试去另一个Redis实例请求获取锁。

• 客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就获得获取锁使用的时间。当且仅当从大多数（N/2+1，这里是3个节点）的Redis节点都取到锁，而且使用的时间小于锁失效时间时，锁才算获取成功。

• 若是取到了锁，key的真正有效时间等于有效时间减去获取锁所使用的时间（步骤3计算的结果）。

• 若是由于某些缘由，获取锁失败（没有在至少N/2+1个Redis实例取到锁或者取锁时间已经超过了有效时间），客户端应该在全部的Redis实例上进行解锁（即使某些Redis实例根本就没有加锁成功，防止某些节点获取到锁可是客户端没有获得响应而致使接下来的一段时间不能被从新获取锁）。

针对如上几点，redisson的实现：

​

​  

3、基于Redisson的分布式实现方案

在分析Redisson的源码前，先重申一下咱们本文的重点放在分布式锁的加锁、锁重入、未获取到锁的线程继续获取锁、释放锁四个过程！但愿能够对你们有所帮助。

锁重入：咱们假设，一次加锁时间为30秒，固然Redisson默认的也是30秒，可是业务执行时间大于30秒，若是没有锁重入的实现，那么30秒后锁失效，业务逻辑就会陷入没法保证正确性的严重后果中。

第一步：添加依赖 

<dependency>
     <groupId>org.redisson</groupId>
     <artifactId>redisson</artifactId>
     <version>3.12.5</version>
</dependency>

在正式编码前，咱们先看下有关Redisson实现分布式锁的核心类之间的关系，以下图：

​

第二步：正式编码测试代码

@Slf4j
@RunWith(SpringRunner.class)
@SpringBootTest(classes = BootIntegrationComponentApplication.class)
public class ReidsRedLockTest {

    private ExecutorService executorService = Executors.newCachedThreadPool();

    public RedissonRedLock getRedLock(){
        Config config1 = new Config();
        config1.useClusterServers()
                .addNodeAddress("redis://127.0.0.1:9001","redis://127.0.0.1:9002","redis://127.0.0.1:9003"
                        ,"redis://127.0.0.1:9004","redis://127.0.0.1:9005","redis://127.0.0.1:9006")
                .setPassword("123");
        RedissonClient redissonClient1 = Redisson.create(config1);//建立redissonClient对象，设置一系列的redis参数
        RLock rLock1 = redissonClient1.getLock("red_lock");
        //若是有多个redis cluster集群，则参考如上的写法建立对应的RLock对象，并传入下面的RedissonRedLock构造方法中。
        return new RedissonRedLock(rLock1);//获取redisson红锁
    }

    @Test
    public void redisRedLock() throws Exception {
        RedissonRedLock redLock = getRedLock();

        int[] count = {0};
        for (int i = 0; i < 1000; i++) {
            executorService.submit(() -> {
                try {
                    redLock.tryLock(10, TimeUnit.SECONDS);//加锁
                    count[0]++;
                    Thread.sleep(50000L);
                } catch (Exception e) {
                    log.error("添加分布式锁异常：",e);
                } finally {
                    try {
                        redLock.unlock();//释放锁
                    } catch (Exception e) {
                        log.error("解除分布式锁异常：",e);
                    }
                }
            });
        }
        executorService.shutdown();
        executorService.awaitTermination(1, TimeUnit.HOURS);
        log.info("计算后的结果：{}",count[0]);
    }
}

4、加锁过程分析

首先咱们将加锁过程的方法调用栈列出，按照调用步骤分析加锁的源码实现：

​

由上述调用栈能够看到，实现加锁的核心方法是：

​

这是一个调用lua脚本的执行过程，接下来对该方法作详细解释：

​

针对lua脚本中参数占位符的问题：

•  KEYS[1] = getName()，
• ARGV[1] = internalLockLeaseTime 
• ARGV[2] = getLockName(threadId)

针对getLockName(threadId)方法，在建立redis链接管理器时，设置了id = UUID，具体以下

​

  咱们假设线程A，执行完上面的lua脚本，而且持有了该分布式锁，接下来针对线程A来讲，直到业务逻辑结束，释放锁以前，该线程A，都将进入锁重入的环节，一直持续到业务逻辑执行完成，线程主动释放锁。而没有持有锁的线程，则进入争抢锁的过程，一直到持有锁（至因而公平竞争仍是非公平竞争，咱们先留一个悬念，欢迎各位看官老爷在评论区留言讨论）。

5、锁重入过程分析

再让咱们回到加锁过程当中方法调用栈的图片上，咱们能够看到方法：

​

上图中的红框便是锁重入的实现方法，详细解释以下：

​

一样是利用lua脚本实现，

​

具体逻辑为：

• 咱们假设线程A持有了该锁，则后台线程会在该锁持续了初始失效时间除3取整数的时间节点，作锁重入的操做。
• if判断指定的key是否存在，且是否为当前线程所持有
• 若是被当前线程持有，则将失效时间重置为初始失效时间，redisson默认为30秒。
• 若是上面两步操做成功，则返回1，也便是true；不然返回false。

6、未获取到锁的线程继续获取锁

让咱们将思路继续回到线程A获取锁的逻辑中，咱们经过加锁方法调用栈能够看到方法：

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException 
复制代码

该方法实属有些长，咱们就分段截取分析。

​ ​

经过上图的分析，咱们知道，若是一个线程初次没有获取到锁，则会一直尝试获取锁，直到咱们设置的针对获取该redis实例锁的超时时间耗尽才罢休，在这个过程当中没有获取到锁，则认为在该redis实例获取锁失败。

7、锁释放过程分析

咱们仍是先将锁释放过程方法调用栈列出：

​ ​

经过上图能够看到，在锁释放的过程当中，最核心的方法就是：

​

分析其lua脚本实现逻辑：

​

分析可知，在删除对应的key以后，会发布一条消息以供其余未获取到锁的线程订阅，此逻辑和加锁过程遥相呼应，而且在删除key以后作了移除锁重入资格的操做，以保证当前线程完全释放锁。

8、易混淆概念

咱们所说的一个redis实例，并非一个Redis集群中的某一个master节点或者Slave节点，针对redis集群，一个集群在redLock算法中只是一个实例节点，至于咱们的key值放在了哪一个slot，是由Redis集群的一致性算法决定的。一样对于哨兵模式也是这样。因此针对RedLock算法来讲，若是有N个实例，则是指N个cluster集群、N个sentinel集群、N个redis单实例节点。而不是一个集群中的N个实例。

 

​