浅谈用Redis实现分布式锁的方案及细节

前言

我们都知道，在面对并发问题时，有加锁操作和保证原子操作两种解决方案。当我们采用加锁操作的时候，因为Redis多采用集群的方式部署，因此我们就需要考虑到锁在分布式系统中使用的注意事项。接下来就看看Redis的分布式锁问题。

单机锁

说到分布式锁，首先我们得了解【单机锁】。单机锁比较简单，不用考虑分布式系统中各个服务的资源、网络等差异。

单机锁使用起来也很简单，用一个变量就能实现锁必备的互斥功能。比如设置一个锁变量lock，当lock=0时，说明锁空闲着；当lock=1时，说明此时锁被某个线程占用了。在进行互斥操作时先获取lock的值，只有lock=0才能继续，当操作完成后，再将锁释放出来。

对分布式锁的要求

既然单机锁这么简单，为什么分布式锁就很复杂呢？

上面将单机锁的时候也有提到，分布式锁用于分布式系统中，系统中每台服务器的资源、网络状况都不同，我们需要在不同的服务器存储锁变量。锁的操作（加锁、释放锁）在不同的情况下，就会衍生出相应的问题。

我们对分布式锁的要求很简单，总结就是：

锁操作（加锁、释放锁），需要保证锁操作的原子性。
分布式系统，要考虑到系统故障的场景。当某些服务器实例发生故障时，要保证分布式锁能正常使用。

如图，多个进程同时请求对mysql某个数据操作，首先要去获取分布式锁。图例中只有进程1获取到锁，因此加锁后进行下一步的操作；而其他2个进程因为没有获取到锁不能往下操作，这样就做到了互斥。

分布式锁，实现的方式有很多，也就是需要在一个系统中维护锁变量lock。而基于性能的考量，选择Redis作为分布式锁的场景很常见。

Redis单个节点分布式锁的实现

要实现分布式锁，首要的就是保证操作的互斥性。在Redis中有SETNX命令，这个命令的含义是：若key不存在，才去设置它的值；key存在的话就不操作。

这样一来，分布式系统的多个客户端可通过该命令达到互斥的要求。

如上面图例：

客户端a在要更新mysql资源时，先向Redis分布式锁申请加锁，也就是执行SETNX lock 1,加锁成功。
客户端b也申请加锁，但被客户端a已经加锁了，因此加锁失败，不往下执行。
客户端a加锁成功后，更新MySQL操作。操作完成后，再删除lock变量DEL lock。

整个过程就是这样，但是我们再仔细想想就会发现这种方式有个很大的漏洞。那就是当客户端a加锁成功后，如果在操作mysql的过程中发生异常了，锁就不会释放。这样也就死锁了，其他的客户端都别想拿到锁了。

这个死锁的问题，你可能会说解决起来也不麻烦，给锁加个过期时间不就行了。于是乎，操作命令变成了这样：

127.0.0.1:6379> SETNX lock 1
(integer) 1
127.0.0.1:6379> EXPIRE lock 5
(integer) 1
复制代码

经过EXPIRE操作后，就不用担心锁不释放的问题了。

但我们仔细想想，这里加锁和给锁设置过期时间是分为2步走的，也就是说不是原子性操作，如果执行完上锁操作后，如果还没来得及给锁设置过期时间客户端就异常了，这样也会造成死锁。

因此，将这2条命令原子化才是关键。庆幸的是，SET命令支持将这2步一次性执行了（Redis版本要>=2.6.12）。命令示例：

127.0.0.1:6379> SET lock 1 EX 5 NX
OK
复制代码

这样一来，死锁的问题解决了。但你认为这样就万事大吉了吗？显然不是，有一个场景还需要考虑到，那就是：锁过期时间到了被自动释放后，等客户端正常操作完成后，又会去释放锁。具体来说如下：

客户端a申请锁lock成功，然后更新MySQL去了；
因为mysql连接问题，客户端a更新操作，超过了设定的过期时间，于是lock被自动释放了；
客户端b这时申请lock成功，也开始更新MySQL了；
MySQL连接正常了，客户端a更新MySQL完成，然后释放锁lock。（此时lock正在被客户端b用着呢）。

这种场景下，锁过期了被释放会被其他的客户端加锁成功，然后客户端a成功更新MySQL后又会去释放客户端b的锁。

总结来说这种场景存在2个问题：

设置的过期时间不合理：我还没操作完你就让锁过期了。导致这种情况的原因有很多，单单增加锁的过期时间并不能完全解决问题。因为网络状况、代码操作逻辑异常都影响到过期时间。
释放了别的进程锁：最后一步客户端a释放了别的客户端的锁，这种情况是不应该发生的。解决方法如下。

如何避免释放了别的进程锁

解决方法简单，在获取到锁时，写入唯一标识就可以了。比如说线程ID。

127.0.0.1:6379> set lock {thread_id} ex 5 nx
OK
复制代码

当要释放锁的时候，先判断一下锁的唯一标识，这样就可以避免释放别的进程锁。

redis_client.del('lock') if redis_client.get('lock') == {thread_id}
复制代码

但上述命令是分2步走的（查询+删除），为了保证原子性，我们可以用Lua脚本来执行上述命令。脚本可以这样写：

if redis.call("GET", KEYS[1]) == ARGV[1]
then
	return redis.call("DEL", KEYS[1])
else
	return 0
end
复制代码

调用脚本命令就是：redis-cli --eval lua.script lock, {thread_id}。

备注：Redis使用lua脚本的语法是：

redis-cli --eval {lua_path} KEYS[1] KEYS[2]... , ARGV[1] ARGV[2]...

--eval：  		执行lua脚本的命令
{lua_path}： 		lua脚本的路径
KEYS[1] KEYS[2]：       lua脚本中要操作的redis键，我们可以在lua脚本中用KEYS[1]，KEYS[2]，KEYS[3]指定多个
ARGV[1] ARGV[2]：	传入到lua脚本的参数，在脚本中用ARGV[1]，ARGV[2]...来获取。
复制代码

这样一来，Redis分布式锁的实现，除了上述过期时间不好把握外，基本能满足要求。

我们使用Redis做分布式锁的步骤可总结为：