Redis分布式锁的前世今生

数据库 Redis
redisson是redis官方推荐的一个分布式锁的框架,它帮我们解决了上面提到的所有问题,底层也是用了lua脚本实现,同时又提供了watchdog(看门狗)机制,在锁将要过期的时候,会自动检测业务是否执行完成,如果没有完成,则自动延长锁的过期时间,直到业务执行完成。

背景

如今的服务大多数是集群化部署,这就使得像synchronized、ReentrantLock等传统的本地锁失去了功效。因此需要引入第三方的服务实现对这些并发进程的调度,从而控制对共享资源的访问,像redis、zookeeper、mysql等。其中又以redis的应用最为广泛。

分布式锁的要素

最重要的两个要素:排他性、容错性。

排他性是指在分布式应用集群中,同一个方法在同一时间内只能被一台机器上的一个线程执行。

容错性是指不论正常的业务执行完成,还是突发性的程序崩溃或者网络中断,都要保证分布式锁最终一定能得到释放,不能出现死锁现象。

redis分布式锁的基本命令

1、加锁 SETNX key value

setnx 的含义就是 SET if Not Exists,有两个参数 setnx(key, value),该方法是原子性操作。如果 key 不存在,则设置当前 key 成功,返回 1;如果当前 key 已经存在,则设置当前 key 失败,返回 0。

2、解锁 del (key)

得到锁的线程执行完任务,需要释放锁,以便其他线程可以进入。

3、配置锁超时 expire (key,30s)

客户端崩溃或者网络中断,资源将会永远被锁住,即死锁,因此需要给key配置过期时间,以保证即使没有被显式释放,这把锁也要在一定时间后自动释放。

OK,有了上面的理论基础,我们就可以来逐步的揭开redis分布式锁的神秘面纱。

我们以常见的扣减库存的场景为例,当有线程来执行扣减库存的方法时,大致逻辑是先判断当前库存,如果还有库存的话,就库存减1,然后生成明细记录。

一把问题很多的锁

首先看一段伪代码。

methodA(){
//ID为666的商品库存扣减key
String key = "stock:deduct:666"

if(setnx(key,1) == 1{
expire(key,10,TimeUnit.SECONDS)
try {
//查询是否有库存
//扣减库存
//生成明细记录
} finally {
del(key)
}
}else{
//获取锁失败,睡眠100毫秒,然后自旋调用本方法
methodA()
}
}

这段代码的主要逻辑是,先给ID为666的商品库存上锁,然后设置key的过期时间为10秒,之后就执行扣减库存的逻辑了,等业务逻辑执行完成,就删除key释放锁。在此期间如果有其他线程来获取锁,会上锁失败,失败后就等一会再次调用methodA方法继续尝试上锁,然后循环往复,直到上锁成功。

看上去大功告成了,所谓的分布式锁也不过如此。

然而,正如我们标题上写的,这是一把问题很多的锁,有什么问题呢?

首先最大的问题是,多个命令之间不是原子操作。在setnx和expire之间是分了两步来执行的,如果setnx成功,但是expire却执行失败,或者还没有执行就突发宕机,就造成了这个资源的死锁,违反了我们上面提到的容错性原则。

另外存在的一个问题是,可能会出现线程A删掉了线程B的锁。假设有两个线程A和B,A先上锁成功开始执行业务逻辑,但由于某些原因导致A执行很慢,15秒才执行完,但A的锁有效期只有10秒,A锁过期后,B上锁成功,但是B还没有执行完业务逻辑,线程A业务逻辑执行完成,执行删锁操作,此时删除的,实际上是B的锁,B的锁删掉了,也就无法阻止其他线程来加锁,违反了上面提到的排他性原则。

如何解决这两个问题呢?

优化后的锁

第一个问题,既然多个命令之间不是原子操作,我们用一个命令就行了,而redis恰好也提供了一个这样的命令,setex,即在赋值的时候设置过期时间,这是一个原子命令。对应到java中,也有这样的API供我们使用:

redisTemplate.opsForValue().setIfAbsent("key","success",10,TimeUnit.SECONDS)

第二个问题,可以在删除锁之前做一个判断,验证当前要删除的锁是不是自己的锁,实现方式也很简单,可以将value值设置为当前的线程ID或者随便一个UUID。

优化后的伪代码应该是这样的:

methodA(){
//ID为666的商品库存扣减key
String key = "stock:deduct:666";
String value = Thread.currentThread().getId();

if(setex(key, 10, value) == 1{
try {
//查询是否有库存
//扣减库存
//生成明细记录
} finally {
if(get(key).equals(value)){
del(key)
}
}
}else{
//获取锁失败,睡眠100毫秒,然后自旋调用本方法
methodA()
}
}

这把锁总没问题了吧?

然而,细细考究一下,还是会发现不妥之处。虽然我们删除锁的时候做了判断,但仍有可能删错锁。根本原因是判断锁和删除锁同样不是原子操作。

那到底如何保证绝对的原子性?

lua脚本的横空出世

这里我们不去深究lua脚本是什么,只需要知道,lua是一个脚本语言,redis执行lua脚本的时候,会将它里面的命令当做一个整体去执行,要么全部执行成功,要么出现异常,结果不会更新到redis中。

因此,上面的删锁操作,我们完全可以将判断命令和删除命令都放到lua脚本中,然后由代码去执行lua脚本,最终会实现我们想要的原子操作。

实际上,这也正是redis官方推荐的做法。具体可查看官方文档:​​set 命令 -- Redis中国用户组(CRUG)​​。

这里提供一段java中调用lua脚本的代码,大家看了后可以加深理解:

String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
Integer result = redisTemplate.execute(new DefaultRedisScript<>(script, Integer.class), Arrays.asList(lockKey), uuid);

其中的脚本代码是官方文档中提供的,可以直接复制过来使用。

原生分布式锁

综合上面所说的,一个完整的原生分布式锁应该就是下面这个样子了:

methodA(){
//ID为666的商品库存扣减key
String key = "stock:deduct:666";
String value = Thread.currentThread().getId();
String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
if(setex(key, 10, value) == 1{
try {
//查询是否有库存
//扣减库存
//生成明细记录
} finally {
//解锁
Long result = redisTemplate.execute( new DefaultRedisScript<>(script,Long.class),Arrays.asList(lockKey),uuid);
}
}else{
//获取锁失败,睡眠100毫秒,然后自旋调用本方法
methodA()
}
}

这就是一个比较完善的分布式锁了,既满足了对共享资源的并发控制,又保证了加锁、解锁的原子性操作,防止突发状况造成的死锁问题。

这里大家再想一个问题,如何避免业务执行时间过长锁过期的问题?为了保证排他性,肯定要保证在业务执行时间内,锁是一定不能过期的。在原生的分布式锁中,没有什么好的方法,只能加长锁的过期时间,保证业务一定能执行完成。

那么,有没有更好的解决方案呢?

Hi,我叫redisson

redisson是redis官方推荐的一个分布式锁的框架,它帮我们解决了上面提到的所有问题,底层也是用了lua脚本实现,同时又提供了watchdog(看门狗)机制,在锁将要过期的时候,会自动检测业务是否执行完成,如果没有完成,则自动延长锁的过期时间,直到业务执行完成。而且最重要的一点,使用起来非常简单,几行代码就可以搞定,不像原生锁那样繁琐,是我们进行分布式锁开发的不二选择。这里不做详细描述了,感兴趣的可以在网上搜索一下。

好了,关于redis分布式锁就到这里了。

责任编辑:姜华 来源: 今日头条
相关推荐

2019-06-19 15:40:06

分布式锁RedisJava

2019-02-26 09:51:52

分布式锁RedisZookeeper

2022-01-06 10:58:07

Redis数据分布式锁

2023-08-21 19:10:34

Redis分布式

2019-06-10 14:53:15

分布式架构应用服务

2019-11-25 09:32:26

软件程序员数据结构

2022-12-01 07:36:40

2023-03-01 08:07:51

2020-11-16 12:55:41

Redis分布式锁Zookeeper

2022-09-19 08:17:09

Redis分布式

2021-06-16 07:56:21

Redis分布式

2019-07-16 09:22:10

RedisZookeeper分布式锁

2019-12-25 14:35:33

分布式架构系统

2023-01-13 07:39:07

2021-06-03 00:02:43

RedisRedlock算法

2021-07-30 00:09:21

Redlock算法Redis

2023-04-03 10:00:00

Redis分布式

2022-12-18 20:07:55

Redis分布式

2022-03-08 07:22:48

Redis脚本分布式锁

2023-10-11 09:37:54

Redis分布式系统
点赞
收藏

51CTO技术栈公众号