应用
加锁机制
lock()底层是通过一段 lua 脚本实现的
KEYS[1] 代表你加锁的那个 key，RLock lock = redisson.getLock(“myLock”); 这里你本人设置了加锁的那个锁 key 就是“myLock”
ARGV[1]代表的就是锁 key 的默认生存工夫，默认 30 秒
ARGV[2] 代表的是加锁的客户端的 ID，相似于上面这样：8743c9c0-0795-4907-87fd-6c719a6b4586:1
加锁流程:
1. 判断是否存在这个加锁的 key
2. 如果不存在，通过 hset 命令加锁
3. 设置过期工夫
锁互斥机制
如果客户端 2 来尝试加锁，执行了同样的一段 lua 脚本。
1. 第一个 if 判断这个 key 发现已存在，走第二个 if 判断 key 中的客户端的 id 是否与是客户端 2 的 id
2. 如果发现不是，客户端 2 会获取到 pttl myLock 返回的一个数字，这个数字代表了 myLock 这个锁 key 的 残余生存工夫。比方还剩 15000 毫秒的生存工夫。此时客户端 2 会进入一个 while 循环，不停的尝试加锁。
实际上的原理：
当锁正在被占用时，期待获取锁的过程并不是通过一个 while(true) 死循环去获取锁，而是利用了 Redis 的公布订阅机制, 通过 await 办法阻塞期待锁的过程，无效的解决了 有效的锁申请浪费资源的问题。
watch dog 主动延期机制
客户端 1 加锁的锁 key 默认生存工夫才 30 秒，如果超过了 30 秒，客户端 1 还想始终持有这把锁，怎么办呢？
简略！只有客户端 1 一旦加锁胜利，就会启动一个 watch dog 看门狗，他是一个后盾线程，会每隔 10 秒检查一下，如果客户端 1 还持有锁 key，过期工夫持续缩短为 30s。
可重入加锁机制
下面那段 lua 脚本。第一个 if 判断必定不成立 ，“exists myLock”会显示锁 key 曾经存在了。 第二个 if 判断会成立，因为 myLock 的 hash 数据结构中蕴含的那个 ID，就是客户端 1 的那个 ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”，此时就会执行可重入加锁的逻辑，他会用：incrby myLock 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1，通过这个命令，对客户端 1 的加锁次数，累加 1，变为 myLock 8743c9c0-0795-4907-87fd-6c71a6b4586:1 2
锁开释机制
如果执行 lock.unlock()，就能够开释分布式锁，此时的业务逻辑也是非常简单的。其实说白了，就是每次都对 myLock 数据结构中的那个加锁次数减 1。如果发现加锁次数是 0 了，阐明这个客户端曾经不再持有锁了，此时就会用：“del myLock”命令，从 redis 里删除这个 key
此种计划 Redis 分布式锁的缺点
计划最大的问题，就是如果你对某个 redis master 实例，写入了 myLock 这种锁 key 的 value，此时会异步复制给对应的 master slave 实例。然而这个过程中一旦产生 redis master 宕机，主备切换，redis slave 变为了 redis master。接着就会导致，客户端 2 来尝试加锁的时候，在新的 redis master 上实现了加锁，而客户端 1 也认为本人胜利加了锁。此时就会导致多个客户端对一个分布式锁实现了加锁。这时零碎在业务语义上肯定会呈现问题，导致各种脏数据的产生 。
所以这个就是 redis cluster，或者是 redis master-slave 架构的主从异步复制导致的 redis 分布式锁的最大缺点：在 redis master 实例宕机的时候，可能导致多个客户端同时实现加锁。
参考大佬：
托付，面试请不要再问我 Redis 分布式锁的实现原理！