redis通过lua脚本实现分布式锁

实现原理。

说实话&＃xff0c;如果在公司里落地生产环境用分布式锁的时候&＃xff0c;一定是会用开源类库的&＃xff0c;比如Redis分布式锁&＃xff0c;一般就是用Redisson框架就好了&＃xff0c;非常的简便易用。

大家如果有兴趣&＃xff0c;可以去看看Redisson的官网&＃xff0c;看看如何在项目中引入Redisson的依赖&＃xff0c;然后基于Redis实现分布式锁的加锁与释放锁。

下面给大家看一段简单的使用代码片段&＃xff0c;先直观的感受一下&＃xff1a;

怎么样&＃xff0c;上面那段代码&＃xff0c;是不是感觉简单的不行&＃xff01;

此外&＃xff0c;人家还支持redis单实例、redis哨兵、redis cluster、redis master-slave等各种部署架构&＃xff0c;都可以给你完美实现。

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

好的&＃xff0c;接下来就通过一张手绘图&＃xff0c;给大家说说Redisson这个开源框架对Redis分布式锁的实现原理。

&＃xff08;1&＃xff09;加锁机制

咱们来看上面那张图&＃xff0c;现在某个客户端要加锁。如果该客户端面对的是一个redis cluster集群&＃xff0c;他首先会根据hash节点选择一台机器。

这里注意&＃xff0c;仅仅只是选择一台机器&＃xff01;这点很关键&＃xff01;

紧接着&＃xff0c;就会发送一段lua脚本到redis上&＃xff0c;那段lua脚本如下所示&＃xff1a;

为啥要用lua脚本呢&＃xff1f;

因为一大坨复杂的业务逻辑&＃xff0c;可以通过封装在lua脚本中发送给redis&＃xff0c;保证这段复杂业务逻辑执行的原子性。

那么&＃xff0c;这段lua脚本是什么意思呢&＃xff1f;

KEYS[1]代表的是你加锁的那个key&＃xff0c;比如说&＃xff1a;

RLock lock &＃61; redisson.getLock("myLock");

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

ARGV[1]代表的就是锁key的默认生存时间&＃xff0c;默认30秒。

ARGV[2]代表的是加锁的客户端的ID&＃xff0c;类似于下面这样&＃xff1a;

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

给大家解释一下&＃xff0c;第一段if判断语句&＃xff0c;就是用“exists myLock”命令判断一下&＃xff0c;如果你要加锁的那个锁key不存在的话&＃xff0c;你就进行加锁。

如何加锁呢&＃xff1f;很简单&＃xff0c;用下面的命令&＃xff1a;

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

通过这个命令设置一个hash数据结构&＃xff0c;这行命令执行后&＃xff0c;会出现一个类似下面的数据结构&＃xff1a;

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

接着会执行“pexpire myLock 30000”命令&＃xff0c;设置myLock这个锁key的生存时间是30秒。

好了&＃xff0c;到此为止&＃xff0c;ok&＃xff0c;加锁完成了。

&＃xff08;2&＃xff09;锁互斥机制

那么在这个时候&＃xff0c;如果客户端2来尝试加锁&＃xff0c;执行了同样的一段lua脚本&＃xff0c;会咋样呢&＃xff1f;

很简单&＃xff0c;第一个if判断会执行“exists myLock”&＃xff0c;发现myLock这个锁key已经存在了。

接着第二个if判断&＃xff0c;判断一下&＃xff0c;myLock锁key的hash数据结构中&＃xff0c;是否包含客户端2的ID&＃xff0c;但是明显不是的&＃xff0c;因为那里包含的是客户端1的ID。

所以&＃xff0c;客户端2会获取到pttl myLock返回的一个数字&＃xff0c;这个数字代表了myLock这个锁key的剩余生存时间。比如还剩15000毫秒的生存时间。

此时客户端2会进入一个while循环&＃xff0c;不停的尝试加锁。

&＃xff08;3&＃xff09;watch dog自动延期机制

客户端1加锁的锁key默认生存时间才30秒&＃xff0c;如果超过了30秒&＃xff0c;客户端1还想一直持有这把锁&＃xff0c;怎么办呢&＃xff1f;

简单&＃xff01;只要客户端1一旦加锁成功&＃xff0c;就会启动一个watch dog看门狗&＃xff0c;他是一个后台线程&＃xff0c;会每隔10秒检查一下&＃xff0c;如果客户端1还持有锁key&＃xff0c;那么就会不断的延长锁key的生存时间。

&＃xff08;4&＃xff09;可重入加锁机制

那如果客户端1都已经持有了这把锁了&＃xff0c;结果可重入的加锁会怎么样呢&＃xff1f;

比如下面这种代码&＃xff1a;

这时我们来分析一下上面那段lua脚本。

第一个if判断肯定不成立&＃xff0c;“exists myLock”会显示锁key已经存在了。

第二个if判断会成立&＃xff0c;因为myLock的hash数据结构中包含的那个ID&＃xff0c;就是客户端1的那个ID&＃xff0c;也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”

此时就会执行可重入加锁的逻辑&＃xff0c;他会用&＃xff1a;

incrby myLock 

 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1

通过这个命令&＃xff0c;对客户端1的加锁次数&＃xff0c;累加1。

此时myLock数据结构变为下面这样&＃xff1a;

大家看到了吧&＃xff0c;那个myLock的hash数据结构中的那个客户端ID&＃xff0c;就对应着加锁的次数

&＃xff08;5&＃xff09;释放锁机制

如果执行lock.unlock()&＃xff0c;就可以释放分布式锁&＃xff0c;此时的业务逻辑也是非常简单的。

其实说白了&＃xff0c;就是每次都对myLock数据结构中的那个加锁次数减1。

如果发现加锁次数是0了&＃xff0c;说明这个客户端已经不再持有锁了&＃xff0c;此时就会用&＃xff1a;

“del myLock”命令&＃xff0c;从redis里删除这个key。

然后呢&＃xff0c;另外的客户端2就可以尝试完成加锁了。

这就是所谓的分布式锁的开源Redisson框架的实现机制。

一般我们在生产系统中&＃xff0c;可以用Redisson框架提供的这个类库来基于redis进行分布式锁的加锁与释放锁。

&＃xff08;6&＃xff09;上述Redis分布式锁的缺点

其实上面那种方案最大的问题&＃xff0c;就是如果你对某个redis master实例&＃xff0c;写入了myLock这种锁key的value&＃xff0c;此时会异步复制给对应的master slave实例。

但是这个过程中一旦发生redis master宕机&＃xff0c;主备切换&＃xff0c;redis slave变为了redis master。

接着就会导致&＃xff0c;客户端2来尝试加锁的时候&＃xff0c;在新的redis master上完成了加锁&＃xff0c;而客户端1也以为自己成功加了锁。

此时就会导致多个客户端对一个分布式锁完成了加锁。

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

所以这个就是redis cluster&＃xff0c;或者是redis master-slave架构的主从异步复制导致的redis分布式锁的最大缺陷&＃xff1a;在redis master实例宕机的时候&＃xff0c;可能导致多个客户端同时完成加锁。

三、未完待续

下一篇文章&＃xff0c;给大家分享一下电商系统中&＃xff0c;大促销的活动场景下&＃xff0c;每秒上千订单的时候如何对Redis分布式锁进行高并发的优化。

敬请关注&＃xff1a;

《每秒上千订单的高并发场景下如何完成分布式锁的性能优化&＃xff1f;》