|
|
|
|
公众号矩阵

Redis锁被别人释放怎么办

当多个进程不在同一个系统中,用分布式锁控制多个进程对资源的访问。有这样一个情境,线程A和线程B都共享某个变量X。如果是分布式情况下,线程A和线程B很可能不是在同一对象中,每个客户端在释放锁时,都是删除操作,并没有检查这把锁是否还是自己的,所以就会发生释放别人锁的风险。

作者:conan来源:后端Q|2021-10-01 00:12

 

本文转载自微信公众号「后端Q」,作者conan 。转载本文请联系后端Q公众号。

什么是分布式锁?

要介绍分布式锁,首先要提到与分布式锁相对应的是线程锁、进程锁。

线程锁:主要用来给方法、代码块加锁。当某个方法或代码使用锁,在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果,因为线程锁的实现在根本上是依靠线程之间共享内存实现的,比如synchronized是共享对象头,显示锁Lock是共享某个变量(state)。

进程锁:为了控制同一操作系统中多个进程访问某个共享资源,因为进程具有独立性,各个进程无法访问其他进程的资源,因此无法通过synchronized等线程锁实现进程锁。

问题窥探

分布式锁:当多个进程不在同一个系统中,用分布式锁控制多个进程对资源的访问。有这样一个情境,线程A和线程B都共享某个变量X。如果是分布式情况下,线程A和线程B很可能不是在同一对象中,每个客户端在释放锁时,都是删除操作,并没有检查这把锁是否还是自己的,所以就会发生释放别人锁的风险。

解决办法

客户端在加锁时,设置一个只有自己知道的唯一标识进去。例如,可以是自己的线程 ID,也可以是一个 UUID(随机且唯一),这里我们以 UUID 举例:

  1. // 锁的VALUE设置为UUID 
  2. 127.0.0.1:6379> SET lock $uuid EX 20 NX 
  3. OK 

这里假设 20s 操作共享时间完全足够,先不考虑锁自动过期的问题。之后,在释放锁时,要先判断这把锁是否还归自己持有,伪代码可以这么写:

  1. // 锁是自己的,才释放 
  2. if redis.get("lock") == $uuid: 
  3.     redis.del("lock"
  4.      

这里释放锁使用的是 GET + DEL 两条命令,这时,又会遇到我们前面讲的原子性问题了。

客户端 1 执行 GET,判断锁是自己的

客户端 2 执行了 SET 命令,强制获取到锁(虽然发生概率比较低,但我们需要严谨地考虑锁的安全性模型)

客户端 1 执行 DEL,却释放了客户端 2 的锁

由此可见,这两个命令还是必须要原子执行才行。

怎样原子执行呢?Lua 脚本。

我们可以把这个逻辑,写成 Lua 脚本,让 Redis 来执行。

因为 Redis 处理每一个请求是单线程执行的,在执行一个 Lua 脚本时,其它请求必须等待,直到这个 Lua 脚本处理完成,这样一来,GET + DEL 之间就不会插入其它命令了。安全释放锁的 Lua 脚本如下:

  1. // 判断锁是自己的,才释放 
  2. if redis.call("GET",KEYS[1]) == ARGV[1] 
  3. then 
  4.     return redis.call("DEL",KEYS[1]) 
  5. else 
  6.     return 0 
  7. end 

好了,这样一路优化,整个的加锁、解锁的流程就更严谨了。

这里我们先小结一下,基于 Redis 实现的分布式锁,一个严谨的的流程如下:

  1. 加锁:SET lock_key $unique_id EX $expire_time NX 

操作共享资源 释放锁:Lua 脚本,先 GET 判断锁是否归属自己,再 DEL 释放锁

【编辑推荐】

  1. 赌你看不懂:分布式存储系统的数据强一致性挑战
  2. 聊聊Docker中如何安装Redis_Exporter
  3. 基于人工智能技术伦敦国王学院与葛兰素史克展开癌症研究合作
  4. Apple Pay被爆安全漏洞 可绕过锁屏进行欺诈性支付
  5. Sentry 监控 - Distributed Tracing 分布式跟踪
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微