Redis分布式锁的最佳实践 - Redisson

﹏ヽ暗。殇╰゛Y 2023-05-21 12:55 10阅读 0赞

![format_png][]

# Redisson 实现分布式锁 #

本文只介绍Redisson如何实现分布式锁的原理。

### 一、高效分布式锁 ###

当我们在设计分布式锁的时候，我们应该考虑分布式锁至少要满足的一些条件，同时考虑如何高效的设计分布式锁，这里我认为以下几点是必须要考虑的。

#### 1、互斥 ####

在分布式高并发的条件下，我们最需要保证，同一时刻只能有一个线程获得锁，这是最基本的一点。

#### 2、防止死锁 ####

在分布式高并发的条件下，比如有个线程获得锁的同时，还没有来得及去释放锁，就因为系统故障或者其它原因使它无法执行释放锁的命令,导致其它线程都无法获得锁，造成死锁。

所以分布式非常有必要设置锁的 `有效时间` ，确保系统出现故障后，在一定时间内能够主动去释放锁，避免造成死锁的情况。

#### 3、性能 ####

对于访问量大的共享资源，需要考虑减少锁等待的时间，避免导致大量线程阻塞。

所以在锁的设计时，需要考虑两点。

1、 `锁的颗粒度要尽量小`  
。比如你要通过锁来减库存，那这个锁的名称你可以设置成是商品的ID,而不是任取名称。这样这个锁只对当前商品有效,锁的颗粒度小。

2、 `锁的范围尽量要小` 。比如只要锁2行代码就可以解决问题的，那就不要去锁10行代码了。

#### 4、重入 ####

我们知道ReentrantLock是可重入锁，那它的特点就是：同一个线程可以重复拿到同一个资源的锁。重入锁非常有利于资源的高效利用。关于这点之后会做演示。

针对以上Redisson都能很好的满足，下面就来分析下它。

### 二、Redisson原理分析 ###

为了更好的理解分布式锁的原理，我这边自己画张图通过这张图来分析。

![format_png 1][]

#### 1、加锁机制 ####

线程去获取锁，获取成功: 执行lua脚本，保存数据到redis数据库。

线程去获取锁，获取失败: 一直通过while循环尝试获取锁，获取成功后，执行lua脚本，保存数据到redis数据库。

#### 2、watch dog自动延期机制 ####

这个比较难理解，找了些许资料感觉也并没有解释的很清楚。这里我自己的理解就是:

在一个分布式环境下，假如一个线程获得锁后，突然服务器宕机了，那么这个时候在一定时间后这个锁会自动释放，你也可以设置锁的有效时间(不设置默认30秒），这样的目的主要是防止死锁的发生。

但在实际开发中会有下面一种情况:

//设置锁1秒过去
                redissonLock.lock(redisson, 1);
                /**
                 * 业务逻辑需要咨询2秒
                 */
                redissonLock.release(redisson);
    
              /**
               * 线程1 进来获得锁后，线程一切正常并没有宕机，但它的业务逻辑需要执行2秒，这就会有个问题，在 线程1 执行1秒后，这个锁就自动过期了，
               * 那么这个时候 线程2 进来了。那么就存在 线程1和线程2 同时在这段业务逻辑里执行代码，这当然是不合理的。
               * 而且如果是这种情况，那么在解锁时系统会抛异常，因为解锁和加锁已经不是同一线程了，具体后面代码演示。
               */

所以这个时候 `看门狗` 就出现了，它的作用就是 线程1 业务还没有执行完，时间就过了，线程1 还想持有锁的话，就会启动一个watch  
dog后台线程，不断的延长锁key的生存时间。

`注意` 正常这个看门狗线程是不启动的，还有就是这个看门狗启动后对整体性能也会有一定影响，所以不建议开启看门狗。

#### 3、为啥要用lua脚本呢？ ####

这个不用多说，主要是如果你的业务逻辑复杂的话，通过封装在lua脚本中发送给redis，而且redis是单线程的，这样就保证这段复杂业务逻辑执行的  
**原子性** 。

#### 4、可重入加锁机制 ####

Redisson可以实现可重入加锁机制的原因，我觉得跟两点有关：

1、Redis存储锁的数据类型是 Hash类型
        2、Hash数据类型的key值包含了当前线程信息。

下面是redis存储的数据

![format_png 2][]

这里表面数据类型是Hash类型,Hash类型相当于我们java的 `<key,<key1,value>>` 类型,这里key是指 'redisson'

它的有效期还有9秒，我们再来看里们的key1值为 `078e44a3-5f95-4e24-b6aa-80684655a15a:45` 它的组成是:

guid + 当前线程的ID。后面的value是就和可重入加锁有关。

**举图说明**

![format_png 3][]

上面这图的意思就是可重入锁的机制，它最大的优点就是相同线程不需要在等待锁，而是可以直接进行相应操作。

#### 5、Redis分布式锁的缺点 ####

Redis分布式锁会有个缺陷，就是在Redis哨兵模式下:

`客户端1` 对某个 `master节点` 写入了redisson锁，此时会异步复制给对应的 slave节点。但是这个过程中一旦发生  
master节点宕机，主备切换，slave节点从变为了 master节点。

这时 `客户端2` 来尝试加锁的时候，在新的master节点上也能加锁，此时就会导致多个客户端对同一个分布式锁完成了加锁。

这时系统在业务语义上一定会出现问题， **导致各种脏数据的产生** 。

`缺陷` 在哨兵模式或者主从模式下，如果 master实例宕机的时候，可能导致多个客户端同时完成加锁。

![format_png 4][]

*  [MySQL性能优化(一)：MySQL架构与核心问题][MySQL_MySQL]
 *  [ MySQL性能优化(二)：选择优化的数据类型][MySQL]
 *  [MySQL性能优化(三)：深入理解索引的这点事][MySQL 1]
 *  [MySQL性能优化(四)：如何高效正确的使用索引 ][MySQL 2]
 *  [MySQL性能优化(五)：为什么查询速度这么慢][MySQL 3]  
    
 *  [微服务架构下的核心话题 (一)：微服务架构下各类项目的顺势崛起][Link 1]
 *  [微服务架构下的核心话题 (二)：微服务架构的设计原则和核心话题][Link 2]
 *  [微服务架构下的核心话题 (三)：微服务架构的技术选型][Link 3]

![format_png 5][]

喜欢就点个"在看"呗，留言、转发朋友圈

[format_png]: /images/20230521/03332b5c009c4f79b1719053dce391c0.png
[format_png 1]: /images/20230521/9b9979aa22df4d02ab7057ee59390212.png
[format_png 2]: /images/20230521/9b48994eb4884315aeca1750fdd45f22.png
[format_png 3]: /images/20230521/40c17ba387584b4ab69eb2f662831d78.png
[format_png 4]: /images/20230521/944327563272423eaa53dc243b68b569.png
[MySQL_MySQL]: https://blog.csdn.net/xcbeyond/article/details/104574275
[MySQL]: http://mp.weixin.qq.com/s?__biz=MzA5MzUwOTY4NQ%3D%3D&chksm=905d89e9a72a00ffd26b7bd32b10213ddd72e16d05e10aca8df42919db494289de2686ad1263&idx=1&mid=2247485619&scene=21&sn=c5a033c1046a279ce285573321bcc858#wechat_redirect
[MySQL 1]: https://blog.csdn.net/xcbeyond/article/details/104858619
[MySQL 2]: http://mp.weixin.qq.com/s?__biz=MzA5MzUwOTY4NQ%3D%3D&chksm=905d885ba72a014d2cb27ffacabecd5e4d28ef4cc2e033915c72a74b468db119eac07d0f3d74&idx=1&mid=2247485697&scene=21&sn=48e3a4ab43ffb5bbdd8b763dae391da0#wechat_redirect
[MySQL 3]: https://blog.csdn.net/xcbeyond/article/details/105375386
[Link 1]: https://blog.csdn.net/xcbeyond/article/details/97503091
[Link 2]: https://blog.csdn.net/xcbeyond/article/details/98392304
[Link 3]: https://blog.csdn.net/xcbeyond/article/details/102511891
[format_png 5]: /images/20230521/54cf57db56ea4d52a76a089989cd1c2b.png