乐趣区

关于java:Redisson-分布式锁源码-01可重入锁加锁

jiezi

前言

置信小伙伴都是应用分布式服务，那肯定绕不开分布式服务中数据并发更新问题！

单零碎很容易想到 Java 的各种锁，像 synchronize、ReentrantLock 等等等，那分布式系统如何解决？

当然是应用分布式锁。

如果小伙伴不晓得什么是分布式锁，那举荐看看石杉老师的突击课或者在网上搜一搜相干材料。

当应用 Redis 作为分布式锁时，以后应用较多的框架就是 Redisson。

当然 Redisson 也不仅仅只能当做锁来应用，也有很多其余的性能，小伙伴们能够看一看官网文档，本人多入手实际一下。

上面就开始记录 Redisson 的相干笔记！谬误之处，欢送斧正。🙏🏻

环境配置

  • 本地环境搭建的伪集群：

  • redisson 3.15.6

不同版本可能会有所不同，然而核心思想不会产生太大变动，如果变化很大，心愿能够留言。

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.15.6</version>
</dependency>
  • 我的项目筹备

一个简略的 maven 我的项目，只须要一个 Main 办法即可。

可重入锁加锁

在 lock.lock() 断点，作为源码入口。

默认加锁，什么参数也没有传递。然而这里会设置 leaseTime = -1。这个 leaseTime 的含意是 加锁的工夫。

剩下的一路挺进即可。

在调用 tryAcquire 办法之前，多了一个参数 threadId，是以后线程的 id，long 型负数。

异步加锁

间接来到 tryAcquireAsync 异步加锁办法。

后面曾经说了 leaseTime 是 -1，所以这里会走到上面的办法中。

至此几个参数曾经分明：

  1. waitTime：-1；
  2. internalLockLeaseTime：应用默认工夫 30000 毫秒；
  3. TimeUnit.MILLISECONDS：单位毫秒；
  4. threadId：线程 id；
  5. RedisCommands.EVAL_LONG：eval。

Redis eval 命令的相干文档能够浏览：https://redis.io/commands/eval

加锁逻辑

真正的加锁，其实就是这么一段 lua 脚本。

先阐明一下 lua 脚本的参数信息：

  1. KEYS[1]：getRawName()，加锁的 key，比方 anyLock；
  2. ARGV[1]：unit.toMillis(leaseTime)，锁的毫秒工夫，比方 30000；
  3. ARGV[2]：getLockName(threadId)，是 UUID 和线程 id 拼接起来的字符串，比方 931573de-903e-42fd-baa7-428ebb7eda80:1。

因为应用的是 lua 脚本，能够保障这一块 lua 脚本的 原子性。

首次加锁剖析：

  1. exists 命令判断 redis anyLock 是否存在；
  2. 不存在，应用 hincrby 命令，创立 anyLock 数据；
  3. 对 anyLock 设置过期工夫。

加锁后 Redis 内的数据格式是：

对于 Redis 的 Hash 数据结构能够浏览：https://redis.io/topics/data-…

形象一点能够了解为 anyLock 上面挂着一个 K-V 构造的数据：

"anyLock":{"f400aad5-4b1f-4246-a81e-80c2717c3afb:1":"1"}

执行脚本

后续的内容就是进行申请执行 lua 脚本，惟一须要留神的中央就是有个哈希槽路由。

这块代码是在 CommandAsyncService#evalWriteAsync 办法处调用的，是为了获取一个 NodeSource。

当然这个 NodeSource 外面只寄存了一个 slot（哈希槽值）。

这个 slot 值是对加锁的 key 应用 CRC16 算法计算出来的。

// MAX_SLOT 默认 16384
int result = CRC16.crc16(key.getBytes()) % MAX_SLOT;

这块计算一个 slot 到底有什么用呢？

持续追踪！

BaseRedisBatchExecutor#addBatchCommandData 在这里会从 source 外面获取到 solt，而后取得 MasterSlaveEntry。

大略能够了解为这里是获取到这个 Redis key 对应的节点。

可重入

既然是可重入锁，这块是反对可重入的，来看下可重入是如何保障的。

  1. exists 命令判断 redis key field 是否存在；
  2. 存在 则通过 hincrby 命令对 key 的 field 对应 value 自增；
  3. 为以后 redis key 设置过期工夫。

加锁互斥

下面曾经验证了两种状况：

  1. redis key 不存在；
  2. redis key 和 key 的 field 存在。

剩下的状况就是 key 存在的状况下，然而 field 不存在。

要晓得 key 的 field 放的是 UUID:ThreadId，阐明加锁的不是以后线程。这时候间接返回以后锁的剩余时间。

总结

本文次要介绍了 Redisson 可重入锁的加锁、锁重入、锁互斥逻辑。

外围重点在 lua 脚本。 同时须要了解 Redis 的 Hash 数据结构。

同时须要记住，在未指定加锁工夫时，默认应用的是 30s。

最初，一张图介绍本文加锁逻辑。

相干举荐

  • Spring 动静代理时是如何解决循环依赖的？为什么要应用三级缓存？
  • Spring 是如何解决循环依赖的？
  • Spring 自调用事务生效，你是怎么解决的？
退出移动版