分布式学习笔记五：redis分步式锁

前言

分布式锁一般有三种实现方式：1. 数据库乐观锁；2. 基于Redis的分布式锁；3. 基于ZooKeeper的分布式锁。本篇博客将介绍第二种方式，基于Redis实现分布式锁。虽然网上已经有各种介绍Redis分布式锁实现的博客，然而他们的实现却有着各种各样的问题，本篇博客将详细介绍如何正确地实现Redis分布式锁。
需满足如下条件：
-互斥性。在任意时刻，只有一个客户端能持有锁。 
- 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。 
- 具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。 
- 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。

加锁

正确方式：

首先我们要通过Maven引入Jedis开源组件，在pom.xml文件加入下面的代码：

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>

注：如果在springBoot，可以使用springBoot自己封装的redisTemplate.自行百度。

加锁代码：

public class RedisTool {

    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 请求标识 （可通过UUID生成唯一标识）
     * @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;
    }
}

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

public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) {

    Long result = jedis.setnx(lockKey, requestId);
    if (result == 1) {
        // 若在这里程序突然崩溃，则无法设置过期时间，将发生死锁
        jedis.expire(lockKey, expireTime);
    }
}

setnx()方法作用就是SET IF NOT EXIST，expire()方法就是给锁加一个过期时间。乍一看好像和前面的set()方法结果一样，然而由于这是两条Redis命令，不具有原子性，如果程序在执行完setnx()之后突然崩溃，导致锁没有设置过期时间。那么将会发生死锁。网上之所以有人这样实现，是因为低版本的jedis并不支持多参数的set()方法。

解锁代码

正确方式：

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命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。

错误示例1：

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

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

错误示例2：

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的锁给解除了。
 

springBoot中实现

首先需要引入redisson

        <!--redis-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
        <!--redis分布式锁-->
        <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson</artifactId>
            <version>3.4.3</version>
        </dependency>

生成Redisson的bean 
支持单机，主从，哨兵，集群等模式，具体方式请参考https://github.com/redisson/redisson/wiki/2.-%E9%85%8D%E7%BD%AE%E6%96%B9%E6%B3%95，这里只演示集群环境。

 @Bean
    Redisson redissonSentinel() {
        Config config = new Config();
        config.useClusterServers()
                .setScanInterval(2000) // 集群状态扫描间隔时间，单位是毫秒
                //可以用"rediss://"来启用SSL连接
                .addNodeAddress("redis://10.82.0.102:7000")
                .addNodeAddress("redis://10.82.0.102:7001")
                .addNodeAddress("redis://10.82.0.102:7002")
                .addNodeAddress("redis://10.82.0.102:7003")
                .addNodeAddress("redis://10.82.0.102:7004")
                .addNodeAddress("redis://10.82.0.102:7005");
        return (Redisson)Redisson.create(config);
    }

这里只是简单展示，配置更加详细的，参考上面网站。

简单使用实现：   

@Autowired
    Redisson redisson;


    RLock lock = redisson.getLock(key);
    lock.lock(60, TimeUnit.SECONDS); //设置60秒自动释放锁  （默认是30秒自动过期）

    //执行的业务代码

    lock.unlock(); //释放锁

关于Redisson 更加全面详细锁的情况，前往：https://github.com/redisson/redisson/wiki/8.-%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81%E5%92%8C%E5%90%8C%E6%AD%A5%E5%99%A8

就这样通过redisson就实现redis分布式锁，内部帮我们解决了上一篇提到的注意的地方。使用redisson更加体现一切皆对象，我们不需要知道内部如何实现，只需知道如何使用就行。当然作为一个积极进取的程序员还是要了解底层实现的。

原理简介

Redisson 分布式锁实现分析

java.util.concurrent.locks 中包含了 JDK 提供的在多线程情况下对共享资源的访问控制的一系列工具，它们可以帮助我们解决进程内多线程并发时的数据一致性问题。

但是在分布式系统中，JDK 原生的并发锁工具在一些场景就无法满足我们的要求了，这就是为什么要使用分布式锁。我总结了一句话，分布式锁是用于解决分布式系统中操作共享资源时的数据一致性问题。

设计分布式锁要注意的问题

互斥

分布式系统中运行着多个节点，必须确保在同一时刻只能有一个节点的一个线程获得锁，这是最基本的一点。

死锁

分布式系统中，可能产生死锁的情况要相对复杂一些。分布式系统是处在复杂网络环境中的，当一个节点获取到锁，如果它在释放锁之前挂掉了，或者因网络故障无法执行释放锁的命令，都会导致其他节点无法申请到锁。

因此分布式锁有必要设置时效，确保在未来的一定时间内，无论获得锁的节点发生了什么问题，最终锁都能被释放掉。

性能

对于访问量大的共享资源，如果针对其获取锁时造成长时间的等待，导致大量节点阻塞，是绝对不能接受的。

所以设计分布式锁时要能够掌握锁持有者的动态，若判断锁持有者处于不活动状态，要能够强制释放其持有的锁。
此外，排队等待锁的节点如果不知道锁何时会被释放，则只能隔一段时间尝试获取一次锁，这样无法保证资源的高效利用，因此当锁释放时，要能够通知等待队列，使一个等待节点能够立刻获得锁。

重入

考虑到一些应用场景和资源的高效利用，锁要设计成可重入的，就像 JDK 中的 ReentrantLock 一样，同一个线程可以重复拿到同一个资源的锁。

RedissonLock 实现解读

本文中 Redisson 的代码版本为 2.2.17-SNAPSHOT。

这里以 lock() 方法为例，其他一系列方法与其核心实现基本一致。

先来看 lock() 的基本用法

RLock lock = redisson.getLock("foobar"); // 1.获得锁对象实例
lock.lock(); // 2.获取分布式锁
try {
    // do sth.
} finally {
    lock.unlock(); // 3.释放锁
}

1. 通过 RedissonClient 的 getLock() 方法取得一个 RLock 实例。
2. lock() 方法尝试获取锁，如果成功获得锁，则继续往下执行，否则等待锁被释放，然后再继续尝试获取锁，直到成功获得锁。
3. unlock() 方法释放获得的锁，并通知等待的节点锁已释放。

下面来看看 RedissonLock 的具体实现

org.redisson.Redisson#getLock()

@Override
public RLock getLock(String name) {
  return new RedissonLock(commandExecutor, name, id);
}

这里的 RLock 是继承自 java.util.concurrent.locks.Lock 的一个 interface，getLock 返回的实际上是其实现类 RedissonLock 的实例。

来看看构造 RedissonLock 的参数

• commandExecutor: 与 Redis 节点通信并发送指令的真正实现。需要说明一下，Redisson 缺省的 CommandExecutor 实现是通过 eval 命令来执行 Lua 脚本，所以要求 Redis 的版本必须为 2.6 或以上，否则你可能要自己来实现 CommandExecutor。关于 Redisson 的 CommandExecutor 以后会专门解读，所以本次就不多说了。
• name: 锁的全局名称，例如上面代码中的 "foobar"，具体业务中通常可能使用共享资源的唯一标识作为该名称。
• id: Redisson 客户端唯一标识，实际上就是一个 UUID.randomUUID()。

org.redisson.RedissonLock#lock()

此处略过前面几个方法的层层调用，直接看最核心部分的方法 lockInterruptibly()，该方法在 RLock 中声明，支持对获取锁的线程进行中断操作。在直接使用 lock() 方法获取锁时，最后实际执行的是 lockInterruptibly(-1, null)。

@Override
public void lockInterruptibly(long leaseTime, TimeUnit unit) throws InterruptedException {
    // 1.尝试获取锁
    Long ttl = tryAcquire(leaseTime, unit);
    // 2.获得锁成功
    if (ttl == null) {
        return;
    }
    // 3.等待锁释放，并订阅锁
    long threadId = Thread.currentThread().getId();
    Future<RedissonLockEntry> future = subscribe(threadId);
    get(future);

    try {
        while (true) {
            // 4.重试获取锁
            ttl = tryAcquire(leaseTime, unit);
            // 5.成功获得锁
            if (ttl == null) {
                break;
            }
            // 6.等待锁释放
            if (ttl >= 0) {
                getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
            } else {
                getEntry(threadId).getLatch().acquire();
            }
        }
    } finally {
        // 7.取消订阅
        unsubscribe(future, threadId);
    }
}

1. 首先尝试获取锁，具体代码下面再看，返回结果是已存在的锁的剩余存活时间，为 null 则说明没有已存在的锁并成功获得锁。
2. 如果获得锁则结束流程，回去执行业务逻辑。
3. 如果没有获得锁，则需等待锁被释放，并通过 Redis 的 channel 订阅锁释放的消息，这里的具体实现本文也不深入，只是简单提一下 Redisson 在执行 Redis 命令时提供了同步和异步的两种实现，但实际上同步的实现都是基于异步的，具体做法是使用 Netty 中的异步工具 Future 和 FutureListener 结合 JDK 中的 CountDownLatch 一起实现。
4. 订阅锁的释放消息成功后，进入一个不断重试获取锁的循环，循环中每次都先试着获取锁，并得到已存在的锁的剩余存活时间。
5. 如果在重试中拿到了锁，则结束循环，跳过第 6 步。
6. 如果锁当前是被占用的，那么等待释放锁的消息，具体实现使用了 JDK 并发的信号量工具 Semaphore 来阻塞线程，当锁释放并发布释放锁的消息后，信号量的 release() 方法会被调用，此时被信号量阻塞的等待队列中的一个线程就可以继续尝试获取锁了。
7. 在成功获得锁后，就没必要继续订阅锁的释放消息了，因此要取消对 Redis 上相应 channel 的订阅。

下面着重看看 tryAcquire() 方法的实现，

private Long tryAcquire(long leaseTime, TimeUnit unit) {
    // 1.将异步执行的结果以同步的形式返回
    return get(tryAcquireAsync(leaseTime, unit, Thread.currentThread().getId()));
}

private <T> Future<Long> tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId) {
    if (leaseTime != -1) {
        return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
    }
    // 2.用默认的锁超时时间去获取锁
    Future<Long> ttlRemainingFuture = tryLockInnerAsync(LOCK_EXPIRATION_INTERVAL_SECONDS,
                TimeUnit.SECONDS, threadId, RedisCommands.EVAL_LONG);
    ttlRemainingFuture.addListener(new FutureListener<Long>() {
        @Override
        public void operationComplete(Future<Long> future) throws Exception {
            if (!future.isSuccess()) {
                return;
            }
            Long ttlRemaining = future.getNow();
            // 成功获得锁
            if (ttlRemaining == null) {
                // 3.锁过期时间刷新任务调度
                scheduleExpirationRenewal();
            }
        }
    });
    return ttlRemainingFuture;
}

<T> Future<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId,
                RedisStrictCommand<T> command) {
    internalLockLeaseTime = unit.toMillis(leaseTime);
    // 3.使用 EVAL 命令执行 Lua 脚本获取锁
    return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
              "if (redis.call('exists', KEYS[1]) == 0) then " +
                  "redis.call('hset', KEYS[1], ARGV[2], 1); " +
                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                  "return nil; " +
              "end; " +
              "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                  "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                  "return nil; " +
              "end; " +
              "return redis.call('pttl', KEYS[1]);",
                Collections.<Object>singletonList(getName()), internalLockLeaseTime,
                        getLockName(threadId));
}

1. 上面说过 Redisson 实现的执行 Redis 命令都是异步的，但是它在异步的基础上提供了以同步的方式获得执行结果的封装。
2. 前面提到分布式锁要确保未来的一段时间内锁一定能够被释放，因此要对锁设置超时释放的时间，在我们没有指定该时间的情况下，Redisson 默认指定为30秒。
3. 在成功获取到锁的情况下，为了避免业务中对共享资源的操作还未完成，锁就被释放掉了，需要定期（锁失效时间的三分之一）刷新锁失效的时间，这里 Redisson 使用了 Netty 的 TimerTask、Timeout 工具来实现该任务调度。
4. 获取锁真正执行的命令，Redisson 使用 EVAL 命令执行上面的 Lua 脚本来完成获取锁的操作：
5. 如果通过 exists 命令发现当前 key 不存在，即锁没被占用，则执行 hset 写入 Hash 类型数据 key:全局锁名称（例如共享资源ID）, field:锁实例名称（Redisson客户端ID:线程ID）, value:1，并执行 pexpire 对该 key 设置失效时间，返回空值 nil，至此获取锁成功。
6. 如果通过 hexists 命令发现 Redis 中已经存在当前 key 和 field 的 Hash 数据，说明当前线程之前已经获取到锁，因为这里的锁是可重入的，则执行 hincrby 对当前 key field 的值加一，并重新设置失效时间，返回空值，至此重入获取锁成功。
7. 最后是锁已被占用的情况，即当前 key 已经存在，但是 Hash 中的 Field 与当前值不同，则执行 pttl 获取锁的剩余存活时间并返回，至此获取锁失败。

以上就是对 lock() 的解读，不过在实际业务中我们可能还会经常使用 tryLock()，虽然两者有一定差别，但核心部分的实现都是相同的，另外还有其他一些方法可以支持更多自定义参数，本文中就不一一详述了。

org.redisson.RedissonLock#unlock()

最后来看锁的释放，

@Override
public void unlock() {
    // 1.通过 EVAL 和 Lua 脚本执行 Redis 命令释放锁
    Boolean opStatus = commandExecutor.evalWrite(getName(), LongCodec.INSTANCE,
                    RedisCommands.EVAL_BOOLEAN,
                    "if (redis.call('exists', KEYS[1]) == 0) then " +
                        "redis.call('publish', KEYS[2], ARGV[1]); " +
                        "return 1; " +
                    "end;" +
                    "if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +
                        "return nil;" +
                    "end; " +
                    "local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +
                    "if (counter > 0) then " +
                        "redis.call('pexpire', KEYS[1], ARGV[2]); " +
                        "return 0; " +
                    "else " +
                        "redis.call('del', KEYS[1]); " +
                        "redis.call('publish', KEYS[2], ARGV[1]); " +
                        "return 1; "+
                    "end; " +
                    "return nil;",
                    Arrays.<Object>asList(getName(), getChannelName()), 
                            LockPubSub.unlockMessage, internalLockLeaseTime, 
                            getLockName(Thread.currentThread().getId()));
    // 2.非锁的持有者释放锁时抛出异常
    if (opStatus == null) {
        throw new IllegalMonitorStateException(
                "attempt to unlock lock, not locked by current thread by node id: "
                + id + " thread-id: " + Thread.currentThread().getId());
    }
    // 3.释放锁后取消刷新锁失效时间的调度任务
    if (opStatus) {
        cancelExpirationRenewal();
    }
}

1. 使用 EVAL 命令执行 Lua 脚本来释放锁：
2. key 不存在，说明锁已释放，直接执行 publish 命令发布释放锁消息并返回 1。
3. key 存在，但是 field 在 Hash 中不存在，说明自己不是锁持有者，无权释放锁，返回 nil。
4. 因为锁可重入，所以释放锁时不能把所有已获取的锁全都释放掉，一次只能释放一把锁，因此执行 hincrby 对锁的值减一。
5. 释放一把锁后，如果还有剩余的锁，则刷新锁的失效时间并返回 0；如果刚才释放的已经是最后一把锁，则执行 del 命令删除锁的 key，并发布锁释放消息，返回 1。
6. 上面执行结果返回 nil 的情况（即第2中情况），因为自己不是锁的持有者，不允许释放别人的锁，故抛出异常。
7. 执行结果返回 1 的情况，该锁的所有实例都已全部释放，所以不需要再刷新锁的失效时间。

总结

写了这么多，其实最主要的就是上面的两段 Lua 脚本，基于 Redis 的分布式锁的设计完全体现在其中，看完这两段脚本，再回顾一下前面的 设计分布式锁要注意的问题 就豁然开朗了。