【Redis 技术专题】分析一下 Redission 实现分布式锁的点点滴滴

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 objectConfig = ...// 2. Create Redisson instanceRedissonClient redisson = Redisson.create(config);// 3. Get Redis based object or service you needRMap<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#tryLockInnerAsyncreturn 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 myLock8743c9c0-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 算法实现，但是目前存在争议，可自行查询及谨慎使用