分布式锁的核心功能其实就三个：加锁、解锁、设置锁超时
同时在了解分布式锁之前，也需要了解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 递归执行一次
