redis深度历险 千帆竞发 —— 分布式锁

分布式应用进行逻辑处理时经常会遇到并发问题。
比如一个操作要修改用户的状态,修改状态需要先读出用户的状态,在内存里进行修改,改完了再存回去。如果这样的操作同时进行了,就会出现并发问题,因为读取和保存状态这两个操作不是原子的。(Wiki 解释:所谓原子操作是指不会被线程调度机制打断的操作;这种操作一旦开始,就一直运行到结束,中间不会有任何 context switch 线程切换。)
redis深度历险 千帆竞发 —— 分布式锁_第1张图片
这个时候就要使用到分布式锁来限制程序的并发执行。Redis 分布式锁使用非常广泛,它是面试的重要考点之一,很多同学都知道这个知识,也大致知道分布式锁的原理,但是具体到细节的使用上往往并不完全正确。

1 分布式锁

1.1 步骤1,向 Redis 节点发送命令,请求锁。

分布式锁本质上要实现的目标就是在 Redis 里面占一个“茅坑”,当别的进程也要来占时,发现已经有人蹲在那里了,就只好放弃或者稍后再试。

占坑一般是使用 setnx(set if not exists) 指令,只允许被一个客户端占坑。先来先占, 用完了,再调用 del 指令释放茅坑。

127.0.0.1:6379> setnx lock:codehole true
(integer) 1
127.0.0.1:6379>  .. do something critical ..
127.0.0.1:6379>  .. do something critical ..
127.0.0.1:6379> del lock:codehole
(integer) 1
127.0.0.1:6379>

但是有个问题,如果逻辑执行到中间出现异常了,可能会导致 del 指令没有被调用,这样就会陷入死锁,锁永远得不到释放。

于是我们在拿到锁之后,再给锁加上一个过期时间,比如 5s,这样即使中间出现异常也可以保证 5 秒之后锁会自动释放。

127.0.0.1:6379> setnx lock:codehole true
(integer) 1
127.0.0.1:6379> expire lock:codehole 5
(integer) 1
127.0.0.1:6379>.. do something critical ..
127.0.0.1:6379>.. do something critical ..
127.0.0.1:6379> del lock:codehole
(integer) 1

但是以上逻辑还有问题。如果在setnx和 expire 之间服务器进程突然挂掉了,可能是因为机器掉电或者是被人为杀掉的,就会导致expire 得不到执行,也会造成死锁。

这种问题的根源就在于setnx和 expire是两条指令而不是原子指令。如果这两条指令可以一起执行就不会出现问题。也许你会想到用Redis事务来解决。但是这里不行,因为expire是依赖于 setnx的执行结果的,如果 setnx没抢到锁, expire是不应该执行的。事务里没有 if-else 分支逻辑,事务的特点是一口气执行,要么全部执行要么一个都不执行。

为了解决这个疑难,Redis开源社区涌现了一堆分布式锁的 library,专门用来解决这个问题。实现方法极为复杂,小白用户一般要费很大的精力才可以搞懂。如果你需要使用分布式锁,意味着你不能仅仅使用Jedis或者redis-py就行了,还得引入分布式锁的 library。
redis深度历险 千帆竞发 —— 分布式锁_第2张图片

为了治理这个乱象,Redis 2.8 版本中作者加入了 set 指令的扩展参数,使得 setnx 和expire 指令可以一起执行,彻底解决了分布式锁的乱象。从此以后所有的第三方分布式锁library 可以休息了。

127.0.0.1:6379> set lock:codehole true ex 5 nx
OK
127.0.0.1:6379>.. do something critical ..
127.0.0.1:6379>.. do something critical ..
127.0.0.1:6379> del lock:codehole
(integer) 0

setnx 和 expire 组合在一起的原子指令,它就是分布式锁的奥义所在。

下面解释下各参数的意义。

set  lock:codehole    true                ex 5                nx
SET  lock_name        my_random_value     EX 30000            NX 
  • lock_name,即锁名称,这个名称应是公开的,在分布式环境中,对于某一确定的公共资源,所有争用方(客户端)都应该知道对应锁的名字。对于 Redis 而言,lock_name 就是 Key-Value 中的 Key,具有唯一性。
  • my_random_value是由客户端生成的一个随机字符串,它要保证在足够长的一段时间内,且在所有客户端的所有获取锁的请求中都是唯一的,用于唯一标识锁的持有者。
  • NX 表示只有当 lock_name(key) 不存在的时候才能 SET成功,从而保证只有一个客户端能获得锁,而其它客户端在锁被释放之前都无法获得锁。
  • EX 30000 表示这个锁节点有一个 30秒的自动过期时间(目的是为了防止持有锁的客户端故障后,无法主动释放锁而导致死锁,因此要求锁的持有者必须在过期时间之内执行完相关操作并释放锁)。

1.2 步骤2,如果步骤 1 的命令返回成功,则代表获取锁成功,否则获取锁失败。

对于一个拥有锁的客户端,释放锁流程如下。
(1)向 Redis 节点发送命令,获取锁对应的 Value,代码如下:

GET lock_name

(2)如果查询回来的 Value 和客户端自身的 my_random_value 一致,则可确认自己是锁的持有者,可以发起解锁操作,即主动删除对应的 Key,发送命令:

DEL lock_name

通过 Redis-cli 执行上述命令,显示如下:

100.X.X.X:6379> set lock_name my_random_value NX EX 30000
OK
100.X.X.X:6379> get lock_name
"my_random_value"
100.X.X.X:6379> del lock_name
(integer) 1
100.X.X.X:6379> get lock_name
(nil)

你可能感兴趣的:(数据库-Redis,redis,分布式,wpf)