大家所推崇的Redis分散式锁真的就万无一失吗？ 点关注，不迷路；持续更新Java相关技术及资讯！！！
在单例项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] [NXXX]”这个命令。
从 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的复制是异步的。举例来说：
执行绪A在master节点拿到了锁。master节点在把A建立的key写入slave之前宕机了。slave变成了master节点。执行绪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之间就发生过一场争论。
关注、转发、评论头条号每天分享java 知识，私信回复“源代码”赠送Spring源代码分析、Dubbo、Redis、Netty、zookeeper、Spring cloud、分散式资料
