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

前言

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

单机锁

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

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

对分布式锁的要求

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

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

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

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

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

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

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

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

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

如上面图例：

1. 客户端a在要更新mysql资源时，先向Redis分布式锁申请加锁，也就是执行SETNX lock 1,加锁成功。
2. 客户端b也申请加锁，但被客户端a已经加锁了，因此加锁失败，不往下执行。
3. 客户端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
复制代码

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

1. 客户端a申请锁lock成功，然后更新MySQL去了；
2. 因为mysql连接问题，客户端a更新操作，超过了设定的过期时间，于是lock被自动释放了；
3. 客户端b这时申请lock成功，也开始更新MySQL了；
4. 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做分布式锁的步骤可总结为：

1. 获取锁： SET lock {唯一标识} EX {过期时间} NX
2. 更新操作：比如说更新mysql资源。
3. 释放锁资源：用lua脚本判断锁是不是自己加的，是的话再释放锁（ DEL lock ）

锁过期时间怎么设定才好

锁的过期时间，如果设置的不合理，自动过期的可能性就会大大增加。

在解决这个问题上，Java中有个SDK叫做Redisson。 它在使用分布式锁时，加锁的同时有开启一个看门狗线程。这个线程会定时去检查锁的过期时间，若锁快过期了，而更新操作还没完成，看门狗会延长锁的过期时间，也就是重新设置过期时间。

如果不使用Java语言，我们也可借鉴Redisson的做法，在加锁的同时开启一个守护线程。

Redis单个节点的分布式锁实现就说到这，接下来看看Redis多个节点该图和实现分布式锁。

Redis多个节点的分布式锁（Redlock方案）

Redis的使用，往往不是单机用，用主从集群的模式部署最多。而在该模式下，分布式锁的使用会带来新的问题。比如下面场景：

1. 客户端a在主库上执行加锁命令（SET）成功。
2. 主库发生故障，而步骤1的SET命令还没来得及同步到从库上。
3. 主从切换后，原从库被推举为主库，锁就在节点上丢失了。

为解决这个问题，Redis提供了Redlock方案。要使用Redlock方案，要有2个前提：

• 只部署主库，不部署从库及哨兵。
• 主库部署多个，官方推荐>=5个。

Redlock的使用流程大致如下：

1. 客户端获取到当前的时间戳。
2. 客户端按顺序向部署的N个Redis实例执行加锁操作。在设定时间内，不管加锁成功还是失败，都会继续向下一个实例申请加锁操作。
3. 若加锁成功的实例个数>= (N/2) + 1，并且加锁的总耗时要<锁设定的过期时间，Redlock就判断加锁成功，反之就是加锁失败。
4. 加锁成功了，就继续往下操作，比如操作MySQL资源；若加锁失败，则会向所有节点发起锁释放的操作请求。

由上面流程可见，Redlock的设计规则就是：

• 客户端要在所有实例上申请加锁，只有保证大多数节点加锁成功了才判定为加锁成功。
• 加锁的总耗时要 < 锁设定的过期时间。
• 释放锁的时候，要向所有节点发起锁释放的请求，不管之前加锁是否成功。

Redlock的应用，可以提升Redis分布式锁的可靠性。但是，Redlock并非没有缺陷和漏洞。

业界的分布式系统专家Martin就曾质疑过Redlock的设计方案，主要是提到了Redlock的效率和正确性。效率不用多说，给全部节点发起加锁的规则就会影响效率。

正确性方面，因为分布式系统中，时钟偏移的情况无法避免，运维成本很高。

总的来说，Redlock设计繁杂，还得部署多个节点，运维难度大。我们在实现Redis分布式锁的时候，用主从+哨兵的集群方案就基本够用了。

小结

本文讲了Redis是如何实现分布式锁的，单个Redis节点和多节点的实现和问题是不一样的。

在使用的时候，如果追求效率，单节点的分布式锁就够用了，缺点就是过期时间不好把握，因为网络情况不好预估；如果要保证正确性，Redlock也是可以考虑的，但运维方面的问题需要提前考虑好。