黄东旭解析 TiDB 的核心优势
631
2023-06-16
Redis分布式锁的前世今生
背景
如今的服务大多数是集群化部署,这就使得像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分布式锁就到这里了。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。