社区编辑申请
注册/登录
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分布式锁就到这里了。

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

2022-06-30 08:04:16

2022-02-28 10:12:10

Redis分布式开发

2019-02-26 09:51:52

分布式锁RedisZookeeper

2021-09-26 09:16:45

2022-06-28 08:37:07

分布式服务器WebSocket

2021-11-29 00:18:30

2021-03-24 08:41:38

Redis 分布式锁序列化

2021-03-07 16:11:26

Redis分布式

2022-03-04 09:54:04

Redis分布式锁脚本

2022-05-31 08:04:03

Redis高可用集群

2020-10-19 07:30:57

Java Redis 开发

2019-06-25 08:46:04

Redis分布式锁JVM

2022-05-09 15:08:56

存储厂商NFV领域华为

2021-01-12 14:56:40

Redis分布式锁工具

2021-02-02 16:37:25

Redis分布式

2021-03-10 09:54:06

Redis分布式

2019-01-21 11:01:52

2020-02-11 16:10:44

Redis分布式锁Java

2020-07-23 09:10:09

Redis分布式锁漏洞

2022-06-15 16:16:21

分布式数据库鸿蒙

同话题下的热门内容

通俗易懂讲解Redis的哨兵模式Redis 的内存淘汰策略和过期删除策略,你别再搞混了!没遇到过这三个问题都不好意思说用过Redis分享AWS的Redis如何正确迁移至阿里云项目实践Redisson 高性能 Redis 分布式锁源码分析

编辑推荐

几款开源的图形化Redis客户端管理软件推荐Redis内存淘汰策略,看这一篇就够了!Redis 的默认端口为啥是 6379 ?Redis集群的5种使用方式,各自优缺点分析Redis为什么这么快?一文深入了解Redis内存模型!
我收藏的内容
点赞
收藏

51CTO技术栈公众号