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

分布式应用进行逻辑处理时经常会遇到并发问题。

比如一个操作要修改用户的状态，修改状态需要先读出用户的状态，在内存里进行修改，改完了再存回去。如果这样的操作同时进行了，就会出现并发问题，因为读取和保存状态这两个操作不是原子的。（Wiki 解释：所谓原子操作是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch 线程切换。）

这个时候就要使用到分布式锁来限制程序的并发执行。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.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)