Redisson分布式锁案列和源码解读

分布式锁的核心功能其实就三个：加锁、解锁、设置锁超时

同时在了解分布式锁之前，也需要了解Redis的发布订阅功能。

Redis的发布订阅功能

具体的操作演示如下：

         开启3个客户端，一个订阅了频道 **channel1** ，另外个订阅了频道 **channel1**，最后一个通过PUBLISH发送消息后，订阅的那个就能收到了，靠这种模式就能实现不同客户端之间的通信。 

Redisson分布式锁源码整体分析

RLock接口

       **RLock**是一个接口，具体的同步器需要实现该接口，当我们调用 `redisson.getLock()`时，程序会初始化一个默认的同步执行器**RedissonLock** 

1、commandExecutor ：异步的Executor执行器，Redisson中所有的命令都是通过...Executor 执行的 ；

2、internalLockLeaseTime：等待获取锁时间，这里读的是配置类中默认定义的，时间为30秒；

3、pubSub：封装了发布订阅功能组件

 Redisson锁的执行流程

通过Redis的monitor监控Redis服务器的命令 

 1、不启动看门狗的加锁

这里只加锁，然后让主线程休眠，我们看下针对Redis做了什么操作

这里可以和《Redisson锁的执行流程》对应看一看。

这里可以看到Redisson的加锁实际上是一个Lua脚本+针对一个哈希类型的操作（hincrby命令）

2、不启动看门狗的加锁+解锁

这里可以看到：

这里可以看到Redisson的解锁实际上是一个Lua脚本（del操作）+publish发布的操作。

3、不启动看门狗的加锁+解锁（重入锁的情况）

 可以看到这里没有删除掉key，这里实现锁的可重入是利用一个计数，加锁一次就加1，解锁一次就减1。

4、启动看门狗的加锁 

 Redisson锁的执行流程+源码分析

跟踪lock方法进入源码

代码还是挺长的，不过流程也就两步：

**要么线程拿到锁返回成功；**

**要么没拿到锁并且等待时间还没过就继续循环拿锁（这里使用监听机制避免来优化了），同时监听锁是否被释放。**

以上的Lua脚本就比较清晰了：

1、当前key不存在：标识锁未被占用

2、使用hset写入一个hash类型的数据：其中，key为锁的名称、field为“Redisson客户端ID：线程id”，value=1

3、执行pexpire，设置失效时间

4、当前key存在：标识已经获取到了锁

5、hincrby新增field的value，并且重新设置超时时间。

6、最后都不满足：获取锁失败，返回锁的剩余超时时间。

**拿不到的话，就会返回锁的剩余过期时长，这个时长有什么作用呢？？？**

用Java的Semaphore信号量的tryAcquire方法来阻塞线程。

Semaphore信号量又是由谁控制呢，何时才能release呢。

这段代码的作用在于将当前线程的**threadId**添加到一个**AsyncSemaphore**中，并且设置一个redis的监听器，这个监听器是通过redis的发布、订阅功能实现的。

一旦监听器收到redis发来的消息，就从中获取与当前thread相关的，如果是锁被释放的消息，就立马通过操作 **Semaphore** （也就是调用**release**方法）来让刚才阻塞的地方释放。

看门狗线程续锁

io.netty.util.Timeout 使用

这个源码，就是一个定时器，每隔 10s 递归执行一次