Redisson和Jedis类似，都是用Java实现的操作Redis的客户端，但是使用场景不同。Redisson更多用在分布式场景下（功能可以看wiki），Jedis更多用在单机场景下。
1 Java接入Redisson
以Spring Boot为例，接入Redisson的依赖：
和使用Jedis类似，需要初始化一个Redisson客户端，使用提供的API来创建Redisson对象（指定了配置，以及要操作的是哪个Redis实例），然后注入到容器中：
上面的代码里是单机模式，也支持其他的配置方法，如集群、主从、复制、哨兵等主流的Redis架构：
在业务代码里注入：
2 使用Redisson分布式锁
使用方法：
这里的加锁操作就相当于实现了前面Java笔记70里讲的SETNX加锁+设置超时时间+开分线程做锁续命等一系列操作。
加锁的逻辑（加锁成功就开一个后台线程做锁续命，一般是超时时间的1/3时间续一次，加锁不成功就循环尝试）：
3 RLock.lock()的底层核心实现
3.1 设置key-value和超时时间
这里会执行一个lua脚本来操作Redis：
首先使用exists命令判断key存不存在。
如果不存在，就使用hset命令来设置key-value，其中key就是传进来的key，value是根据原生线程id做了一些封装得到的线程唯一标识（ARGV[2]对应getLockName(threadId)）。
然后使用pexpire命令设置一下超时时间（ARGV[1]对应internalLockLeaseTime），去追溯一下可以看到这个超时时间默认是30秒：
试想为什么这里可以将设置key和设置超时时间分成两条命令？实际是因为Redis（>=2.6）支持开发者编写Lua脚本传到Redis中执行：
也就是说Redisson里的一长串Lua脚本实际是原子性执行的。
3.2 锁续命的实现
在执行完前面Lua脚本的异步加锁操作之后，执行了一个回调，调了一个看似要执行定时任务的scheduleXXX：
点进去可以看到确实是拉起了一个定时任务：
可以看到又执行了一段Lua脚本，先用hexists判断一下自己的主线程设置的key还存不存在（这里KEYS[1]就是要查的key，ARGV[2]是要比较value确认确实是自己主线程加的key）。
然后，如果判断发现这把锁还存在，就调用pexpire命令，重新把锁（key为KEYS[1]）的超时时间设置为一开始定的ARGV[1]。
注意，这个锁续命操作是delay做的，延迟时间就是设置的超时时间的1/3：
但是这样也只是延迟执行一次，如何能做到间隔执行？往下看可以看到，在锁续命执行完一次后，又加了一个监听器来调用自己（指这个scheduleXXX），也就实现了不断的间隔续命：
