Redis实现分布式锁

最新推荐文章于 2024-08-13 14:41:03 发布

爆发的~小宇宙

最新推荐文章于 2024-08-13 14:41:03 发布

阅读量188

点赞数

分类专栏： redis 文章标签： redis分布式锁 redis 锁分布式

原文链接：https://blog.csdn.net/kongmin_123/article/details/82080962#commentBox

版权

redis 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

概述

最近在使用分布式锁，看到一篇博客介绍的挺详细的，这里记录下方便查看，后续会把简单的代码实现作为参考
原文链接：https://blog.csdn.net/kongmin_123/article/details/82080962#commentBox

正文

在多线程并发的情况下，我们可以使用锁来保证一个代码块在同一时间内只能由一个线程访问。比如Java的synchronized关键字和Reentrantlock类等等。

这样子可以保证在同一个JVM进程内的多个线程同步执行。

如果在分布式的集群环境中，如何保证不同节点的线程同步执行呢？

怎么才能在分布式系统中，实现不同线程对代码和资源的同步访问？

对于单进程的并发场景，我们可以使用语言和类库提供的锁。对于分布式场景，我们可以使用分布式锁。

那么怎么才能实现分布式系统中的锁呢？

分布式锁有许多中实现方法，下面简单列举一下。

分布式锁的实现有哪些？

1.Memcached分布式锁

利用Memcached的add命令。此命令是原子性操作，只有在key不存在的情况下，才能add成功，也就意味着线程得到了锁。

2.Redis分布式锁

和Memcached的方式类似，利用Redis的setnx命令。此命令同样是原子性操作，只有在key不存在的情况下，才能set成功。（setnx命令并不完善，后续会介绍替代方案）

3.Zookeeper分布式锁

利用Zookeeper的顺序临时节点，来实现分布式锁和等待队列。Zookeeper设计的初衷，就是为了实现分布式锁服务的。

首先讲一下Redis的分布式锁，这种实现方式比较有代表性。

如何用Redis实现分布式锁？

Redis分布式锁的基本流程并不难理解，但要想写得尽善尽美，也并不是那么容易。在这里，我们需要先了解分布式锁实现的三个核心要素：

1.加锁

最简单的方法是使用setnx命令。key是锁的唯一标识，按业务来决定命名。比如想要给一种商品的秒杀活动加锁，可以给key命名为 “lock_sale_商品ID” 。而value设置成什么呢？锁的value值为一个随机生成的UUID。我们可以姑且设置成1。加锁的伪代码如下：

setnx（key，1）

当一个线程执行setnx返回1，说明key原本不存在，该线程成功得到了锁；当一个线程执行setnx返回0，说明key已经存在，该线程抢锁失败。

2.解锁

有加锁就得有解锁。当得到锁的线程执行完任务，需要释放锁，以便其他线程可以进入。释放锁的最简单方式是执行del指令，伪代码如下：

del（key）

释放锁之后，其他线程就可以继续执行setnx命令来获得锁。

3.锁超时

锁超时是什么意思呢？如果一个得到锁的线程在执行任务的过程中挂掉，来不及显式地释放锁，这块资源将会永远被锁住，别的线程再也别想进来。

所以，setnx的key必须设置一个超时时间，单位为second，以保证即使没有被显式释放，这把锁也要在一定时间后自动释放，避免死锁。setnx不支持超时参数，所以需要额外的指令，伪代码如下：

expire（key， 30）

综合起来，我们分布式锁实现的第一版伪代码如下：


 
 
   
   
    
    
   
   
   
   
    
    
     
     if（setnx（key，
     
     1） == 
     
     1）{
    
    
   
   

   
   
    
    
   
   
   
   
    
    
     
         expire（key，
     
     30）
    
    
   
   

   
   
    
    
   
   
   
   
    
    
     
         
     
     try {
    
    
   
   

   
   
    
    
   
   
   
   
    
    
     
             
     
     do something ......
    
    
   
   

   
   
    
    
   
   
   
   
    
    
     
         } 
     
     finally {
    
    
   
   

   
   
    
    
   
   
   
   
    
    
     
             del（key）
    
    
   
   

   
   
    
    
   
   
   
   
    
    
     
         }
    
    
   
   

   
   
    
    
   
   
   
   
    
    
     
     }

上面的伪代码只是分布式锁的简单实现，结合实际应用场景考虑就会发现上述分布式锁的实现存在着三个致命问题：

1. setnx和expire的非原子性

设想一个极端场景，当某线程执行setnx，成功得到了锁：

setnx刚执行成功，还未来得及执行expire指令，节点1 Duang的一声挂掉了。

这样一来，这把锁就没有设置过期时间，变得“长生不老”，别的线程再也无法获得锁了。

怎么解决呢？setnx指令本身是不支持传入超时时间的，幸好Redis 2.6.12以上版本为set指令增加了可选参数，伪代码如下：

set（key，1，30，NX）

这样就可以取代setnx指令。

2. del 导致误删

又是一个极端场景，假如某线程成功得到了锁，并且设置的超时时间是30秒。

如果某些原因导致线程A执行的很慢很慢，过了30秒都没执行完，这时候锁过期自动释放，线程B得到了锁。

随后，线程A执行完了任务，线程A接着执行del指令来释放锁。但这时候线程B还没执行完，线程A实际上删除的是线程B加的锁。

怎么避免这种情况呢？可以在del释放锁之前做一个判断，验证当前的锁是不是自己加的锁。

至于具体的实现，可以在加锁的时候把当前的线程ID当做value，并在删除之前验证key对应的value是不是自己线程的ID。

加锁：


 
 
   
   
    
    
   
   
   
   
    
    
     
     String threadId = Thread.currentThread().getId()
    
    
   
   

   
   
    
    
   
   
   
   
    
    
     
     set（key，threadId ，
     
     30，NX）

解锁：


 
 
   
   
    
    
   
   
   
   
    
    
     
     if（threadId .equals(redisClient.get(key))）{
    
    
   
   

   
   
    
    
   
   
   
   
    
    
     
         del(key)
    
    
   
   

   
   
    
    
   
   
   
   
    
    
     
     }