聊聊 Redis 分布式锁

0. 前言

Redis 是日常开发中经常使用到的中间件，以优秀的性能著称。但是 Redis 分布式锁可以说是饱受争议，很多人认为 Redis 并不适合作为分布式锁。它确实存在着一些问题，今天我准备聊一聊 Redis 分布式锁如何实现、有什么问题、该如何解决以及它的进阶版本红锁（Red Lock）解决了哪些问题，又带来了哪些新的问题

1. Redis 分布式锁的标准实现方式

我们以一个 Redis 单实例为例

1.1. 上锁原理

Redis 通过 SET key value NX 命令实现锁的互斥机制。SETNX 含义为（SET if Not eXists），只有在 key 不存在时，才能 SET 成功

完整的上锁命令如下所示

# NX 代表 key 不存在才能 SET 成功，PX 指定 key 的过期时间
SET resource_name client_id NX PX 30000

key 的过期时间，就是锁的持有时间（或者说释放时间）

client_id 可以是任何随机的唯一值（例如 UUID），它存在的意义是用于解锁。只有 client_id 匹配时，才能解锁（保证只有持有锁的客户端才可以解锁，防止其他客户端错误的解锁）

1.2. 解锁原理

解锁本质上就是删除 key，或者 key 过期。

主动解锁通常使用 lua 脚本进行，因为我们希望原子性的完成判断和删除逻辑

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

2. Redis 分布式锁的问题

通过上一章节，我们已经了解到了，如何利用 Redis 机制实现一个分布式锁，现在我们要更深入的讨论下 Redis 是否可靠

2.1. Redis 锁未设置过期时间，导致死锁

场景：我使用 SET key client_id NX 持有了一个锁，但是我并没有设置过期时间。此时我的应用进程突然挂了，并没有来得及进行解锁操作。此时任何客户端都无法再持有这个锁了，必须得人工介入删除掉这个 key，业务才能继续流转

对于这个场景有什么好的解决办法呢

Redission 提供了一个很好的解决方案。Redission 提供了一个“看门狗”机制

如果用户在申请锁的时候没有指定锁的释放时间，此时 Redission 会为锁指定一个 30 秒的过期时间。在锁释放之前，再额外使用一个线程不断地延长 key 的过期时间。这样就能保证即使应用进程意外挂掉，也不会出现“死锁”

Redission 使用了 Netty API 来实现“看门狗”，这里为了方便大家理解，我使用 Java API 做一个简单的示例以供参考

public class WatchDogExample {
    /**
     * 定义线程池
     */
    static ScheduledExecutorService scheduled = new ScheduledThreadPoolExecutor(8, new ThreadFactory() {
        private final AtomicInteger threadNumber = new AtomicInteger(1);

        @Override
        public Thread newThread(Runnable r) {
            Thread thread = new Thread(r, "watchDog-" + threadNumber.getAndIncrement());
            // 设置为守护线程，防止主线程意外挂掉，看门狗线程依旧在执行
            thread.setDaemon(true);
            return thread;
        }
    });

    public static void main(String[] args) {
        // 模拟获得锁 tryLock()
        // SET NX 命令，过期时间为 30s
        System.out.println("SET KEY VALUE NX EX 30");

        // 向线程池提交 KEY 续期任务
        ScheduledFuture future = scheduled.scheduleAtFixedRate(() -> {
            if (Thread.currentThread().isInterrupted()) {
                return;
            }
            // EXPIRE 命令续期key 30s
            System.out.println("EXPIRE KEY 30");
        }, 10, 10, TimeUnit.SECONDS);


        try {
            // 模拟业务流程
            Thread.sleep(20000);
        } catch (InterruptedException e) {
        }

        // 解锁 unlock。停止任务调度 & 删除key
        future.cancel(true);
        System.out.println("DEL KEY");

        try {
            // 保证 main 线程不停止。如果 main 线程停止，守护线程将结束
            new CountDownLatch(1).await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

}

2.2. Redis 锁过期了，但是应用进程还在操作共享资源

这种情况，我的理解是，如果你明确指定了锁的过期时间，那么你就必须保证在这个时间内完成对共享资源的操作。如果你无法保证，就使用 2.1 的方式，不指定过期时间

2.3. 如何实现锁的等待

其实 SETNX 实现的效果仅是一个 tryLock，以 Java 中常用的锁作为参考。通常来说我们如果无法立即获得锁，是可以选择等待锁释放后，继续尝试获取锁。那么 Redis 分布式锁可以实现这一效果吗？

当然可以了，参考 Redission 的实现，我们可以利用 Redis 的发布订阅来实现锁的等待，思路如下

a. 尝试获取锁
b. 获取锁失败，订阅锁释放消息，线程进入等待状态
c. 其它客户端解锁，发布锁释放消息
d. 接受到锁释放消息，回到步骤 a

感兴趣的同学，可以自行阅读下 Redission 源码

图片来源小米技术团队

2.4. Redis 锁是不可重入锁？

首先我们要明白，可重入锁有什么意义？

1. Java synchronized、ReentrantLock 都是可重入锁。可重入锁，即同一个线程可以多次获取同一个锁，其意义在于防止代码出现死锁。

假设我们的 Redis 锁已经实现了 2.3 中提到的锁等待功能，此时我设置了锁的最大等待时间为 -1（无限等待），锁的持有时间也是 -1。我在编码的时候，没有注意，多次获取了相同的锁。由于是无限等待，我的代码在第二次获取锁时，就会出现死锁，永远的卡在那里。

2. 对于 Redis 锁来说，可重入也可以代表锁续期

在理解了可重入锁的意义之后，我们该如何让 Redis 分布式锁支持重入呢？同样参考 Redission 即可

Redission 使用 Redis Hash 结构，存储结构为 lock_key，client_id，重入次数

     RFuture tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand command) {
        internalLockLeaseTime = unit.toMillis(leaseTime);

        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]); " +
                      // 竞争锁成功 返回null
                      "return nil; " +
                  "end; " +
                   // 如果锁已经被当前线程获取
                  "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                       // 重入次数加1
                      "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                      "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                      "return nil; " +
                  "end; " +
                  // 锁被其他线程获取，返回锁的过期时间
                  "return redis.call('pttl', KEYS[1]);",

                    // 下面三个参数分别为 KEYS[1], ARGV[1], ARGV[2]
                    // 即锁的name，锁释放时间，当前线程唯一标识
                    Collections.