分布式锁之浪漫的爱情故事

一、简介

分布式知识是考验一个程序员知识面广度和深度很好的度量标准，而分布式锁又是其中非常重要的一个知识点。

我们知道分布式应用在进行逻辑处理的时候经常涉及到并发的问题，比如对一个转账修改一个用户的账户金额数据，此时可能会涉及多个用户同时对这个用户进行转账，它们都需要将数据读取到各内存中进行修改，然后再存刷新回去，这个时候就会出现并发问题：

这里假设初始account.money = 400

1. 客户端A，向账户转账100，并未提交到Redis
2. 客户端B，读取金额为400，并向账户转账200
3. 客户端A提交
4. 客户端B提交

最后account.money = 600

执行流程如下所示：

出现上述问题的主要原因是，“读取”和“写入”这两个操作并不是一个原子操作（所谓原子操作是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （切换到另一个线程））。

关于上述问题的解决，分布式锁就可以派上用场了，我们通过分布式锁来限制程序的并发执行，就像Java中的synchronized，常见的分布式锁解决方案如下所示：

1. 基于数据库锁机制实现的分布式锁
2. 基于Zookeeper实现的分布式锁
3. 基于Redis实现的分布式锁

本文和大家共同探讨的是基于Redis的分布式锁。

二、分布式锁的演进

2.1 精细胞与卵细胞的爱情故事

嗯……学过生物的宝宝们都知道，精细胞和卵细胞相遇的故事，上亿精细胞中最后也只会有一个幸运的精细胞和卵细胞发生甜蜜的爱情故事，这是因为当有一个精子进入卵子后，卵子会发生皮质反应、透明带反应使透明带对精子的结合能力下降，阻止了多精受精。分布式锁就好像卵细胞，而万千访问客户端就好比精细胞，无论客户访问并发多激烈，我们也应该保证分布式锁只被一个线程获取到。

2.2 Redis中的分布式锁

2.2.1 setnx

我们将Redis实现分布式锁理解为上厕所蹲坑排队，只有一个坑，但是有多个人要到坑里面去，所以就只能一个一个的来了。

很多人一开始想到的是Redis中一般使用setnx(set if no exists)指令来实现，setnx是如果不存在，则 SET的简写，这个指令描述如下：

• 只在键 key 不存在的情况下，将键 key 的值设置为 value 。
• 若键 key 已经存在， 则 SETNX 命令不做任何动作。

127.0.0.1:6379> exists lock  			# lock key不存在
(integer) 0
127.0.0.1:6379> setnx lock true		# 设值成功
(integer) 1
127.0.0.1:6379> setnx lock false	# 覆盖失败
(integer) 0
127.0.0.1:6379> del lock          # 删除lock 释放
(integer) 1

如上这种方案存在的问题非常明显，如果逻辑执行过程中间出现了异常，可能导致del key 指令没有执行，这样会产生死锁。如下图所示：

2.2.2 setnx + expire

在第一种解决方案的基础上，可能部分人会相到，既然主动删除key可能会出现异常情况，那么就设值key的过期时间到期自动删除。

127.0.0.1:6379> setnx lock true		
(integer) 1
127.0.0.1:6379> expire lock 10		# 设值过期时间10s
(integer) 1	
127.0.0.1:6379> setnx lock true		# 10s内再次设值失败
(integer) 0
127.0.0.1:6379> setnx lock true		# 10skey过期，后设置成功
(integer) 1

这种的方案和前面的方案其实并没有本质上的区别，它还是可能会出现服务器异常等情况，导致expire的不到执行的情况，换汤不换药，如下图所示：

2.2.3 原子操作

基于上面两种方案，我们可以发现，产生问题的本质在于两个操作并不是原子操作。方案一中是setnx指令加一个del指令，方案二中是setnx指令加一个expire指令，这两个指令并不是原子指令。基于这个问题，Redis官方将这两个指令组合在了一起，解决Redis分布式锁原子性操作的问题。

先认真看set指令可选参数 EX 和 NX

set key value [EX seconds] [PX milliseconds] [NX|XX]

EX seconds ：将键的过期时间设置为 seconds 秒。执行 SET key value EX seconds 的效果等同于执行 SETEX key seconds value 。

PX milliseconds ：将键的过期时间设置为 milliseconds 毫秒。执行 SET key value PX milliseconds 的效果等同于执行 PSETEX key milliseconds value 。

NX ：只在键不存在时，才对键进行设置操作。执行 SET key value NX 的效果等同于执行 SETNX key value 。

XX ：只在键已经存在时，才对键进行设置操作。

127.0.0.1:6379> set lock true EX 10 NX		# 设置 10s生效
OK
127.0.0.1:6379> set lock true EX 10 NX		# 10s内再次设值失败
(nil)
127.0.0.1:6379> set lock true EX 10 NX		# 10s后设置成功
OK

如上这个操作就成功的解决了Redis分布式锁的原子操作问题。

2.2.4 解锁

Redis分布式锁加锁在上面讲述了，而Redis分布式锁的解锁过程其实就是将key删除，key的删除有客户端调用del指令删除，也有设置key的过期时间自动删除。但是这个删除不能乱删除，不能说客户端A请求的锁被客户端B给删除了……，那这把锁就是一把烂锁了。

为了防止客户端A请求的锁被客户端B给删除了这种情况，我们通过匹配客户端传入的锁的值与当前锁的值是否相等来做判断（这个值是随机且保证不会重复的），如果相等就删除，解锁成功。

但是Redis并未提供这样的功能，我们只能通过Lua脚本来处理，因为Lua脚本可以保证多个指令的原子性执行。

示例：

首先设置一个key，这个key的值是123456789，通过客户端传入的value值是否相等来校验是否允许删除这个key

127.0.0.1:6379> get lock
(nil)
127.0.0.1:6379> set lock 123456789	# 设置一个key 值为123456789
OK
127.0.0.1:6379> get lock
"123456789"