Redisson分布式锁

为什么使用分布式锁

        为了保证一个方法在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLcok或synchronized)进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题。

Redis分布式锁演变

redis实现分布式锁，其实就是保住对redis数据只能有一个线程同时进行修改操作。

说一下Redis的两个命令：

setnx key value

  用法如下，如果不存在set成功返回int的1，这个key存在了返回0。 

127.0.0.1:6379> setnx name love
(integer) 1
127.0.0.1:6379> setnx name you
(integer) 0
127.0.0.1:6379> get name
"love"
127.0.0.1:6379> del name
(integer) 1
127.0.0.1:6379> get name
(nil)
127.0.0.1:6379> 

解析：就是客户端线程1进行setnx操作，设置成功返回1，获得1的进行对数据的修改操作，然后删除del，这样就能保住redis数据同时只有一个线程进行修改操作；

问题：setnx成功返回1在接下来的操作中，客户端线程1宕机，那么name的值一直存在，进入死锁状态

setex key seconds value

   用法如下，如果不存在setex成功返回int的1，这个key存在了返回0，并且设置锁时间

情况一，锁自动取消
127.0.0.1:6379> setex name 10 love        
OK
127.0.0.1:6379> get name
"love"
127.0.0.1:6379> get name
"love"
127.0.0.1:6379> get name
(nil)

//情况二，手动取消
127.0.0.1:6379> setex name 10 love
OK
127.0.0.1:6379> get name
"love"
127.0.0.1:6379> del name
(integer) 1
127.0.0.1:6379> get name
(nil)
127.0.0.1:6379> 

在setnx加了一个过期时间，可以手动取消

问题：时间应该设置成多少？

答案：设置成多大，一般都会出现问题，设置大了也影响性能。

举例说明问题：线程A当设置成10秒时，假设 setex与del之间的代码需要15秒才能执行完成，当程序执行到第10秒时，锁自动失效，其他线程（例如线程B获得name锁，同时设置失效时间为10秒），程序执行到15秒时，del删除了线程B的锁，同理可能出现锁一直失效的可能；

 解决方式：给锁设置一个本线程唯一ID，模拟如下，这有本线程能够释放这个锁

下面是spirngboot下自动导入的redis

maven如下：

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>

代码如下：

    @Test
    void contextLoads() {

        String lock = "0001";
        String clientId = UUID.randomUUID().toString();
        stingRedisTemplate.opsForValue().setIfAbsent(lock,clientId,10, TimeUnit.SECONDS);//jedis.setex
        //业务1
        int num = 100+2;
        //业务2
        String flag = "成功了"; 
        if (clientId.equals(stingRedisTemplate.opsForValue().get(lock))){
            stingRedisTemplate.delete(lock);
        }
    }

问题：如果设置时间过短，那么加锁就没有意义，假如设置1秒，程序需要执行100秒，其他线程获取到锁，还是会有线程对数据修改 冲突问题

解决方式：去获取线程是否还在执行，如果还在执行重新设置过期时间；

Redisson实现分布式锁

1、Redisson实现分布式锁原理

2、Redisson实现分布式锁的源码解析

3、Redisson实现分布式锁的项目代码（可以用于实际项目中）

一、高效分布式锁

当我们在设计分布式锁的时候，我们应该考虑分布式锁至少要满足的一些条件，同时考虑如何高效的设计分布式锁，这里我认为以下几点是必须要考虑的。

1、互斥

在分布式高并发的条件下，我们最需要保证，同一时刻只能有一个线程获得锁，这是最基本的一点。

2、防止死锁

在分布式高并发的条件下，比如有个线程获得锁的同时，还没有来得及去释放锁，就因为系统故障或者其它原因使它无法执行释放锁的命令,导致其它线程都无法获得锁，造成死锁。

所以分布式非常有必要设置锁的有效时间，确保系统出现故障后，在一定时间内能够主动去释放锁，避免造成死锁的情况。

3、性能

对于访问量大的共享资源，需要考虑减少锁等待的时间，避免导致大量线程阻塞。

所以在锁的设计时，需要考虑两点。

1、锁的颗粒度要尽量小。比如你要通过锁来减库存，那这个锁的名称你可以设置成是商品的ID,而不是任取名称。这样这个锁只对当前商品有效,锁的颗粒度小。

2、锁的范围尽量要小。比如只要锁2行代码就可以解决问题的，那就不要去锁10行代码了。

4、重入

我们知道ReentrantLock是可重入锁，那它的特点就是：同一个线程可以重复拿到同一个资源的锁。重入锁非常有利于资源的高效利用。关于这点之后会做演示。

针对以上Redisson都能很好的满足，下面就来分析下它。

二、Redisson原理分析

为了更好的理解分布式锁的原理，我这边自己画张图通过这张图来分析。

1、加锁机制

线程去获取锁，获取成功: 执行lua脚本，保存数据到redis数据库。

线程去获取锁，获取失败: 一直通过while循环尝试获取锁，获取成功后，执行lua脚本，保存数据到redis数据库。

紧接着，就会发送一段lua脚本到redis上，那段lua脚本如下所示：

为啥要用lua脚本呢？

因为复杂的业务逻辑，可以通过封装在lua脚本中发送给redis，保证这段复杂业务逻辑执行的原子性。

那么，这段lua脚本是什么意思呢？

KEYS[1]代表的是你加锁的那个key，比如说：

RLock lock = redisson.getLock("myLock");

这里你自己设置了加锁的那个锁key就是“myLock”。

ARGV[1]代表的就是锁key的默认生存时间，默认30秒。

ARGV[2]代表的是加锁的客户端的ID，类似于下面这样：8743c9c0-0795-4907-87fd-6c719a6b4586:1

给大家解释一下，第一段if判断语句，就是用“exists myLock”命令判断一下，如果你要加锁的那个锁key不存在的话，你就进行加锁。

2、watch dog自动延期机制

客户端1加锁的锁key默认生存时间才30秒，如果超过了30秒，客户端1还想一直持有这把锁，怎么办呢？

简单！只要客户端1一旦加锁成功，就会启动一个watch dog看门狗，他是一个后台线程，会每隔10秒检查一下（1/3），如果客户端1还持有锁key，那么就会不断的延长锁key的生存时间。

3、可重入

Redis存储锁的数据类型是 Hash类型     Hash数据类型的key值包含了当前线程信息。

先判断 if判断肯定不成立，“exists myLock”会显示锁key已经存在了。

然后if判断会成立，因为myLock的hash数据结构中包含的那个ID，就是客户端1的那个ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”

此时就会执行可重入加锁的逻辑，他会用：

incrby myLock 

 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1

通过这个命令，对客户端1的加锁次数，累加1。

Redis分布式锁的缺点

Redis分布式锁会有个缺陷，就是在Redis哨兵模式下:

客户端1 对某个master节点写入了redisson锁，此时会异步复制给对应的 slave节点。但是这个过程中一旦发生 master节点宕机，主备切换，slave节点从变为了 master节点。

这时客户端2 来尝试加锁的时候，在新的master节点上也能加锁，此时就会导致多个客户端对同一个分布式锁完成了加锁。

这时系统在业务语义上一定会出现问题，导致各种脏数据的产生。

缺陷在哨兵模式或者主从模式下，如果 master实例宕机的时候，可能导致多个客户端同时完成加锁。

借鉴：

https://www.cnblogs.com/qdhxhz/p/11046905.html

https://www.cnblogs.com/AnXinliang/p/10019389.html

面试官：如何用Redis实现分布式锁？ - 知乎