Redisson 实现分布式锁源码浅析
大家好，我是此林。
今天来分享Redisson分布式锁源码。还是一样，我们用 问题驱动 的方式展开讲述。
1. redis 中如何使用 lua 脚本？
Redis内置了lua解释器，lua脚本有两个好处：
1. 减少多次Redis命令的网络传输开销。（当然也可以使用pipline命令）
2. lua脚本所有命令能保证原子性，隔离性（Redis单线程），失败回滚
综上所述，Redis中如果想要实现事务操作，可以使用lua脚本。
Redis 本身也可以使用 MULTI + WATCH乐观锁 来实现，但是它只能保证命令执行的顺序性，无法保证失败回滚，无法保证原子性。
所以，一般推荐使用 lua 脚本。
使用案例：
现在我们要去执行redis命令：
HSET info name john 1. lua脚本
local hash_key = KEYS[1] -- 哈希结构的键名（外部传入）
local key = ARGV[1] -- 哈希字段（外部传入）
local value = ARGV[2] -- 哈希字段值（外部传入）
return redis.call('HSET', hash_key, key, value)因为KEYS[1]、ARGV[1]等都是外部传入，所以可以简化。
return redis.call('HSET', KEYS[1], ARGV[1], ARGV[2])redis.call()就是执行redis命令。
2. redis 命令
EVAL "return redis.call('HSET', KEYS[1], ARGV[1], ARGV[2])" 1 info name john这里的1代表传入一个key。
2. 如何使用Redisson？
这里的
boolean isLock = lock.tryLock(1, 10, TimeUnit.SECONDS);
是获取锁，第一个1表示：锁超时等待时间，在1秒内会不断重试获取锁，直到获取到。
第二个10表示：锁释放时间，为10秒（防止java服务获取到锁后，突然宕机，导致redis锁永远不会被释放，避免造成死锁问题。）
3. Redisson源码？
3.1. Redisson如何实现锁重入？
其实归根结底，就是这段代码。Redisson本质上是使用hash结构来标志锁的，可能我们经常听到说用setnx命令来实现分布式锁，但是setnx无法实现锁的重入。
所以Redisson用 hash（计数） + lua脚本（原子性）实现可重入分布式锁。
先说明下参数：
KEYS[1]：hash结构的键名，也就是我们之前手动指定的 anylock
ARGV[1]：锁的释放时间
ARGV[2]：hash结构的字段的键名，UUID:线程id
我们直接去看redis：
anyLock这个hash结构里，
有字段的key为c3341b71-6edd-4db8-b626-9135cf727fd4:1，value为1
了解了锁的结构后，我们再来看lua脚本。
一图胜千言，总的来说，
第一个if：处理线程第一次获取锁
第二个if：处理线程重入获取锁
最后：发现锁已经被占有，返回剩余ttl（过期时间）。
3.2. 如果抢锁失败呢？
之前说的锁的设置，其实就是图中框起来的方法里的实现。
接下来，如果ttl为null，抢锁成功了，直接返回true。
如果ttl不为null，说明抢锁失败了，会去计算等待时间是否充足。
这里的等待时间就是我们之前手动设置的1秒钟。
如果锁等待时间还充足，那么执行它会去用pub-sub机制去 订阅锁释放事件。（避免轮询 Redis 造成的性能损耗。）
如果订阅超时，触发失败回调，返回false。
那么订阅成功了之后呢？会再次尝试抢锁。
还不行，那只能信号量挂起，具体通过 Semaphore（getLatch()）挂起当前线程，等待锁释放的 Pub/Sub 通知。
总结一下抢锁流程：
抢锁成功，直接返回；抢锁失败，pub/sub机制订阅锁释放事件，通过信号量挂起线程，直到收到锁释放的消息才被唤醒。
3.3. 解锁流程是怎么样的？
看下图。本质还是那一段lua脚本。
先看下锁是不是线程自己的，不是的话直接返回null。
如果锁是自己的，计数器减1。
如果减1操作后还大于0，说明重入的还没完，刷新锁的超时释放时间。
如果减1后小于等于0，直接删除，发布锁删除事件。
- 返回nil表示锁不属于当前线程，应抛出异常。
- 返回0表示锁未完全释放，仅更新了过期时间。
- 返回1表示锁已释放，并发布事件。
3.4. Redisson的看门狗机制？
看门狗主要用于 解决锁的自动续期问题，避免因业务执行时间过长导致锁超时自动释放。
注意一点：如果我们显式指定了leaseTime参数，看门狗机制就不会生效。这时候锁的过期时间由用户控制。
像我们之前手动指定了锁释放时间10秒，它就不会走看门狗机制，Redisson默认锁释放时间是30秒。（见下图，单位毫秒）
在scheduledExpirationRenewal方法里，其实就是用了netty的时间轮进行定时任务调度，每隔10秒重置锁时间为30秒，直到业务执行结束。
每次续期成功后，会递归调用 renewExpiration()，形成 无限续期链，直到锁被释放（主动释放或者客户端宕机）。
关于 时间轮，这是一种高效的定时任务调度设计。
感兴趣的朋友可以去看下之前写的文章：
时间轮：XXL-JOB 高效、精准定时任务调度实现思路分析_xxljob fasttriggerpool slowtrigger-CSDN博客
至于为什么不使用ScheduledThreadPoolExecutor？
是因为ScheduledThreadPoolExecutor的底层结构：基于优先级队列（堆实现）。插入任务的时间复杂度 O(log n)，每次插入需调整堆结构。
使用时间轮插入任务的时间复杂度为 O(1)，直接哈希到时间槽（Bucket），并且支持同一槽内任务批量触发。
3.5. Redisson怎么解决死锁的？
主要就是设置了锁的超时释放时间，客户端宕机了会自动超时释放。
然后还有一点支持重入，如果同一个线程两次去获取锁，因为支持重入，第二次就不会阻塞等待自己释放锁了。
至于说看门狗机制会无限续期，客户端宕机了就续期不了，不会导致死锁。
那你说：业务要是无限阻塞，永远执行不完呢？
这个也不大可能，为什么业务会无限阻塞？这个时候肯定需要人工介入去排查问题了。
今天的分享就到这里了，我是此林。
关注我吧，带你看不一样的世界！