Redis分布式锁的实现方式

前言

分布式锁通常有3中实现方式：

1. 数据库乐观锁；
2. 基于Redis的分布式锁；
3. 基于ZooKeeper的分布式锁。

如下将详细介绍如何正确地实现Redis分布式锁。

---

可靠性

首先，为了确保分布式锁的可用，咱们至少要确保锁的实现的同时，要知足如下四个条件：

• 互斥性。在任意时刻，只有一个客户端持有锁。
• 不会发生死锁。即便一个客户端在持有锁的期间发生崩溃而没有主动释放锁，也能保证后续其余客户端能加锁。
• 具备容错性。只要大部分的 Redis 节点正常运行，客户端就能够加锁和解锁。
• 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端本身不能把别人加的锁给解了。

---

 代码实现

　组件依赖

　　首先咱们经过 Maven 引入 Jedis 开源组件，在 pom.xml 文件加入如下代码：

1 <dependency>
2     <groupId>redis.clientsgroupId</groupId>
3     <artifactId>jedisartifactId</artifactId>
4     <version>2.9.0version</version>
5 </dependency>

　加锁代码

　　先放代码，后面再解释为何这样实现：

 1 public class RedisTool {
 2 
 3     private static final String LOCK_SUCCESS = "OK";
 4     private static final String SET_IF_NOT_EXIST = "NX";
 5     private static final String SET_WITH_EXPIRE_TIME = "PX";
 6     /**
 7      * 尝试获取分布式锁
 8      * @param jedis Redis客户端
 9      * @param lockKey 锁
10     * @param requestId 请求标识
11     * @param expireTime 超期时间
12     * @return 是否获取成功
13     */
14     public static boolean tryGetDistributedLock(Jedis jedis, 
15                     String lockKey,String requestId, int expireTime) {
16 
17         String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, 
18                         SET_WITH_EXPIRE_TIME, expireTime);
19 
20         if (LOCK_SUCCESS.equals(result)) {
21             return true;
22         }
23         return false;
24     }
25 }

能够看到，加锁就一行代码：

1 jedis.set(String key, String value, String nxxx, String expx, int time);

这个 set( ) 方法一共5个形参：

　　第一个是 key，咱们使用 key来当锁，由于 key 是惟一的。

　　第二个是value，入参是 requestId，不少人不明白，有 key 做为锁不就够了吗，为什么还要用到value？

　　由于咱们上面讲到的可靠性里，分布式锁要知足第4个条件：解铃还须系铃人，经过给 value 赋值为 requestId，咱们就知道这把锁是哪一个请求加的，在解锁的时候能够有依据。

　　requestId 可使用UUID.random().toString() 方法生成。

　　第三个事nxxx，这个参数 咱们填的是NX，意识 set if not exist，即当 key 不存在时，咱们进行 set 操做；若 key 已经存在，则不作任何操做；

　　第四个是expx，这个参数咱们传的是PX，意思是咱们要给这个 key 加一个过时的设置，具体时间由第五个参数决定；

　　第五个是time，于第四个参数相呼应，表明 key 的过时时间。

总的来讲，执行上面的 set() 方法就只有两种结果：

1. 当前没有锁（key不存），那么就进行加锁操做，并对锁设置个有效时间，同时 value 表示加锁的客户；
2. 已经存在锁，不作任何操做。

细心查看就会发现，咱们加锁的代码知足可靠性里面描述的三个条件。

　　首先，set() 加入了 NX 参数，能够保证若是已有 key 存在，则函数不会调用成功，也就是只有一个客户端能持有锁，知足互斥性。

　　其次，因为咱们对锁设置了过时时间，即便锁的持有者后续发生崩溃而没有解锁，锁也会由于到了过时时间而自动解锁（即key被删除），不会发生死锁。

　　最后，由于咱们将 value 赋值 requestId，表明加锁的客户标识，那么在客户端解锁时就能够进行校验是不是同一个客户端，即解铃还须系铃人。

　　因为咱们只考虑 Redis 单机部署的场景，因此容错性暂不考虑。

　错误示例一

　　比较常见的错误示例就是使用 jedis.setnx() 和 jedis.expire() 组合实现加锁。代码以下：

1 public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) {
2 
3     Long result = jedis.setnx(lockKey, requestId);
4     if (result == 1) {
5         // 若在这里程序忽然崩溃，则没法设置过时时间，将发生死锁
6         jedis.expire(lockKey, expireTime);
7     }
8 }

　　setnx() 方法的做用就是 set if not exist，expire() 方法就是给锁加一个过时时间。

　　咋一看好像和前面的 set() 方法结果同样，然而因为这是两条 Redis 命令，不具备原子性，若是程序在执行完 setnx()以后忽然崩溃，致使没有设置过时时间，那么将会发生死锁。

　　网上之因此有人这么实现，是由于低版本的 Jedis 并不支持多参数的 set() 方法。

　错误示例二

　　这种错误示例就是比较难发现问题，并且实现也比较复杂。实现思路：使用 jedis.setnx( key, value) 命令实现加锁，其中 key 是锁，value 是锁的过时时间。

　　执行过程：

1. 经过 setnx( ) 方法蚕食加锁，若是当前锁不存在，返回加锁成功。
2. 若是锁已经存在，则获取锁的过时时间，和当前时间比较，若是锁已通过期，则设置新的过时时间，返回加锁成功。

　　代码以下：

 1 public static boolean wrongGetLock2(Jedis jedis, String lockKey, int expireTime) {
 2 
 3     long expires = System.currentTimeMillis() + expireTime;
 4     String expiresStr = String.valueOf(expires);
 5 
 6     // 若是当前锁不存在，返回加锁成功
 7     if (jedis.setnx(lockKey, expiresStr) == 1) {
 8         return true;
 9     }
10     // 若是锁存在，获取锁的过时时间
11     String currentValueStr = jedis.get(lockKey);
12     if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
13         // 锁已过时，获取上一个锁的过时时间，并设置如今锁的过时时间
14         String oldValueStr = jedis.getSet(lockKey, expiresStr);
15         if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
16         // 考虑多线程并发的状况，只有一个线程的设置值和当前值相同，它才有权利加锁
17             return true;
18         }
19     }
20     // 其余状况，一概返回加锁失败
21     return false;
22 }

　　这段代码的问题在哪里？

1. 因为是客户端本身生产过时时间，因此须要强制要求分布式下每一个客户端的时间必须同步。
2. 当锁过时的时候，若是多个客户同时执行 jedis.setnx(k, v) 方法，那么虽然只有一个客户端能够加锁，可是这个客户端的锁过时时间可能会被其余客户端覆盖。
3. 锁不具有拥有者标识，即任何客户端均可以解锁。

---

解锁代码

　正确姿式

　　先展现代码，再解释为何这样实现：

 1 public class RedisTool {
 2     private static final Long RELEASE_SUCCESS = 1L;
 3     /**
 4      * 释放分布式锁
 5      * @param jedis Redis客户端
 6      * @param lockKey 锁
 7      * @param requestId 请求标识
 8      * @return 是否释放成功
 9      */
10     public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {
11         String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
12         Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
13 
14         if (RELEASE_SUCCESS.equals(result)) {
15             return true;
16         }
17         return false;
18     }
19 }

　　能够看到，解锁只须要两行代码就能够搞定了。

　　第一行，写的是一个简单的 Lua 脚本代码；

　　第二行，咱们将 Lua 代码传到 jedis.eval( ) 方法里，并使参数 KEYS[1] 赋值为lockKey，ARGV[1] 赋值为 requestId，eval() 方法是将 Lua代码交给 Redis 服务端执行。

　　那么这段代码的功能是什么呢？

　　很简单，首先获取锁对应的 value 值，检查是否与 requestId 相等，若是相等则删除锁（解锁）。

　　那么为何要使用Lua语言来讲实现呢？

　　由于要确保上述操做是原子性的。关于非原子性会带来的问题，能够阅读【解锁代码 - 错误示例二】。

　　那么为何执行 eval() 方法能够确保原子性？

　　源于 Redis 的特性，下面是官网对 eval 命令的部分解释：简单来讲，就是在 eval 命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，而且直到 eval 命令执行完成，Redis 才会执行其余命令。

　错误示例一

　　最多见的解锁代码就是直接使用 jedis.del() 方法删除锁，这种不先判断锁的拥有者就直接解锁的方法，会致使任何客户端均可以随时进行解锁，即便这把锁不是它的。

1 public static void wrongReleaseLock1(Jedis jedis, String lockKey) {
2     jedis.del(lockKey);
3 }

　错误示例二

　　这种解锁代码咋一看也是没有问题的，与正确姿式差很少，惟一区别的是分红两条命令去执行。代码以下：

1 public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) {
2     // 判断加锁与解锁是否是同一个客户端
3     if (requestId.equals(jedis.get(lockKey))) {
4         // 若在此时，这把锁忽然不是这个客户端的，则会误解锁
5         jedis.del(lockKey);
6     }
7 }

　　如代码的注释，问题在于若是调用 jedis.del() 方法的时候，这把锁已经不属于当前客户端的时候，会解锁他人加的锁。

　　是否有这种场景？

　　固然有的。如客户端A加锁，一段时间后客户端A解锁，在执行 jedis.del() 方法以前，锁忽然过时了，此时客户端B尝试加锁成功，而后客户端A再执行 jedis.del() 方法，则会将客户端B的锁给解除。

---

总结

　　想要经过 Redis实现分布式锁并不难，只要保证能知足可靠性里的四个条件。

　　若是项目中Redis是多机部署，那么能够尝试使用 Redisson 实现分布式锁。