分布式锁的基本原理和实现方式对比
分布式锁：满足分布式系统或集群模式下多进程可见并且互斥的锁。
分布式锁的核心思想就是让大家都使用同一把锁，只要大家使用的是同一把锁，那么我们就能锁住线程，不让线程进行，让程序串行执行，这就是分布式锁的核心思路
在分布式情况下有多个JVM，所以就有多个锁监视器，所以就存在有多个线程拿到锁，他们就会产生不互斥的情况，这也是我们为什么要使用分布式锁的原因。而从图中我们也可以看到分布式锁的原理：让多个微服务共用一个锁监视器，这样就不会有多把锁同时存在的情况。
那么分布式锁他应该满足一些什么样的条件呢？
可见性：多个线程都能看到相同的结果，注意：这个地方说的可见性并不是并发编程中指的内存可见性，只是说多个进程之间都能感知到变化的意思
互斥：互斥是分布式锁的最基本的条件，使得程序串行执行
高可用：程序不易崩溃，时时刻刻都保证较高的可用性
高性能：由于加锁本身就让性能降低，所有对于分布式锁本身需要他就较高的加锁性能和释放锁性能
安全性：安全也是程序中必不可少的一环
常见的分布式锁有三种
Mysql：mysql本身就带有锁机制，但是由于mysql性能本身一般，所以采用分布式锁的情况下，其实使用mysql作为分布式锁比较少见
Redis：redis作为分布式锁是非常常见的一种使用方式，现在企业级开发中基本都使用redis或者zookeeper作为分布式锁，利用setnx这个方法，如果插入key成功，则表示获得到了锁，如果有人插入成功，其他人插入失败则表示无法获得到锁，利用这套逻辑来实现分布式锁
Zookeeper：zookeeper也是企业级开发中较好的一个实现分布式锁的方案
Redis分布式锁的实现核心思路
实现分布式锁时需要实现的两个基本方法：
获取锁：
互斥：确保只能有一个线程获取锁
非阻塞：尝试一次，成功返回true，失败返回false
我们在获取锁的时候一开始的思路如下：
但是有一种可能就是当我们执行完第一个命令添加完锁之后，此时宕机了，那么后面给锁添加过期时间的命令还没来得及执行，这时候就会出现死锁的现象。为了让这两个命令达到同时成功或者失败的效果，我们可以把两个命令进行合并。
释放锁：
手动释放
超时释放：获取锁时添加一个超时时间
核心思路：
我们利用redis 的setNx 方法，当有多个线程进入时，我们就利用该方法，第一个线程进入时，redis 中就有这个key 了，返回了1，如果结果是1，则表示他抢到了锁，那么他去执行业务，然后再删除锁，退出锁逻辑，没有抢到锁的哥们，等待一定时间后重试即可
分布式锁的初级实现
锁的基本接口
接下来我们实现这一个接口：
public class SimpleRedisLock implements ILock {
private StringRedisTemplate redisTemplate;
//定义一个锁的通用前缀
private static final String KEY_PREFIX="lock:";
//这个锁可能会被多个业务使用，所以需要使用者提供业务名称来完成key的组建
private String name;
public SimpleRedisLock(StringRedisTemplate redisTemplate, String name) {
this.redisTemplate = redisTemplate;
this.name = name;
}
@Override
public Boolean tryLock(long time) {
//我们的锁里面要记载当前的线程id
long id = Thread.currentThread().getId();
Boolean success = redisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, id + "", time, TimeUnit.SECONDS);
//为了防止拆包的时候出现空指针异常我们使用如下方法
return Boolean.TRUE.equals(success);
}
@Override
public void unlock() {
redisTemplate.delete(KEY_PREFIX + name);
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
注意点：
这个锁可能会被多个业务使用，所以需要使用者提供业务名称来完成key的组建
我们的锁里面要记载当前的线程id，为我们后面处理Redis分布式锁误删的问题作准备
为了防止拆包的时候出现空指针异常我们使用Boolean.TRUE.equals(success);
修改业务代码
@Override
public Result seckillVoucher(Long voucherId) {
// 1.查询优惠券
SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
// 2.判断秒杀是否开始
if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
// 尚未开始
return Result.fail("秒杀尚未开始！");
}
// 3.判断秒杀是否已经结束
if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
// 尚未开始
return Result.fail("秒杀已经结束！");
}
// 4.判断库存是否充足
if (voucher.getStock() < 1) {
// 库存不足
return Result.fail("库存不足！");
}
Long userId = UserHolder.getUser().getId();
//创建锁对象(新增代码)
SimpleRedisLock lock = new SimpleRedisLock("order:" + userId, stringRedisTemplate);
//获取锁对象
boolean isLock = lock.tryLock(1200);
//加锁失败
if (!isLock) {
return Result.fail("不允许重复下单");
}
try {
//获取代理对象(事务)
IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
return proxy.createVoucherOrder(voucherId);
} finally {
//释放锁
lock.unlock();
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
前情回顾：我们设计这个分布式锁的初衷就是解决一人一单问题。当一位用户在同一时间使用高并发的方式去抢优惠卷的时候，因为负载均衡的原因他发出的请求可能会被几个不同的服务器处理，这个时候我们使用java中常规的锁是不起作用的，所以我们需要一个分布式锁。
而这个分布式锁的作用就是保证在高并发的情况下只有一个线程抢到了票，其他线程均会失败，随后释放锁。之后如果该用户还想用这种方法抢优惠卷的话因为数据库已经记录了它的优惠卷，所以他不会成功。
Redis分布式锁误删情况说明
逻辑说明：
持有锁的线程在锁的内部出现了阻塞，导致他的锁自动释放，这时其他线程，线程2来尝试获得锁，就拿到了这把锁，然后线程2在持有锁执行过程中，线程1反应过来，继续执行，而线程1执行过程中，走到了删除锁逻辑，此时就会把本应该属于线程2的锁进行删除，这就是误删别人锁的情况说明
有人可能会认为我们存在redis中的key不是包含用户的id吗，怎么会存在误删别人锁的情况呢？
其实我们可以想象一种情况：一位用户进行优惠卷秒杀的时候，第一次领取优惠卷发生了阻塞，过了一会用户可能会觉得我明明领取了怎么还没有反应，于是可能又会去点击领取优惠卷。这个时候用户id是一样的，那么锁误删的情况就不可避免。
解决方案：解决方案就是在每个线程释放锁的时候，去判断一下当前这把锁是否属于自己，如果属于自己，则不进行锁的删除，假设还是上边的情况，线程1卡顿，锁自动释放，线程2进入到锁的内部执行逻辑，此时线程1反应过来，然后删除锁，但是线程1，一看当前这把锁不是属于自己，于是不进行删除锁逻辑，当线程2走到删除锁逻辑时，如果没有卡过自动释放锁的时间点，则判断当前这把锁是属于自己的，于是删除这把锁。
解决Redis分布式锁误删问题
需求：修改之前的分布式锁实现，满足：在获取锁时存入线程标示（可以用UUID表示）
这里不直接使用线程ID而使用UUID是因为，线程ID是一个递增的数字，在JVM中每创建一个线程，这个数字都会递增。而如果是在集群的模式下(也就是说项目使用集群部署)，就会有多个JVM，而每个JVM都会维护这样一个线程ID，所以非常容易出现线程ID相同的情况，不利于我们后面的判断。
在释放锁时先获取锁中的线程标示，判断是否与当前线程标示一致
如果一致则释放锁
如果不一致则不释放锁
核心逻辑：在存入锁时，放入自己线程的标识，在删除锁时，判断当前这把锁的标识是不是自己存入的，如果是，则进行删除，如果不是，则不进行删除。
具体代码如下：加锁
private static final String ID_PREFIX = UUID.randomUUID().toString(true) + "-";
@Override
public boolean tryLock(long timeoutSec) {
// 获取线程标示
String threadId = ID_PREFIX + Thread.currentThread().getId();
// 获取锁
Boolean success = stringRedisTemplate.opsForValue()
.setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
return Boolean.TRUE.equals(success);
}
1
2
3
4
5
6
7
8
9
10
释放锁
public void unlock() {
// 获取线程标示
String threadId = ID_PREFIX + Thread.currentThread().getId();
// 获取锁中的标示
String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
// 判断标示是否一致
if(threadId.equals(id)) {
// 释放锁
stringRedisTemplate.delete(KEY_PREFIX + name);
}
}
1
2
3
4
5
6
7
8
9
10
11
有关代码实操说明：
在我们修改完此处代码后，我们重启工程，然后启动两个线程，第一个线程持有锁后，手动释放锁，第二个线程 此时进入到锁内部，再放行第一个线程，此时第一个线程由于锁的value值并非是自己，所以不能释放锁，也就无法删除别人的锁，此时第二个线程能够正确释放锁，通过这个案例初步说明我们解决了锁误删的问题。
分布式锁的原子性问题
更为极端的误删逻辑说明：
线程1现在持有锁之后，在执行业务逻辑过程中，他正准备删除锁，而且已经走到了条件判断的过程中，比如他已经拿到了当前这把锁确实是属于他自己的，正准备删除锁，但是此时他的锁到期了，那么此时线程2进来，但是线程1他会接着往后执行，当他卡顿结束后，他直接就会执行删除锁那行代码，相当于条件判断并没有起到作用，这就是删锁时的原子性问题，之所以有这个问题，是因为线程1的拿锁，比锁，删锁，实际上并不是原子性的，我们要防止刚才的情况发生，
Lua脚本解决多条命令原子性问题
Redis提供了Lua脚本功能，在一个脚本中编写多条Redis命令，确保多条命令执行时的原子性。
Lua是一种编程语言，它的基本语法大家可以参考网站：https://www.runoob.com/lua/lua-tutorial.html
这里重点介绍Redis提供的调用函数，我们可以使用lua去操作redis，又能保证他的原子性，这样就可以实现拿锁、比锁、删锁是一个原子性动作了，作为Java程序员这一块并不作一个简单要求，并不需要大家过于精通，只需要知道他有什么作用即可。
这里重点介绍Redis提供的调用函数，语法如下：
redis.call('命令名称', 'key', '其它参数', ...)
1
例如，我们要执行set name jack，则脚本是这样：
执行 set name jack
redis.call('set', 'name', 'jack')
1
2
例如，我们要先执行set name Rose，再执行get name，则脚本如下：
先执行 set name jack
redis.call('set', 'name', 'Rose')
再执行 get name
local name = redis.call('get', 'name')
返回
return name
1
2
3
4
5
6
写好脚本以后，需要用Redis命令来调用脚本，调用脚本的常见命令如下：
例如，我们要执行 redis.call(‘set’, ‘name’, ‘jack’) 这个脚本，语法如下：
如果脚本中的key、value不想写死，可以作为参数传递。key类型参数会放入KEYS数组，其它参数会放入ARGV数组，在脚本中可以从KEYS和ARGV数组获取这些参数：
接下来我们来回一下我们释放锁的逻辑：
释放锁的业务流程是这样的
1、获取锁中的线程标示
2、判断是否与指定的标示（当前线程标示）一致
3、如果一致则释放锁（删除）
4、如果不一致则什么都不做
如果用Lua脚本来表示则是这样的：
最终我们操作redis的拿锁比锁删锁的lua脚本就会变成这样
-- 这里的 KEYS[1] 就是锁的key，这里的ARGV[1] 就是当前线程标示
-- 获取锁中的标示，判断是否与当前线程标示一致
if (redis.call('GET', KEYS[1]) == ARGV[1]) then
-- 一致，则删除锁
return redis.call('DEL', KEYS[1])
end
-- 不一致，则直接返回
return 0
1
2
3
4
5
6
7
8
利用Java代码调用Lua脚本改造分布式锁
lua脚本本身并不需要大家花费太多时间去研究，只需要知道如何调用，大致是什么意思即可，所以在笔记中并不会详细的去解释这些lua表达式的含义。
我们的RedisTemplate中，可以利用execute方法去执行lua脚本，参数对应关系就如下图股
Java代码
private static final DefaultRedisScript UNLOCK_SCRIPT;
static {
UNLOCK_SCRIPT = new DefaultRedisScript<>();
UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua"));
UNLOCK_SCRIPT.setResultType(Long.class);
}
public void unlock() {
// 调用lua脚本
stringRedisTemplate.execute(
UNLOCK_SCRIPT,
Collections.singletonList(KEY_PREFIX + name),
ID_PREFIX + Thread.currentThread().getId());
}
//经过以上代码改造后，我们就能够实现 拿锁比锁删锁的原子性动作了~
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Collections.singletonList(KEY_PREFIX + name)：返回一个只包含指定对象的不可变列表。 返回的列表是可序列化的。
小总结：
基于Redis的分布式锁实现思路：
利用set nx ex获取锁，并设置过期时间，保存线程标示
释放锁时先判断线程标示是否与自己一致，一致则删除锁
特性：
利用set nx满足互斥性
利用set ex保证故障时锁依然能释放，避免死锁，提高安全性
利用Redis集群保证高可用和高并发特性
小总结：我们一路走来，利用添加过期时间，防止死锁问题的发生，但是有了过期时间之后，可能出现误删别人锁的问题，这个问题我们开始是利用删之前 通过拿锁，比锁，删锁这个逻辑来解决的，也就是删之前判断一下当前这把锁是否是属于自己的，但是现在还有原子性问题，也就是我们没法保证拿锁比锁删锁是一个原子性的动作，最后通过lua表达式来解决这个问题
但是目前还剩下一个问题锁不住，什么是锁不住呢，你想一想，如果当过期时间到了之后，我们可以给他续期一下，比如续个30s，就好像是网吧上网， 网费到了之后，然后说，来，网管，再给我来10块的，是不是后边的问题都不会发生了，那么续期问题怎么解决呢，可以依赖于我们接下来的redission啦
测试逻辑：
第一个线程进来，得到了锁，手动删除锁，模拟锁超时了，其他线程会执行lua来抢锁，当第一天线程利用lua删除锁时，lua能保证他不能删除他的锁，第二个线程删除锁时，利用lua同样可以保证不会删除别人的锁，同时还能保证原子性。
分布式锁-redission
分布式锁-redission功能介绍
基于setnx实现的分布式锁存在下面的问题：
重入问题：锁的重入指的是同一个线程可以多次获取同一把锁。在第一次获取锁之后,锁的持有线程可以再次获取此锁,而无需等待。可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。
我们可以举一个例子：
void func1() {
lock.lock();
func2();
}
void func2() {
lock.lock(); // 这里可以再次获取锁,因为是同一线程请求
// do something...
lock.unlock();
}
1
2
3
4
5
6
7
8
9
10
这里,func1和func2这两个方法都对lock这个锁进行了加锁,但由于是同一个线程调用,func2可以再次成功获取lock锁,这就是锁的重入。
如果锁不支持重入,那么func2尝试获取锁就会阻塞,导致死锁。
不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。
超时释放： 我们在加锁时增加了过期时间，这样的我们可以防止死锁，但是如果卡顿的时间超长，虽然我们采用了lua表达式防止删锁的时候，误删别人的锁，但是毕竟没有锁住，有安全隐患
主从一致性： 如果Redis提供了主从集群，当我们向集群写数据时，主机需要异步的将数据同步给从机，而万一在同步过去之前，主机宕机了，就会出现死锁问题。
那么什么是Redission呢
Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务，其中就包含了各种分布式锁的实现。
简单来说Redisson就是一个在Redis基础上实现的分布式工具集。
Redission提供了分布式锁的多种多样的功能
分布式锁-Redission快速入门
引入依赖：
org.redisson
redisson
3.13.6
1
2
3
4
5
配置Redisson客户端：
@Configuration
public class RedissonConfig {
@Bean
public RedissonClient redissonClient(){
// 配置
Config config = new Config();
config.useSingleServer().setAddress("redis://192.168.150.101:6379")
.setPassword("123321");
// 创建RedissonClient对象
return Redisson.create(config);
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
如何使用Redission的分布式锁
@Resource
private RedissionClient redissonClient;
@Test
void testRedisson() throws Exception{
//获取锁(可重入)，指定锁的名称
RLock lock = redissonClient.getLock("anyLock");
//尝试获取锁，参数分别是：获取锁的最大等待时间(期间会重试)，锁自动释放时间，时间单位
boolean isLock = lock.tryLock(1,10,TimeUnit.SECONDS);
//判断获取锁成功
if(isLock){
try{
System.out.println("执行业务");
}finally{
//释放锁
lock.unlock();
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
lock.tryLock(1,10,TimeUnit.SECONDS)的意思是：尝试加锁，最多等待(尝试)1秒，上锁以后10秒自动解锁
在 VoucherOrderServiceImpl
注入RedissonClient
@Resource
private RedissonClient redissonClient;
@Override
public Result seckillVoucher(Long voucherId) {
// 1.查询优惠券
SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
// 2.判断秒杀是否开始
if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
// 尚未开始
return Result.fail("秒杀尚未开始！");
}
// 3.判断秒杀是否已经结束
if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
// 尚未开始
return Result.fail("秒杀已经结束！");
}
// 4.判断库存是否充足
if (voucher.getStock() < 1) {
// 库存不足
return Result.fail("库存不足！");
}
Long userId = UserHolder.getUser().getId();
//创建锁对象 这个代码不用了，因为我们现在要使用分布式锁
//SimpleRedisLock lock = new SimpleRedisLock("order:" + userId, stringRedisTemplate);
RLock lock = redissonClient.getLock("lock:order:" + userId);
//获取锁对象
boolean isLock = lock.tryLock();
//加锁失败
if (!isLock) {
return Result.fail("不允许重复下单");
}
try {
//获取代理对象(事务)
IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
return proxy.createVoucherOrder(voucherId);
} finally {
//释放锁
lock.unlock();
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
分布式锁-redission可重入锁原理
我们来看一个案例：
咱们自定义的分布锁采用的是 Redis 的 string 数据类型，也就是简单的 key value。整个获取锁的流程是上图右边这样子的，在一开始尝试获取锁，其实就是执行这个 set 命令，当然要加上 nx、ex 参数，那 nx 的目的就是实现一个互斥，满足互斥锁的基本要求。同时再去获取锁的时候，我们要存入这个线程的标识，其目的就是将来在释放锁的时候做判断，避免误删，只有锁是自己的才去做这个删除。
那么这样的一个流程为什么不能重入？我们一起来看一下上图左边这样一个demo。首先在这里我们会去创建一个锁的对象，接下来有一个测试方法， method1，在 method1 里会首先尝试获取锁，如果失败它就会报错，而如果成功，那么它就会去调用一个方法 method 2。而在 method 2 里又一次尝试获取锁，那么 method1 去调 method2，所以他们两个是在一个线程里的，那一个线程连续两次去加锁，这其实就是锁的重入了。那我们来看一下如果按照我们这个流程，它能不能实现重入。
首先 method1 尝试获取锁，那按照我们这里就会去 set 这个锁名称以及锁的标识进去，那在这就是lock，以及比如说这个线程名叫 Thread 1，我们把它存进去了，接下来往下执行调用这个 method 2，那么 method 2 又一次尝试获取锁，那么又要执行这个 set lock thread 1，那因为这里加了 nx 的一个参数，也就是说只有第一个人能 set 成功，那这里已经有值了。所以说 master2 在直行 try 的时候会失败。
那么可重入是怎么实现的呢？在这简单给大家说一下，其实所谓的可重入无非就是在获取锁的时候，当我判断这个锁已经有人的情况下看一下拿到锁的是不是我自己，也就是说是不是同一个线程，如果是同一个线程的话，我也会让它获取锁。
在Lock锁中，他是借助于底层的一个voaltile的一个state变量来记录重入的状态的，比如当前没有人持有这把锁，那么state=0，假如有人持有这把锁，那么state=1，如果持有这把锁的人再次持有这把锁，那么state就会+1 ，如果是对于synchronized而言，他在c语言代码中会有一个count，原理和state类似，也是重入一次就加一，释放一次就-1 ，直到减少成0 时，表示当前这把锁没有被人持有。
在分布式锁中，他采用hash结构用来存储锁，其中大key表示表示这把锁是否存在，用小key表示当前这把锁被哪个线程持有。
在redission中，我们的也支持可重入锁
redission为了保证获得锁、释放锁等操作的原子性其内部使用的也是Lua脚本：
获取锁的Lua脚本：
释放锁的Lua脚本：
所以接下来我们一起分析一下当前的这个lua表达式
这个地方一共有3个参数
KEYS[1] ： 锁名称
ARGV[1]： 锁失效时间
ARGV[2]： id + “:” + threadId; 锁的小key
exists: 判断数据是否存在 name：是lock是否存在,如果==0，就表示当前这把锁不存在
redis.call(‘hset’, KEYS[1], ARGV[2], 1);此时他就开始往redis里边去写数据 ，写成一个hash结构
Lock{
id + “:” + threadId : 1
}
如果当前这把锁存在，则第一个条件不满足，再判断
redis.call(‘hexists’, KEYS[1], ARGV[2]) == 1
此时需要通过大key+小key判断当前这把锁是否是属于自己的，如果是自己的，则进行
redis.call(‘hincrby’, KEYS[1], ARGV[2], 1)
将当前这个锁的value进行+1 ，redis.call(‘pexpire’, KEYS[1], ARGV[1]); 然后再对其设置过期时间，如果以上两个条件都不满足，则表示当前这把锁抢锁失败，最后返回pttl，即为当前这把锁的失效时间
如果小伙帮们看了前边的源码， 你会发现他会去判断当前这个方法的返回值是否为null，如果是null，则对应前两个if对应的条件，退出抢锁逻辑，如果返回的不是null，即走了第三个分支，在源码处会进行while(true)的自旋抢锁。
"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]);"
1
2
3
4
5
6
7
8
9
10
11
分布式锁-redission锁重试和WatchDog机制
不可重试解决原理
如果我们在tryLock方法中没传入过期时间，则会设置一个默认的-1，然后再tryLockInnerAsync方法中将过期时间设置为看门狗的超时时间(默认30秒)。
在tryLockInnerAsync方法中就是我们前面提到过的获取锁的Lua脚本
tryLock方法中在获取锁失败之后并不是无休止地进行尝试，而是采用的消息的订阅和发布机制。只有在别的锁释放之后发布了消息，而我们订阅了锁释放的消息，这个时候我们再去尝试获取锁。这种方法对CPU来说比较友好
超时释放解决原理
一旦我们获取锁成功，其内部会调用一个scheduleExpirationRenewal的方法，也就是安排自动续期
其内部是一个定时任务，这个定时任务的里面也使用了Lua脚本刷新有效期
定时任务进行递归调用，实现锁的有效期的一直刷新，直到锁被释放
tryLock方法原理：
ttl是锁的剩余过期时间
如果是null说明该锁还没有被获取
如果不是null说明有人正在使用这把锁
lock()方法的源码解析
抢锁过程中，获得当前线程，通过tryAcquire进行抢锁，该抢锁逻辑和之前逻辑相同
1、先判断当前这把锁是否存在，如果不存在，插入一把锁，返回null
2、判断当前这把锁是否是属于当前线程，如果是，则返回null
所以如果返回是null，则代表着当前这哥们已经抢锁完毕，或者可重入完毕，但是如果以上两个条件都不满足，则进入到第三个条件，返回的是锁的失效时间，同学们可以自行往下翻一点点，你能发现有个while( true) 再次进行tryAcquire进行抢锁
long threadId = Thread.currentThread().getId();
Long ttl = tryAcquire(-1, leaseTime, unit, threadId);
// lock acquired
if (ttl == null) {
return;
}
1
2
3
4
5
6
接下来会有一个条件分支，因为lock方法有重载方法，一个是带参数，一个是不带参数，如果带带参数传入的值是-1，如果传入参数，则leaseTime是他本身，所以如果传入了参数，此时leaseTime != -1 则会进去抢锁，抢锁的逻辑就是之前说的那三个逻辑
if (leaseTime != -1) {
return tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
}
1
2
3
如果是没有传入时间，则此时也会进行抢锁， 而且抢锁时间是默认看门狗时间 commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout()
ttlRemainingFuture.onComplete((ttlRemaining, e) 这句话相当于对以上抢锁进行了监听，也就是说当上边抢锁完毕后，此方法会被调用，具体调用的逻辑就是去后台开启一个线程，进行续约逻辑，也就是看门狗线程
RFuture ttlRemainingFuture = tryLockInnerAsync(waitTime,
commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(),
TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
ttlRemainingFuture.onComplete((ttlRemaining, e) -> {
if (e != null) {
return;
}
// lock acquired
if (ttlRemaining == null) {
scheduleExpirationRenewal(threadId);
}
});
return ttlRemainingFuture;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
此逻辑就是续约逻辑，注意看commandExecutor.getConnectionManager().newTimeout（） 此方法
Method( new TimerTask() {},参数2 ，参数3 )
指的是：通过参数2，参数3 去描述什么时候去做参数1的事情，现在的情况是：10s之后去做参数一的事情
因为锁的失效时间是30s，当10s之后，此时这个timeTask 就触发了，他就去进行续约，把当前这把锁续约成30s，如果操作成功，那么此时就会递归调用自己，再重新设置一个timeTask()，于是再过10s后又再设置一个timerTask，完成不停的续约
那么大家可以想一想，假设我们的线程出现了宕机他还会续约吗？当然不会，因为没有人再去调用renewExpiration这个方法，所以等到时间之后自然就释放了。
private void renewExpiration() {
ExpirationEntry ee = EXPIRATION_RENEWAL_MAP.get(getEntryName());
if (ee == null) {
return;
}
Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
@Override
public void run(Timeout timeout) throws Exception {
ExpirationEntry ent = EXPIRATION_RENEWAL_MAP.get(getEntryName());
if (ent == null) {
return;
}
Long threadId = ent.getFirstThreadId();
if (threadId == null) {
return;
}
RFuture<Boolean> future = renewExpirationAsync(threadId);
future.onComplete((res, e) -> {
if (e != null) {
log.error("Can't update lock " + getName() + " expiration", e);
return;
}
if (res) {
// reschedule itself
renewExpiration();
}
});
}
}, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);
ee.setTimeout(task);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
分布式锁-redission锁的MutiLock原理
为了提高redis的可用性，我们会搭建集群或者主从，现在以主从为例
此时我们去写命令，写在主机上， 主机会将数据同步给从机，但是假设在主机还没有来得及把数据写入到从机去的时候，此时主机宕机，哨兵会发现主机宕机，并且选举一个slave变成master，而此时新的master中实际上并没有锁信息，此时锁信息就已经丢掉了。
为了解决这个问题，redission提出来了MutiLock锁，使用这把锁咱们就不使用主从了，每个节点的地位都是一样的， 这把锁加锁的逻辑需要写入到每一个主从节点上，只有所有的服务器都写入成功，此时才是加锁成功，假设现在某个节点挂了，那么他去获得锁的时候，只要有一个节点拿不到，都不能算是加锁成功，就保证了加锁的可靠性。
那么MutiLock 加锁原理是什么呢？我们用一幅图来说明
当我们去设置了多个锁时，redission会将多个锁添加到一个集合中，然后用while循环去不停去尝试拿锁，但是会有一个总共的加锁时间，这个时间是用需要加锁的个数 * 1500ms ，假设有3个锁，那么时间就是4500ms，假设在这4500ms内，所有的锁都加锁成功， 那么此时才算是加锁成功，如果在4500ms有线程加锁失败，则会再次去进行重试.
思维导图总结
————————————————
版权声明：本文为CSDN博主「十八岁讨厌编程」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zyb18507175502/article/details/128590187
