Redis实现分布式锁

最新推荐文章于 2025-04-11 13:39:36 发布

转载最新推荐文章于 2025-04-11 13:39:36 发布 · 238 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://www.jb51.net/article/243044.htm

文章标签：

#redis #分布式

Redis 专栏收录该内容

4 篇文章

订阅专栏

文章目录

应用场景
分布式锁介绍
- 实现一：SETNX + EXPIRE
实现二：SETNX (value 为过期具体时间)
实现三：Lua脚本保证原子性
实现四：SET EX PX NX
实现五：添加唯一校验值
实现六：Redisson
实现七：多机实现Redlock

应用场景

秒杀系统超买超卖
缓存失效时大量访问（缓存击穿）

分布式锁介绍

分布式锁是控制分布式系统不同进程共同访问共享资源的一种锁的实现。不同主机之间共享了某个临界资源，往往需要通过互斥防止彼此干扰，保证一致性。

分布式锁特征

互斥：任意时刻，只能有一个客户端持有锁
锁超时释放：防止不必要的资源浪费，避免死锁
可重入性：一个线程获取锁后，可以再次对其请求加锁
高性能和高可用：加锁解锁开销尽量小，同时保证高可用，避免分布式锁失效
安全性：锁只能被持有的客户端删除，不可以被其他客户端删除

实现一：SETNX + EXPIRE

通过SETNX获取锁，获取锁后再使用EXPIRE设置过期时间，防止锁忘记释放。

if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加锁
    expire（key_resource_id，100）; //设置过期时间
    try {
        do something  //业务请求
    } catch() {
  	}
  	finally {
       jedis.del(key_resource_id); //释放锁
    }
}

不是原子性操作
SETNX与EXPIRE是两个命令，不是原子性操作。如果在获取锁后系统出现错误，未执行EXPIRE，没有设置过期时间，则会导致锁永远无法释放！造成死锁。
锁过期释放
业务过长时，还没有处理完事务，锁就已经过期，此时其他线程可能获取锁，若此时该业务处理完则会删除锁。（也就是一个线程释放了另一个线程持有的锁，此时另一个线程业务可能还未处理完毕）

实现二：SETNX (value 为过期具体时间)

为了解决实现一中异常锁无法释放场景，可以通过将过期的具体时间放入value中，如果获取锁失败则取出value校验

long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间
String expiresStr = String.valueOf(expires);
 
// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
        return true;
} 
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key_resource_id);
 
// 如果获取到的过期时间，小于系统当前时间，表示已经过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
 
     // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈）
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
     
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁
         return true;
    }
}
         
//其他情况，均返回加锁失败
return false;
}

需要各个客户端时间同步
可能存在锁过期被其他客户端占有，却被当前客户端释放的问题

实现三：Lua脚本保证原子性

同实现一原理，但是通过Lua脚本保证原子性

//LUA脚本
if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then
   redis.call('expire',KEYS[1],ARGV[2])
else
   return 0
end;
 
//加锁
String lua_scripts = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then" +
            " redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end";   
Object result = jedis.eval(lua_scripts, Collections.singletonList(key_resource_id), Collections.singletonList(values));
//判断是否成功
return result.equals(1L);

实现四：SET EX PX NX

SET key value [EX seconds] [PX milliseconds] [NX|XX]
NX：表示key不存在的时候，才能set成功，也即保证只有第一个客户端请求才能获得锁，而其他客户端请求只能等其释放锁，才能获取。
EX seconds：设定key的过期时间，时间单位是秒。
PX milliseconds：设定key的过期时间，单位为毫秒
XX：仅当key存在时设置值

if（jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
  }
  finally {
       jedis.del(key_resource_id); //释放锁
  }
}

实现五：添加唯一校验值

SET EX PX NX + 校验唯一随机值,再释放锁

锁可能被别的线程误删，那我们给value值设置一个标记当前线程唯一的随机数，在删除的时候，校验一下，不就OK了嘛

if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
   }
   finally {
       //判断是不是当前线程加的锁,是才释放
       if (uni_request_id.equals(jedis.get(key_resource_id))) {
        jedis.del(lockKey); //释放锁
        }
    }
}

判断是否为当前线程加的锁和释放锁不是原子性操作。可能这把锁已经不属于当前客户端！也可以通过Lua脚本代替实现原子性操作。

if redis.call('get',KEYS[1]) == ARGV[1] then 
   return redis.call('del',KEYS[1]) 
else
   return 0
end;

实现六：Redisson

每隔一段时间检查锁是否还存在，存在则对锁的过期时间延长，防止锁过期提前释放。

Redisson便实现了该过程，原理图如下
在这里插入图片描述
只要线程以加锁成功，就会启动一个watch dog看门狗，它是一个后台线程，会每隔10秒检查一下，如果线程1还持有锁，那么就会不断的延长锁key的生存时间。因此，Redisson解决了锁过期释放但业务没执行完的问题。

实现七：多机实现Redlock

针对Redis集群
在这里插入图片描述

如果线程一在Redis的master节点上拿到了锁，但是加锁的key还没同步到slave节点。恰好这时，master节点发生故障，一个slave节点就会升级为master节点。线程二就可以获取同个key的锁啦，但线程一也已经拿到锁了，锁的安全性就没了。

为了解决这个问题，Redis提出一种高级的分布式锁算法：Redlock。我们假设当前有5个Redis master节点，在5台服务器上面运行这些Redis实例，如下图所示：
在这里插入图片描述
则RedLock的实现步骤如下：

按顺序向5个master节点请求加锁。
根据设置的超时时间来判断，是不是要跳过该master节点。
如果大于等于3个节点（N/2+1，这里是5/2+1=3个节点）加锁成功，并且使用的时间小于锁的有效期，即可认定加锁成功啦。
如果获取锁失败，解锁！