大家所推崇的Redis分布式锁真的就万无一失吗？

在单实例JVM中，常见的处理并发问题的方法有很多，比如synchronized关键字进行访问控制、volatile关键字、ReentrantLock等常用方法。但是在分布式环境中，上述方法却不能在跨JVM场景中用于处理并发问题，当业务场景需要对分布式环境中的并发问题进行处理时，需要使用分布式锁来实现。

分布式锁，是指在分布式的部署环境下，通过锁机制来让多客户端互斥的对共享资源进行访问。

目前比较常见的分布式锁实现方案有以下几种：

• 基于数据库，如MySQL
• 基于缓存，如Redis
• 基于Zookeeper、etcd等。

这里介绍一下如何使用缓存(Redis)实现分布式锁。

使用Redis实现分布式锁最简单的方案是使用命令SETNX。SETNX(SET if Not eXist)的使用方式为：SETNX key value，只在键key不存在的情况下，将键key的值设置为value，若键key存在，则SETNX不做任何动作。SETNX在设置成功时返回，设置失败时返回0。当要获取锁时，直接使用SETNX获取锁，当要释放锁时，使用DEL命令删除掉对应的键key即可。

上面这种方案有一个致命问题，就是某个线程在获取锁之后由于某些异常因素(比如宕机)而不能正常的执行解锁操作，那么这个锁就永远释放不掉了。为此，我们可以为这个锁加上一个超时时间。第一时间我们会联想到Redis的EXPIRE命令(EXPIRE key seconds)。但是这里我们不能使用EXPIRE来实现分布式锁，因为它与SETNX一起是两个操作，在这两个操作之间可能会发生异常，从而还是达不到预期的结果，示例如下：

// STEP 1 
SETNX key value 
// 若在这里（STEP1和STEP2之间）程序突然崩溃，则无法设置过期时间，将有可能无法释放锁 
// STEP 2 
EXPIRE key expireTime 

对此，正确的姿势应该是使用“SET key value [EX seconds] [PX milliseconds] [NX|XX]”这个命令。

从 Redis 2.6.12 版本开始， SET 命令的行为可以通过一系列参数来修改：

• 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 ： 只在键已经存在时， 才对键进行设置操作。

举例，我们需要创建一个分布式锁，并且设置过期时间为10s，那么可以执行以下命令：

SET lockKey lockValue EX 10 NX 
或者 
SET lockKey lockValue PX 10000 NX 

注意EX和PX不能同时使用，否则会报错：ERR syntax error。

解锁的时候还是使用DEL命令来解锁。

修改之后的方案看上去很完美，但实际上还是会有问题。试想一下，某线程A获取了锁并且设置了过期时间为10s，然后在执行业务逻辑的时候耗费了15s，此时线程A获取的锁早已被Redis的过期机制自动释放了。在线程A获取锁并经过10s之后，改锁可能已经被其它线程获取到了。当线程A执行完业务逻辑准备解锁(DEL key)的时候，有可能删除掉的是其它线程已经获取到的锁。

所以最好的方式是在解锁时判断锁是否是自己的。我们可以在设置key的时候将value设置为一个唯一值uniqueValue(可以是随机值、UUID、或者机器号+线程号的组合、签名等)。当解锁时，也就是删除key的时候先判断一下key对应的value是否等于先前设置的值，如果相等才能删除key，伪代码示例如下：

if uniqueKey == GET(key) { 
    DEL key 
} 

这里我们一眼就可以看出问题来：GET和DEL是两个分开的操作，在GET执行之后且在DEL执行之前的间隙是可能会发生异常的。如果我们只要保证解锁的代码是原子性的就能解决问题了。这里我们引入了一种新的方式，就是 Lua 脚本，示例如下：

if redis.call("get",KEYS[1]) == ARGV[1] then 
 return redis.call("del",KEYS[1]) 
else 
 return 0 
end 

其中ARGV[1]表示设置key时指定的唯一值。

由于Lua脚本的原子性，在Redis执行该脚本的过程中，其他客户端的命令都需要等待该Lua脚本执行完才能执行。

下面我们使用Jedis来演示一下获取锁和解锁的实现，具体如下：

public boolean lock(String lockKey, String uniqueValue, int seconds){ 
 SetParams params = new SetParams(); 
 params.nx().ex(seconds); 
 String result = jedis.set(lockKey, uniqueValue, params); 
 if ("OK".equals(result)) { 
 return true; 
 } 
 return false; 
} 
public boolean unlock(String lockKey, String uniqueValue){ 
 String script = "if redis.call('get', KEYS[1]) == ARGV[1] " + 
 "then return redis.call('del', KEYS[1]) else return 0 end"; 
 Object result = jedis.eval(script,  
 Collections.singletonList(lockKey),  
 Collections.singletonList(uniqueValue)); 
 if (result.equals(1)) { 
 return true; 
 } 
 return false; 
} 

如此就万无一失了吗?显然不是!

表面来看，这个方法似乎很管用，但是这里存在一个问题：在我们的系统架构里存在一个单点故障，如果Redis的master节点宕机了怎么办呢?有人可能会说：加一个slave节点!在master宕机时用slave就行了!

但是其实这个方案明显是不可行的，因为Redis的复制是异步的。举例来说：

1. 线程A在master节点拿到了锁。
2. master节点在把A创建的key写入slave之前宕机了。
3. slave变成了master节点。
4. 线程B也得到了和A还持有的相同的锁。(因为原来的slave里面还没有A持有锁的信息)

当然，在某些场景下这个方案没有什么问题，比如业务模型允许同时持有锁的情况，那么使用这种方案也未尝不可。

举例说明，某个服务有2个服务实例：A和B，初始情况下A获取了锁然后对资源进行操作(可以假设这个操作很耗费资源)，B没有获取到锁而不执行任何操作，此时B可以看做是A的热备。当A出现异常时，B可以“转正”。当锁出现异常时，比如Redis master宕机，那么B可能会同时持有锁并且对资源进行操作，如果操作的结果是幂等的(或者其它情况)，那么也可以使用这种方案。这里引入分布式锁可以让服务在正常情况下避免重复计算而造成资源的浪费。

为了应对这种情况，antriez提出了Redlock算法。Redlock算法的主要思想是：假设我们有N个Redis master节点，这些节点都是完全独立的，我们可以运用前面的方案来对前面单个的Redis master节点来获取锁和解锁，如果我们总体上能在合理的范围内或者N/2+1个锁，那么我们就可以认为成功获得了锁，反之则没有获取锁(可类比Quorum模型)。虽然Redlock的原理很好理解，但是其内部的实现细节很是复杂，要考虑很多因素

Redlock算法也并非是“银弹”，他除了条件有点苛刻外，其算法本身也被质疑。关于Redis分布式锁的安全性问题，在分布式系统专家Martin Kleppmann和Redis的作者antirez之间就发生过一场争论。