Redis的分布式锁

摆烂java选手

于 2025-04-12 16:50:38 发布

阅读量786

点赞数 31

分类专栏： redis 文章标签： redis

本文链接：https://blog.youkuaiyun.com/wk200411/article/details/147165127

版权

redis 专栏收录该内容

16 篇文章

订阅专栏

Redis的分布式锁

一.分布式锁的简介
二.分布式锁的实现

一.分布式锁的简介

在一个分布式的系统中，会涉及到多个节点访问一个公共资源的情况，此时就需要通过锁的互斥来控制，避免出现类似于线程安全的问题，而Java的synchronized这样的锁只能在当前进程中生效，在分布式的这种多个进程多个主机的场景下就无能为力了。

此处就会引入了一个分布式锁来解决上述问题，分布式锁本质上就是使用⼀个公共的服务器，来记录加锁状态。这个公共的服务器可以是Redis，也可以是其他组件(比如MySQL或者ZooKeeper等)，还可以
是我们自己写的⼀个服务。

二.分布式锁的实现

1.基本实现

本质上就是通过一个键值对来标识锁的状态。

举个栗子：考虑买票的场景，现在车站提供了若干个车次，每个车次的票数都是固定的。现在存在多个服务器节点，都可能需要处理这个买票的逻辑：先查询指定车次的余票，如果余票>0，则设置余票值-=1。

当客户端1先执行查询余票，才是剩余1张，在即将执行买票操作时，此时客户端2也执行了查询预判，此时发现剩余也是1，客户端2也会执行买票操作，也就出现了超卖情况。上述的场景是存在"线程安全"问题的，需要使用锁来控制。否则就可能出现"超卖"的情况.
在这里插入图片描述

此时就引入了分布式锁，我们可以在上述架构中引入一个Redis，作为分布式锁的管理器：
在这里插入图片描述
此时，如果买票服务器1尝试买票，就需要先访问Redis，在Redis上设置⼀个键值对。比如key就是车次，value随便设置个值(比如1)

如果这个操作设置成功，就视为当前没有节点对该001车次加锁，就可以进行数据库的读写操作。操作完成之后，再把Redis上刚才的这个键值对给删除掉。

如果在买票服务器1操作数据库的过程中，买票服务器2也想买票，也会尝试给Redis上写一个键值对，
key同样是车次。但是此时设置的时候发现该车次的key已经存在了，则认为已经有其他服务器正在持
有锁，此时服务器2就需要等待或者暂时放弃。

刚才的买票场景可以使用MySQL的事务来进行批量执行查询+修改的操作。但是分布式系统中，要访问的共享资源不一定是MySQL，也有可能是其他的存储介质。这些存储介质没有事务也可以执行一段特定的操作，或者是通过统一的服务器完成执行的操作。

Redis中提供了setnx操作，正好适合这个场景。即：key不存在就设置，存在则直接失败。但是这个方案不够完善

2.引入过期时间

当服务器1加锁之后，开始处理买票的过程中，如果服务器1意外宕机了，就会导致解锁操作(删除该
key)不能执行。就可能引起其他服务器始终无法获取到锁的情况。为了解决这个问题，可以在设置key的同时引入过期时间。即这个锁最多持有多久，就应该被释放。

可以使用 set ex nx 的方式，在设置锁的同时把过期时间设置进去。此处的过期时间只能使用一个命令的方式设置。

如果分开多个操作的话就可以举个例子说明：

比如setnx之后，再来⼀个单独的expire，由于Redis的多个指令之间不存在关联，即使，使用了事务也不能保证这两个操作都⼀定成功，因此就可能出现setnx成功，但是expire失败的情况，此时仍然会出现无法正确释放锁的问题。

3.引入校验ID

对于Redis中的一个节点写入的加锁键值对，其他的节点也是可以对这个加锁键值对进行删除的。

比如服务器1写入⼀个"001"：1这样的键值对，服务器2是完全可以把"001"给删除掉的。当然，服务器2不会进行这样的"恶意删除"操作，不过不能保证因为⼀些bug导致服务器2把锁误删除。

为了解决上述问题，我们可以引⼊⼀个校验，id：

比如可以把设置的键值对的值，不再是简单的设为一个1，而是设成服务器的编号：形如 “001”: “服务器1”。这样就可以在删除key(解锁)的时候，先校验当前删除key的服务器是否是当初加锁的服务器，如果是，才能真正删除；不是，则不能删除。

4.引入Lua

因为解锁操作不是原子性的，为了使解锁操作原子，可以使用Redis的Lua脚本功能。

Lua也是一个编程语言。读作"撸啊"。是葡萄牙语中的"⽉亮"的意思。(出自于Lua官方文档)

Lua的语法类似于JS，是⼀个动态弱类型的语言。Lua的解释器⼀般使用C语言实现。Lua语法简单精炼，执行速度快，解释器也比较轻量(Lua解释器的可执行程序体积只有200KB左右)因此Lua经常作为其他程序内部嵌入的脚本语言。Redis本身就支持Lua作为内嵌脚本。

很多程序都支持内嵌脚本，如MySQL8支持JS作为内嵌脚本，比如Vim支持VimScript和Python作为内嵌脚本…

通过内嵌脚本来实现更复杂的功能，提供更强的扩展性Lua除了和Redis搭伙之外，在很多场景也会作为内嵌脚本。如在游戏开发领域常常作为编写逻辑的语言。(比如魔兽世界，大话西游等)

使用Lua脚本完成上述解锁功能：

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

上述代码可以编写成⼀个.lua后缀的文件，由redis-cli 或者 redis-plus-plus 或者jedis 等客户端加载，并发送给Redis服务器，由Redis服务器来执行这段逻辑。⼀个lua脚本会被Redis服务器以原子的方式来执行。

5.引入看门狗(watch dog)

上述方案仍然存在一个重要问题。当我们设置了key过期时间之后(比如10s)，仍然存在⼀定的可能性，
当任务还没执行完，key就先过期了。这就导致锁提前失效。

把这个过期时间设置的足够长，比如30s，是否能解决这个问题呢?很明显，设置多长时间合适，是无止境的。即使设置再长，也不能完全保证就没有提前失效的情况。

而且如果设置的太长了，万一对应的服务器挂了，此时其他服务器也不能及时的获取到锁。因此相比于设置一个固定的长时间，不如动态的调整时间更合适。

所谓watch dog，本质上是加锁的服务器上的⼀个单独的线程，通过这个线程来对锁过期时间进行"续
约"。注意。这个线程是业务服务器上的，不是Redis服务器的。

简单举个具体栗子：

初始情况下设置过期时间为10s。同时设定看门狗线程每隔3s检测⼀次。那么当3s时间到的时候，看门狗就会判定当前任务是否完成。

如果任务已经完成，则直接通过lua脚本的方式，释放锁(删除key)。
如果任务未完成，则把过期时间重写设置为10s.(即"续约")

这样就不担心锁提前失效的问题了。而且另一方面，如果该服务器挂了，看门狗线程也就随之挂了，此时无人续约，这个key自然就可以迅速过期，让其他服务器能够获取到锁了。

6.引入RedLock算法

实践中的Redis⼀般是以集群的方式部署的(至少是主从的形式，而不是单机)。那么就可能出现以下比
较极端的大冤种情况：

服务器1向master节点进行加锁操作。这个写入key的过程刚刚完成，master挂了；slave节点升级成了新的master节点。但是由于刚才写入的这个key尚未来得及同步给slave，此时就相当于服务器1的加锁操作形同虚设了，服务器2仍然可以进行加锁(即给新的master写入key。因为新的master不包含刚才的key)

为了解决这个问题，Redis的作者提出了Redlock算法：
我们引入一组Redis节点。其中每一组Redis节点都包含一个主节点和若干从节点。并且组和组之间存储的数据都是一致的，相互之间是"备份"关系(而并非是数据集合的一部分，这点有别于Redis cluster)

加锁的时候，按照一定的顺序，写多个master节点。在写锁的时候需要设定操作的"超时时间"。比如
50ms即如果set nx操作超过了50ms还没有成功，就视为加锁失败。在这里插入图片描述