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

谁践踏了优雅 2023-01-13 06:06 280阅读 0赞

*  ⼀、写在前⾯
 *  ⼆、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 分布式锁的底层原理 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70]

*  （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实现分布式锁**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMwMjI0MA_size_16_color_FFFFFF_t_70]: /images/20221022/1689cb4f550f4778aa479ce7206a4b15.png