拜托，面试官不要在问我Redis分布式锁原理了

• ?、写在前?
• ?、Redisson 实现 Redis 分布式锁的底层原理
  （1）加锁机制
  （2）锁互斥机制
  （3）watch dog ?动延期机制
  （4）可重?加锁机制
  （5）锁释放机制
  （6）此种?案 Redis 分布式锁的缺陷

?、写在前面

现在?试，?般都会聊聊分布式系统这块的东?。通常?试官都会从服务框架（Spring Cloud、Dubbo）聊起，?路聊到分布式事务、分布式锁、ZooKeeper 等知识。

所以咱们这篇?章就来聊聊分布式锁这块知识，具体的来看看 Redis 分布式锁的实现原理。

说实话，如果在公司?落地?产环境?分布式锁的时候，?定是会?开源类库的，?如 Redis分布式锁，?般就是? Redisson 框架就好了，?常的简便易?。
?家如果有兴趣，可以去看看 Redisson 的官?，看看如何在项?中引? Redisson 的依赖，然后基于 Redis 实现分布式锁的加锁与释放锁。

下?给?家看?段简单的使?代码?段，先直观的感受?下：

```java
RLock rlock = redission.getLock("mylock");
rlock.lock();
rlock.unlock();

怎么样，上?那段代码，是不是感觉简单的不?！
此外，?家还?持 redis 单实例、redis 哨兵、redis cluster、redis master-slave 等各种部署架构，都可以给你完美实现。

?、Redisson 实现 Redis 分布式锁的底层原理

• （1）加锁机制
  咱们来看上?那张图，现在某个客户端要加锁。如果该客户端?对的是?个 redis cluster 集群，他?先会根据 hash 节点选择?台机器。
  这?注意，仅仅只是选择?台机器！这点很关键!
  紧接着，就会发送?段 lua 脚本到 redis 上

为啥要? lua 脚本呢？
因为??坨复杂的业务逻辑，可以通过封装在 lua 脚本中发送给 redis，保证这段复杂业务逻辑?的原?性。
那么，这段 lua 脚本是什么意思呢？

KEYS[1] 代表的是你加锁的那个 key，?如说：
RLock lock = redisson.getLock(“myLock”);

这?你??设置了加锁的那个锁 key 就是 “myLock”。

ARGV[1] 代表的就是锁 key 的默认?存时间，默认 30 秒。
ARGV[2] 代表的是加锁的客户端的 ID，类似于下?这样：

8743c9c0-0795-4907-87fd-6c719a6b4586:1
给?家解释?下，第?段 if 判断语句，就是? “exists myLock” 命令判断?下，如果你要加锁的那个锁 key 不存在的话，你就进?加锁。
如何加锁呢？很简单，?下?的命令：

hset myLock 8743c9c0-0795-4907-87fd-6c719a6b4586:1 1

上述就代表 “8743c9c0-0795-4907-87fd-6c719a6b4586:1” 这个客户端对 “myLock” 这个锁key 完成了加锁。

接着会执? “pexpire myLock 30000” 命令，设置 myLock 这个锁 key 的?存时间是 30 秒

• （2）锁互斥机制
  那么在这个时候，如果客户端 2 来尝试加锁，执?了同样的?段 lua 脚本，会咋样呢？
  很简单，第?个 if 判断会执? “exists myLock” ，发现 myLock 这个锁 key 已经存在了。
  接着第?个 if 判断，判断?下，myLock 锁 key 的 hash 数据结构中，是否包含客户端 2 的 ID，
  但是明显不是的，因为那?包含的是客户端 1 的 ID。
  所以，客户端 2 会获取到 pttl myLock 返回的?个数字，这个数字代表了 myLock 这个锁
  key 的剩余?存时间。?如还剩 15000 毫秒的?存时间。
  此时客户端 2 会进??个 while 循环，不停的尝试加锁。

• （3）watch dog ?动延期机制
  客户端 1 加锁的锁 key 默认?存时间才 30 秒，如果超过了 30 秒，客户端 1 还想?直持有这把锁，怎么办呢？
  简单！只要客户端 1 ?旦加锁成功，就会启动?个 watch dog 看?狗，他是?个后台线程，会每隔 10 秒检查?下，如果客户端 1 还持有锁 key，那么就会不断的延?锁 key 的?存时间。

（4）可重?加锁机制
那如果客户端 1 都已经持有了这把锁了，结果可重?的加锁会怎么样呢？

第?个 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。

• （5）锁释放机制
  如果执? lock.unlock() ，就可以释放分布式锁，此时的业务逻辑也是?常简单的。
  其实说?了，就是每次都对 myLock 数据结构中的那个加锁次数减 1。
  如果发现加锁次数是 0 了，说明这个客户端已经不再持有锁了，此时就会?：
  “del myLock” 命令，从 redis ?删除这个 key。
  然后呢，另外的客户端 2 就可以尝试完成加锁了。
  这就是所谓的分布式锁的开源 Redisson 框架的实现机制。
  ?般我们在?产系统中，可以? Redisson 框架提供的这个类库来基于 redis 进?分布式锁的加锁与释放锁。

• （6）此种?案 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 实例宕机的时候，可能导致多个客户端同时完成加锁。

下一篇我们聊聊 zookeeper实现分布式锁