分布式锁之Redis实现（最终版）

我们接着上篇继续了解redis实现分布式锁的相关问题，先来解释几个问题
1.为什么不直接使用expire设置超时时间，而将时间的毫秒数其作为value放在redis中？
如下面的方式，把超时的交给redis处理：

if (conn.setnx(lockKey) == 1) {
                    conn.expire(lockKey, lockExpire);

这种方式貌似没什么问题，但是假如在setnx后，redis崩溃了，expire就没有执行，结果就是死锁了。锁永远不会超时。

2.多台机器同时向redis发出setnx请求，会不会存在并发问题?

其实redis本事是不会存在并发问题的，因为他是单进程的，再多的command都是one by one执行的。我们使用的时候，可能会出现的并发问题都是多个命令组才会出现，比如get和set这一对。

加锁

上篇文章加锁代码实现思路：使用jedis.setnx()命令实现加锁，其中key是锁，value是锁的过期时间。执行过程：

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

代码如下：

public class SimpleRedisLock {

    public static long hold_time = 3000;

    public static ThreadLocal<String> expireHolder = new ThreadLocal<>();

    public static void acquire(String lock){
        //1.先尝试用setnx命令获取锁,key为参数lock,值为当前时间+要持有锁的时间hold_time
        while(jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time)) == 0){
            //2.如果获取失败,先watch lock key
            jedis.watch(lock);
            //3.获取当前超时时间
            String expireTime = jedis.get(lock);
            if(expireTime != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
                //4.如果超时时间小于当前时间,开事务准备更新lock值
                Transaction transaction = jedis.multi();
                Response<String> response = transaction.getSet(lock, String.valueOf(System.currentTimeMillis() + hold_time));
                //5.步骤2设置了watch,如果lock的值被其他线程修改,不是执行事务中的命令
                if(transaction.exec() != null){
                    String oldExpire = response.get();
                    if(oldExpire != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
                        //6.如果setget命令返回的值依然是过期时间,认为获取锁成功(加了watch之后,这里返回的应该一直是超时时间)
                        break;
                    }
                }
            }else{
                //如果key未超时,解除watch
                jedis.unwatch();
            }
        }
        //设置客户端超时时间
        expireHolder.set(jedis.get(lock));
    }

    public static void release(String lock){
        //比较客户端超时时间与lock值,判断是否还由自己持有锁
        if(jedis.get(lock).equals(expireHolder.get())){
            jedis.del(lock);
        }
        jedis.close();
    }

}

这严格来说是一种错误示例而且实现也比较复杂。那么这段代码问题在哪里？

1. 由于是客户端自己生成过期时间，所以需要强制要求分布式下每个客户端的时间必须同步。
2. 当锁过期的时候，如果多个客户端同时执行jedis.getSet()方法，那么虽然最终只有一个客户端可以加锁，但是这个客户端的锁的过期时间可能被其他客户端覆盖。
3. 锁不具备拥有者标识，即任何客户端都可以解锁。
   更为严谨的做法如下：

public class Redis {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 客户端标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}

可以看到，我们加锁就一行代码：jedis.set(String key, String value, String nxxx, String expx, int time)，这个set()方法一共有五个形参：

• 第一个为key，我们使用key来当锁，因为key是唯一的。
• 第二个为value，我们传的是requestId，requestId是客户端的唯一标志。
• 第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；
• 第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。
• 第五个为time，与第四个参数相呼应，代表key的过期时间。

可以看到上面的set()方法，通过requestId解决了分布式下不同客户端时间不统一问题，通过超期时间解决了多次getset覆盖问题，通过解锁时判断requestId解决了任何客户端都可以解锁问题。

解锁

常规解锁方式

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

}

这种方式的问题在于如果调用jedis.del()方法的时候，这把锁已经不属于当前客户端的时候会解除他人加的锁。那么是否真的有这种场景？答案是肯定的，

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

所以我们应该注意并发的情况下两行代码之间有很高几率出现其它线程乱入的问题
正确解锁方式

public class RedisTool {

    private static final Long RELEASE_SUCCESS = 1L;

    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

        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(requestId));

        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}

可以看到，我们解锁只需要两行代码就搞定了！第一行代码，我们写了一个简单的Lua脚本代码,第二行代码，我们将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

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

首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）。那么为什么要使用Lua语言来实现呢？因为要确保上述操作是原子性的。

关于非原子性会带来什么问题，可以参考上面的错误示例，那么为什么执行eval()方法可以确保原子性，源于Redis的特性，下面是官网对eval命令的部分解释：

Redis分布式锁的正确实现方式_01.png

简单来说，就是在eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。

总结

根据上述的分析的两个问题，我们看到了并发过程中，两行代码之间特别容易出现其它线程乱入影响一致性，所以尽量使用一行原子性的操作来保证锁的实现。