Redission的简介

Redission 为 Redis 官网分布式解决方案

• 官网： Redisson: Redis Java client with features of In-Memory Data Grid

• 快速入门： https://github.com/redisson/redisson#quick-start

• github的Redission系列：https://github.com/orgs/redisson/repositories

Redission的功能分布

Maven配置

<!--Maven-->
<dependency>
   <groupId>org.redisson</groupId>
   <artifactId>redisson</artifactId>
   <version>3.10.4</version>
</dependency> 

基本使用

// 1. Create config object
Config = ...
// 2. Create Redisson instance
RedissonClient redisson = Redisson.create(config);
// 3. Get Redis based object or service you need
RMap<MyKey, MyValue> map = redisson.getMap("myMap");
RLock lock = redisson.getLock("myLock")
lock.lock();
//业务代码
lock.unlock();

官方源码API

RedissionLock类

RLock红锁类

Redission采用Lua脚本执行枷锁逻辑

Redission是通过lua脚本来访问Redis来确保业务逻辑执行的原子性的。

以下就是Redission中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]);

• KEYS[1]：就代表加的那把锁的key，我只需要判断这个key值是否存在就能知道锁是否被线程持有。

• ARGV[1]：表示锁的有效期，默认30s

• ARGV[2]：表示表示加锁的客户端ID

• 首先先判断这把锁的key值是否存在，如果不存在，那就可以直接加锁。如果已存在，就要判断一下持有锁的线程是不是当前线程。所以用hexist来判断这个hash中是否存在当前线程的ID，如果存在就说持有锁的就是当前线程，则可以再次进入。

• 将value值加1并延长锁的有效时间。如果不是当前线程的ID，那么就会返回剩余的生存时间，当前线程就会进入一个循环，不断的去尝试获取锁。

以下是Redisson释放锁的lua代码

if (redis.call('exists', KEYS[1]) == 0) then
       redis.call('publish', KEYS[2], ARGV[1]);
        return 1; 
        end;
if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then 
     return nil;
     end;
local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); 
if (counter > 0) then
     redis.call('pexpire', KEYS[1], ARGV[2]); 
     return 0; 
else redis.call('del', KEYS[1]); 
     redis.call('publish', KEYS[2], ARGV[1]); 
     return 1;
     end;
return nil;

• key 不存在，说明锁已释放，直接执行 publish 命令发布释放锁消息并返回 1。
• key 存在，但是 field 在 Hash 中不存在，说明自己不是锁持有者，无权释放锁，返回 nil。
• 因为锁可重入，所以释放锁时不能把所有已获取的锁全都释放掉，一次只能释放一把锁，因此执行 hincrby 对锁的值减一。
• 释放一把锁后，如果还有剩余的锁，则刷新锁的失效时间并返回 0；如果刚才释放的已经是最后一把锁，则执行 del 命令删除锁的 key，并发布锁释放消息，返回 1。

分布式锁的基本特点

互斥性

互斥性是所有悲观锁或者同步锁一个非常普遍的特性，它的意思是说在同一时刻，只有一个线程可以获得锁，这是最基本也是最重要的一点。

自动释放锁（防死锁）

在分布式高并发的情况下，假设有一个线程获取了锁，但是因为系统故障或者其他的原因，使它无法去执行释放锁的命令。那么它就会一直持有这一把锁，其他线程就会一直等待，产生死锁。所以我们需要给它设置过期时间，即使发生了这样的情况也能在锁过期后自动释放锁。

高性能

分布式锁的颗粒度要尽量小，比如要锁库存，那么锁的名称就可以是商品ID，而不是任意名称，这样只有在操作这件商品的时候才会加锁，锁的

颗粒度小。

锁的范围要尽量小：比如说我们可以只锁二行代码，那么就不要锁十行。所以在用Redission实现分布式锁的时候，常规加锁要优于自定义注解加锁。因为自定义注解加锁只能加在方法上，锁的颗粒度较大。

可重入

就像ReentrantLock一样，Redission也可以实现这一点，有利于资源的高效利用。

Redission的分布式锁执行流程

• 争抢竞争分布式锁

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

• Watch dog所起到的作用就是当锁的有效时间要到了当业务逻辑却还没有执行完成时，延长锁的有效时间。

• 正常这个Watch dog线程是不启动的，还有就是这个Watch dog启动后对整体性能也会有一定影响，所以不建议开启看门狗。

• 将复杂的业务逻辑封装在lua脚本中发送给redis，且redis是原子性的，这样就保证了这段逻辑的原子性。

Redisson可以实现可重入加锁机制

线程二在已经持有锁的情况下再进去，就不需要改线程ID，只需改一下value值即可。这里有点像偏向锁的加锁过程：当检查锁标志位成功的时候，会通过CAS的操作，将Mark Word中的线程ID改为自己的线程ID，并将偏向锁位置为1。如果下一次还是线程二进入同步区，就不需要执行这一步。

Redission的缺点（引入了红锁）

在Redis哨兵模式下，当线程一给master节点写入redission锁，会异步复制给slave节点。如果此时master节点发生故障宕机，就会发生主备切换，slave节点变成了master节点。此时线程二也可以给新的master节点写入redission锁。这样就会产生在同一时刻能有多个客户端对同一个分布式锁加锁，这样就可能会导致脏数据的产生。

Redission的源码分析介绍

加锁机制

//org.redisson.RedissonLock#tryLockInnerAsync
return this.commandExecutor.evalWriteAsync(this.getName(), LongCodec.INSTANCE, command, 
    "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]);"
Collections.singletonList(this.getName()), new Object[]{this.internalLockLeaseTime, this.getLockName(threadId)});

为何要使用lua语言？

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

lua字段解释：

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

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

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

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

• ARGV[2]代表的是加锁的客户端的ID，类似于下面这样：

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

hset myLock
8743c9c0-0795-4907-87fd-6c719a6b4586:1 1

通过这个命令设置一个hash数据结构，这行命令执行后，会出现一个类似下面的数据结构：

myLock:
 {
        8743c9c0-0795-4907-87fd-6c719a6b4586:1 1
}

接着会执行“pexpire myLock 30000”命令，设置myLock这个锁key的生存时间是30秒(默认)

锁互斥机制

• 那么在这个时候，如果客户端2来尝试加锁，执行了同样的一段lua脚本，会咋样呢？

• 很简单，第一个if判断会执行“exists myLock”，发现myLock这个锁key已经存在了。

• 接着第二个if判断，判断一下，myLock锁key的hash数据结构中，是否包含客户端2的ID，但是明显不是的，因为那里包含的是客户端1的ID。

• 所以，客户端2会获取到pttl myLock返回的一个数字，这个数字代表了myLock这个锁key的剩余生存时间。比如还剩15000毫秒的生存时间。

• 此时客户端2会进入一个while循环，不停的尝试加锁。

watch dog自动延期机制

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

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

可重入加锁机制

如果客户端1都已经持有了这把锁了，结果可重入的加锁会怎么样呢？

RLock lock = redisson.getLock("myLock")
lock.lock();
//业务代码
lock.lock();
//业务代码
lock.unlock();
lock.unlock();

分析上面那段lua脚本。

• 第一个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。

此时myLock数据结构变为下面这样：

myLock:
    {
        8743c9c0-0795-4907-87fd-6c719a6b4586:1 2
    }

释放锁机制

if (redis.call('exists', KEYS[1]) == 0) then
       redis.call('publish', KEYS[2], ARGV[1]);
        return 1; 
        end;
if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then 
     return nil;
     end;
local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); 
if (counter > 0) then
     redis.call('pexpire', KEYS[1], ARGV[2]); 
     return 0; 
else redis.call('del', KEYS[1]); 
     redis.call('publish', KEYS[2], ARGV[1]); 
     return 1;
     end;
return nil;

• 如果执行lock.unlock()，就可以释放分布式锁，此时的业务逻辑也是非常简单的。

• 其实说白了，就是每次都对myLock数据结构中的那个加锁次数减1。

• 如果发现加锁次数是0了，说明这个客户端已经不再持有锁了，此时就会用：

• “del myLock”命令，从redis里删除这个key。

• 然后呢，另外的客户端2就可以尝试完成加锁了。

• 这就是所谓的分布式锁的开源Redisson框架的实现机制。

Redission的优点

支持redis单实例、redis哨兵、redis cluster、redis master-slave等各种部署架构，基于Redis 所以具有Redis 功能使用的封装，功能齐全。许多公司试用后可以用到企业级项目中，社区活跃度高。

Redission的缺点

• 最大的问题，就是如果你对某个redis master实例，写入了myLock这种锁key的value，此时会异步复制给对应的master slave实例。

• 但是这个过程中一旦发生redis master宕机，主备切换，redis slave变为了redis master。

• 接着就会导致，客户端2来尝试加锁的时候，在新的redis master上完成了加锁，而客户端1也以为自己成功加了锁。

• 此时就会导致多个客户端对一个分布式锁完成了加锁。

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

• 所以这个就是redis cluster，或者是redis master-slave架构的主从异步复制导致的redis分布式锁的最大缺陷：在redis master实例宕机的时候，可能导致多个客户端同时完成加锁。

Redission 还支持了RedLock 算法实现，但是目前存在争议，可自行查询及谨慎使用