Redisson分布式锁入门
文章目录
- 概述
-
- 什么是分布式锁
- 为什么需要分布式锁
- 分布式锁有哪些，对比一下
- Redis 官网对分布式锁的说法
- 一、Redisson 是什么？
- 二、整合 Redisson
-
- 2.1 引入 Maven 依赖
- 2.2 自定义配置类
- 2.3 测试配置类
- 三、分布式可重入锁
-
- 3.1 可重入锁测试
-
- 3.1.1 验证一：可重入锁是阻塞的吗？
- 3.1.2 验证二：服务停了，锁会释放吗？
- 3.1.3 验证二：同一个线程是否多次获得锁?
- 3.2 看门狗原理
- 3.3 设置锁过期时间
- 四、王者方案
- 五、分布式读写锁
- 六、分布式信号量
- 七、公平锁（Fair Lock）
- 八、 联锁（MultiLock）
- 九、 红锁（RedLock）
概述
什么是分布式锁
为什么需要分布式锁
分布式锁有哪些，对比一下
Redis 官网对分布式锁的说法
我们先来看下 Redis 官网对分布式锁的说法：
而 Java 版的 分布式锁的框架就是 Redisson。
推荐大家去看一下人家github的文档，Redisson 官方Github文档
在实战之前，我们先来看下使用 Redisson 的原理。
一、Redisson 是什么？
如果你之前是在用 Redis 的话，那使用 Redisson 的话将会事半功倍，Redisson 提供了使用 Redis的最简单和最便捷的方法。
Redisson的宗旨是促进使用者对 Redis 的关注分离（Separation of Concern），从而让使用者能够将精力更集中地放在处理业务逻辑上。
Redisson 是一个在 Redis 的基础上实现的 Java 驻内存数据网格（In-Memory Data Grid）。
- Netty 框架：Redisson采用了基于NIO的Netty框架，不仅能作为Redis底层驱动客户端，具备提供对Redis各种组态形式的连接功能，对Redis命令能以同步发送、异步形式发送、异步流形式发送或管道形式发送的功能，LUA脚本执行处理，以及处理返回结果的功能
- 基础数据结构：将原生的Redis Hash，List，Set，String，Geo，HyperLogLog等数据结构封装为Java里大家最熟悉的映射（Map），列表（List），集（Set），通用对象桶（Object Bucket），地理空间对象桶（Geospatial Bucket），基数估计算法（HyperLogLog）等结构，
- 分布式数据结构：这基础上还提供了分布式的多值映射（Multimap），本地缓存映射（LocalCachedMap），有序集（SortedSet），计分排序集（ScoredSortedSet），字典排序集（LexSortedSet），列队（Queue），阻塞队列（Blocking Queue），有界阻塞列队（Bounded Blocking Queue），双端队列（Deque），阻塞双端列队（Blocking Deque），阻塞公平列队（Blocking Fair Queue），延迟列队（Delayed Queue），布隆过滤器（Bloom Filter），原子整长形（AtomicLong），原子双精度浮点数（AtomicDouble），BitSet等Redis原本没有的分布式数据结构。
- 分布式锁：Redisson还实现了Redis文档中提到像分布式锁Lock这样的更高阶应用场景。事实上Redisson并没有不止步于此，在分布式锁的基础上还提供了联锁（MultiLock），读写锁（ReadWriteLock），公平锁（Fair Lock），红锁（RedLock），信号量（Semaphore），可过期性信号量（PermitExpirableSemaphore）和闭锁（CountDownLatch）这些实际当中对多线程高并发应用至关重要的基本部件。正是通过实现基于Redis的高阶应用方案，使Redisson成为构建分布式系统的重要工具。
- 节点：Redisson作为独立节点可以用于独立执行其他节点发布到分布式执行服务和分布式调度服务里的远程任务。
二、整合 Redisson
Spring Boot 整合 Redisson 有两种方案：
- 程序化配置。
- 文件方式配置。
本篇介绍如何用程序化的方式整合 Redisson。
2.1 引入 Maven 依赖
在 服务的 pom.xml 引入 redisson的 maven 依赖。
<dependency>
<groupId>org.redissongroupId>
<artifactId>redissonartifactId>
<version>3.15.5version>
dependency>
2.2 自定义配置类
下面的代码是单节点 Redis 的配置。
@Configuration
public class RedissonConfig {
@Value("${spring.redis.host}")
private String redisConnectIp;
@Value("${spring.redis.port}")
private String redisConnectPort;
@Bean
public RedissonClient redissonClient(){
// 配置
Config config = new Config();
//config.useSingleServer().setAddress("redis://"+redisConnectIp+":"+redisConnectPort);
// 集群模式config.useClusterServers().addNodeAddress("127.0.0.1:7004", "127.0.0.1:7001");
// 2.根据 Config 创建出 RedissonClient 示例。
config.useSingleServer().setAddress("redis://127.0.0.1:6379")
// 创建RedissonClient对象
return Redisson.create(config);
}
}
2.3 测试配置类
新建一个单元测试方法。
@Autowired
RedissonClient redissonClient;
@Test
public void TestRedisson() {
System.out.println(redissonClient);
}
我们运行这个测试方法，打印出 redissonClient
org.redisson.Redisson@77f66138
三、分布式可重入锁
3.1 可重入锁测试
基于Redis的Redisson分布式可重入锁RLockJava 对象实现了java.util.concurrent.locks.Lock接口。同时还提供了异步（Async）、反射式（Reactive）和RxJava2标准的接口。
RLock lock = redisson.getLock("anyLock");
// 1. 最常见的使用方法
lock.lock();
// 2. 支持过期解锁功能,10秒钟以后自动解锁, 无需调用unlock方法手动解锁
lock.lock(10, TimeUnit.SECONDS);
// 3. 尝试加锁，最多等待3秒，上锁以后10秒自动解锁
boolean res = lock.tryLock(3, 10, TimeUnit.SECONDS);
我们测试下可重入锁的两个点：
- 多个线程抢占锁，后面锁需要等待吗？
- 如果抢占到锁的线程所在的服务停了，锁会不会被释放？
- 同一个线程是否多次获得锁
3.1.1 验证一：可重入锁是阻塞的吗？
为了验证以上两点，我写了个 demo 程序：代码的流程就是设置WuKong-lock锁，然后加锁，打印线程 ID，等待 10 秒后释放锁，最后返回响应：“test lock ok”。
@ResponseBody
@GetMapping("test-lock")
public String TestLock() {
// 1.获取锁，只要锁的名字一样，获取到的锁就是同一把锁。
RLock lock = redisson.getLock("WuKong-lock");
// 2.加锁
lock.lock();
try {
System.out.println("加锁成功，执行后续代码。线程 ID：" + Thread.currentThread().getId());
Thread.sleep(10000);
} catch (Exception e) {
//TODO
} finally {
lock.unlock();
// 3.解锁
System.out.println("Finally，释放锁成功。线程 ID：" + Thread.currentThread().getId());
}
return "test lock ok";
}
先验证第一个点，用两个 http 请求来测试抢占锁。
请求的 URL：
http://localhost:11000/question/v1/redisson/test/test-lock
第一个线程对应的线程 ID 为 86，10秒后，释放锁。在这期间，第二个线程需要等待锁释放。
第一个线程释放锁之后，第二个线程获取到了锁，10 秒后，释放锁。
画了一个流程图，帮助大家理解。如下图所示：
第一步：线程 A 在 0 秒时，抢占到锁，0.1 秒后，开始执行等待 10 s。
第二步：线程 B 在 0.1 秒尝试抢占锁，未能抢到锁（被 A 抢占了）。
第三步：线程 A 在 10.1 秒后，释放锁。
第四步：线程 B 在 10.1 秒后抢占到锁，然后等待 10 秒后释放锁。
由此可以得出结论，Redisson 的可重入锁（lock）是阻塞其他线程的，需要等待其他线程释放的。
3.1.2 验证二：服务停了，锁会释放吗？
如果线程 A 在等待的过程中，服务突然停了，那么锁会释放吗？如果不释放的话，就会成为死锁，阻塞了其他线程获取锁。
我们先来看下线程 A 的获取锁后的，Redis 客户端查询到的结果，如下图所示：
WuKong-lock 有值，而且大家可以看到 TTL 在不断变小，说明 WuKong-lock 是自带过期时间的。
通过观察，经过 30 秒后，WuKong-lock 过期消失了。说明 Redisson 在停机后，占用的锁会自动释放。
那这又是什么原理呢？这里就要提一个概念了，看门狗。
3.1.3 验证二：同一个线程是否多次获得锁?
我们可以在获取锁的时候，首先判断锁是否已经被占用，如果已经被占用，判断是否是当前线程所占用的，如果是同一个线程占用，也会让其获取到锁，但是会额外增加一个计数器，用于记录重入的次数，即当前线程总共获取了几次锁。当前线程每获取一次锁，计数器便加1，而在释放锁时，每释放一次锁，计数器就会减1，直至计数器为 0 时，将当前锁直接删除。那么现在，我们不仅要在锁中记录获取锁的线程，还要记录当前线程重入次数，即获取了几次锁，显然，String 类型的数据结构并不满足这个业务需求，这里可以使用 Hash 类型进行存储，这样就可以在 key 的位置，记录锁的名称，在 field 的位置记录线程标识，在 value 的位置记录锁重入次数。
3.2 看门狗原理
如果负责储存这个分布式锁的 Redisson 节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期
默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定。
如果我们未制定 lock 的超时时间，就使用 30 秒作为看门狗的默认时间。只要占锁成功，就会启动一个定时任务：每隔 10 秒重新给锁设置过期的时间，过期时间为 30 秒。
如下图所示：
当服务器宕机后，因为锁的有效期是 30 秒，所以会在 30 秒内自动解锁。（30秒等于宕机之前的锁占用时间+后续锁占用的时间）。
如下图所示：
3.3 设置锁过期时间
我们也可以通过给锁设置过期时间，让其自动解锁。
如下所示，设置锁 8 秒后自动过期。
lock.lock(8, TimeUnit.SECONDS);
如果业务执行时间超过 8 秒，手动释放锁将会报错，如下图所示：
所以我们如果设置了锁的自动过期时间，则执行业务的时间一定要小于锁的自动过期时间，否则就会报错。
四、王者方案
上一篇我讲解了分布式锁的几种方案：原理探究：Redis分布式锁保姆级无死角分析，这一篇主要是讲解如何用 Redisson 在 Spring Boot 项目中实现分布式锁的方案。
因为 Redisson 非常强大，实现分布式锁的方案非常简洁，所以称作王者方案。
原理图如下：
代码如下所示：
RLock lock = redisson.getLock("anyLock");
try {
// 1. 最常见的使用方法
// lock.lock();
// 2. 支持过期解锁功能,10秒钟以后自动解锁, 无需调用unlock方法手动解锁
// lock.lock(10, TimeUnit.SECONDS);
// 3. 尝试加锁，最多等待3秒，上锁以后10秒自动解锁
boolean res = lock.tryLock(3, 10, TimeUnit.SECONDS);
if (res) { // 成功
// do your business
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
和之前 Redis 的方案相比，简洁很多。
下面讲解下 Redisson 的其他几种分布式锁，相信大家在以后的项目中也会用到。
五、分布式读写锁
基于 Redis 的 Redisson 分布式可重入读写锁RReadWriteLock Java对象实现了java.util.concurrent.locks.ReadWriteLock接口。其中读锁和写锁都继承了 RLock接口。
写锁是一个排他锁（互斥锁），读锁是一个共享锁。
读锁 + 读锁：相当于没加锁，可以并发读。
读锁 + 写锁：写锁需要等待读锁释放锁。
写锁 + 写锁：互斥，需要等待对方的锁释放。
写锁 + 读锁：读锁需要等待写锁释放。
示例代码如下：
RReadWriteLock rwlock = redisson.getReadWriteLock("anyRWLock");
// 最常见的使用方法
rwlock.readLock().lock();
// 或
rwlock.writeLock().lock();
另外Redisson还通过加锁的方法提供了leaseTime的参数来指定加锁的时间。超过这个时间后锁便自动解开了。
// 10秒钟以后自动解锁
// 无需调用unlock方法手动解锁
rwlock.readLock().lock(10, TimeUnit.SECONDS);
// 或
rwlock.writeLock().lock(10, TimeUnit.SECONDS);
// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = rwlock.readLock().tryLock(100, 10, TimeUnit.SECONDS);
// 或
boolean res = rwlock.writeLock().tryLock(100, 10, TimeUnit.SECONDS);
...
lock.unlock();
六、分布式信号量
基于Redis的Redisson的分布式信号量（Semaphore）Java对象RSemaphore采用了与java.util.concurrent.Semaphore相似的接口和用法。同时还提供了异步（Async）、反射式（Reactive）和RxJava2标准的接口。
关于信号量的使用大家可以想象一下这个场景，有三个停车位，当三个停车位满了后，其他车就不停了。可以把车位比作信号，现在有三个信号，停一次车，用掉一个信号，车离开就是释放一个信号。
我们用 Redisson 来演示上述停车位的场景。
先定义一个占用停车位的方法：
/**
* 停车，占用停车位
* 总共 3 个车位
*/
@ResponseBody
@RequestMapping("park")
public String park() throws InterruptedException {
// 获取信号量（停车场）
RSemaphore park = redisson.getSemaphore("park");
// 获取一个信号（停车位）
park.acquire();
return "OK";
}
再定义一个离开车位的方法：
/**
* 释放车位
* 总共 3 个车位
*/
@ResponseBody
@RequestMapping("leave")
public String leave() throws InterruptedException {
// 获取信号量（停车场）
RSemaphore park = redisson.getSemaphore("park");
// 释放一个信号（停车位）
park.release();
return "OK";
}
为了简便，我用 Redis 客户端添加了一个 key：“park”，值等于 3，代表信号量为 park，总共有三个值。
然后用 postman 发送 park 请求占用一个停车位。
然后在 redis 客户端查看 park 的值，发现已经改为 2 了。继续调用两次，发现 park 的等于 0，当调用第四次的时候，会发现请求一直处于等待中，说明车位不够了。如果想要不阻塞，可以用 tryAcquire 或 tryAcquireAsync。
我们再调用离开车位的方法，park 的值变为了 1，代表车位剩余 1 个。
注意：多次执行释放信号量操作，剩余信号量会一直增加，而不是到 3 后就封顶了。
七、公平锁（Fair Lock）
/**
* 公平锁（Fair Lock）
* Redisson分布式可重入公平锁也是实现了java.util.concurrent.locks.Lock接口的一种RLock对象。
* 在提供了自动过期解锁功能的同时，保证了当多个Redisson客户端线程同时请求加锁时，优先分配给先发出请求的线程。
* @param redisson
*/
public void testFairLock(RedissonClient redisson){
RLock fairLock = redisson.getFairLock("anyLock");
try{
// 最常见的使用方法
fairLock.lock();
// 支持过期解锁功能, 10秒钟以后自动解锁,无需调用unlock方法手动解锁
fairLock.lock(10, TimeUnit.SECONDS);
// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = fairLock.tryLock(100, 10, TimeUnit.SECONDS);
if (res) {
// do your business
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
fairLock.unlock();
}
// Redisson同时还为分布式可重入公平锁提供了异步执行的相关方法：
// RLock fairLock = redisson.getFairLock("anyLock");
// fairLock.lockAsync();
// fairLock.lockAsync(10, TimeUnit.SECONDS);
// Future res = fairLock.tryLockAsync(100, 10, TimeUnit.SECONDS);
}
八、 联锁（MultiLock）
/**
* 联锁（MultiLock）
* Redisson的RedissonMultiLock对象可以将多个RLock对象关联为一个联锁，每个RLock对象实例可以来自于不同的Redisson实例
* @param redisson1
* @param redisson2
* @param redisson3
*/
public void testMultiLock(RedissonClient redisson1,RedissonClient redisson2, RedissonClient redisson3){
RLock lock1 = redisson1.getLock("lock1");
RLock lock2 = redisson2.getLock("lock2");
RLock lock3 = redisson3.getLock("lock3");
RedissonMultiLock lock = new RedissonMultiLock(lock1, lock2, lock3);
try {
// 同时加锁：lock1 lock2 lock3, 所有的锁都上锁成功才算成功。
lock.lock();
// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);
if (res) {
// do your business
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
九、 红锁（RedLock）
/**
* 红锁（RedLock）
* Redisson的RedissonRedLock对象实现了Redlock介绍的加锁算法。该对象也可以用来将多个RLock对象关联为一个红锁，每个RLock对象实例可以来自于不同的Redisson实例
* @param redisson1
* @param redisson2
* @param redisson3
*/
public void testRedLock(RedissonClient redisson1,RedissonClient redisson2, RedissonClient redisson3){
RLock lock1 = redisson1.getLock("lock1");
RLock lock2 = redisson2.getLock("lock2");
RLock lock3 = redisson3.getLock("lock3");
RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3);
try {
// 同时加锁：lock1 lock2 lock3, 红锁在大部分节点上加锁成功就算成功。
lock.lock();
// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);
if (res) {
// do your business
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}