Redis分布式锁问题与Redisson解决方案的探究

Seajunnn

已于 2022-10-08 17:32:25 修改

阅读量1.2k

点赞数

分类专栏： Redis 文章标签： redis 分布式数据库

于 2022-09-23 18:07:07 首次发布

本文链接：https://blog.csdn.net/xsjzn/article/details/127015896

版权

Redis 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Redis分布式锁问题与Redisson解决方案的探究

在字节实习的时候，用到了Redis分布式锁，因此记录下Redis分布式锁可能存在的问题，同时开源的Redisson的解决方案

基于 Redis 如何实现一个分布式锁？
Redis 分布式锁真的安全吗？

为什么需要分布式锁？

在开始讲分布式锁之前，有必要简单介绍一下，为什么需要分布式锁？

与分布式锁相对应的是「单机锁」，我们在写多线程程序时，避免同时操作一个共享变量产生数据问题，通常会使用一把锁来「互斥」，以保证共享变量的正确性，其使用范围是在「同一个进程」中。

如果换做是多个进程，需要同时操作一个共享资源，如何互斥呢？

例如，现在的业务应用通常都是微服务架构，或者是服务有多台实例，这也意味着一个应用会部署多个进程，那这多个进程如果需要修改 MySQL 中的同一行记录时，为了避免操作乱序导致数据错误，此时，我们就需要引入「分布式锁」来解决这个问题了。

分布式锁怎么实现？

想要实现分布式锁，必须要求 Redis 有**「互斥」的能力，我们可以使用 SETNX 命令，这个命令表示SET** if Not eXists，即如果 key 不存在，才会设置它的值，否则什么也不做。

两个客户端进程可以执行这个命令，达到互斥，就可以实现一个分布式锁。

客户端 1 申请加锁，加锁成功：

127.0.0.1:6379> SETNX lock 1
(integer) 1     // 客户端1，加锁成功

客户端 2 申请加锁，因为后到达，加锁失败：

127.0.0.1:6379> SETNX lock 1
(integer) 0     // 客户端2，加锁失败

此时，加锁成功的客户端，就可以去操作共享资源，例如，修改 MySQL 的某一行数据，或者调用一个 API 请求。

操作完成后，还要及时释放锁，给后来者让出操作共享资源的机会。如何释放锁呢？

也很简单，直接使用 DEL 命令删除这个 key 即可：

但是，它存在一格很大的问题，当客户端1拿到锁后，如果发生下面的场景，就会造成死锁

程序处理业务逻辑异常，没及时释放锁
进程挂了，没机会释放锁

这时，这个客户端就会一直占用这个锁，而其它客户端就「永远」拿不到这把锁了。

怎么解决这个问题呢？

如何避免死锁？

针对业务异常的逻辑，那么我们肯定首先想到是在程序控制抓住异常，然后释放锁，以java程序,以及Redisson客户端为例

 		// 创建锁对象 传入key 
        RLock redisLock = redissonClient.getLock("lock:order:" + userId);
        // 尝试获取锁
        boolean isLock = redisLock.tryLock();
        // 判断
        if (!isLock) {
            // 获取锁失败，直接返回失败或者重试
            return;
        }

        try {
           //执行业务逻辑
        } catch (Exception e) {
        	e.printStackTrace();
        } finally {
            // 释放锁
            redisLock.unlock();
        }

那么如果异常，没来得及catch住，并且释放锁应当怎么办呢？

对了，设置过期时间兜底，也就是一个租期

在 Redis 中实现时，就是给这个 key 设置一个「过期时间」。这里我们假设，操作共享资源的时间不会超过 10s，那么在加锁时，给这个 key 设置 10s 过期即可：

127.0.0.1:6379> SETNX lock 1    // 加锁
(integer) 1
127.0.0.1:6379> EXPIRE lock 10  // 10s后自动过期
(integer) 1

当然上面这两条指令需要保证原子性。

不保证原子性的话，会有下述问题

加锁、设置过期是 2 条命令，有没有可能只执行了第一条，第二条却「来不及」执行的情况发生呢？例如：

SETNX 执行成功，执行 EXPIRE 时由于网络问题，执行失败
SETNX 执行成功，Redis 异常宕机，EXPIRE 没有机会执行
SETNX 执行成功，客户端异常崩溃，EXPIRE 也没有机会执行

在 Redis 2.6.12 版本之前，我们需要想尽办法，保证 SETNX 和 EXPIRE 原子性执行，还要考虑各种异常情况如何处理。

但在 Redis 2.6.12 之后，Redis 扩展了 SET 命令的参数，用这一条命令就可以了：

// 一条命令保证原子性执行
127.0.0.1:6379> SET lock 1 EX 10 NX
OK

锁被别人释放了怎么办？

解决办法是：客户端在加锁时，设置一个只有自己知道的「唯一标识」进去。

例如，可以是自己的线程 ID，也可以是一个 UUID（随机且唯一），这里我们以 UUID 举例：

// 锁的VALUE设置为UUID
127.0.0.1:6379> SET lock $uuid EX 20 NX
OK

之后，在释放锁时，要先判断这把锁是否还归自己持有，伪代码可以这么写：

/ 锁是自己的，才释放
if redis.get("lock") == $uuid:
    redis.del("lock")

这里释放锁使用的是 GET + DEL 两条命令，这时，又会遇到我们前面讲的原子性问题了。

客户端 1 执行 GET，判断锁是自己的
客户端 2 执行了 SET 命令，强制获取到锁（虽然发生概率比较低，但我们需要严谨地考虑锁的安全性模型）
客户端 1 执行 DEL，却释放了客户端 2 的锁

由此可见，这两个命令还是必须要原子执行才行。

怎样原子执行呢？Lua 脚本。(还是可以参考Redisson的实现)

安全释放锁的 Lua 脚本如下：

// 判断锁是自己的，才释放
if redis.call("GET",KEYS[1]) == ARGV[1]
then
    return redis.call("DEL",KEYS[1])
else
    return 0
end

这里我们先小结一下，基于 Redis 实现的分布式锁，一个严谨的的流程如下：

加锁：SET $lock_key $unique_id EX $expire_time NX
操作共享资源
释放锁：Lua 脚本，先 GET 判断锁是否归属自己，再 DEL 释放锁

锁过期了怎么办？

试想这样一种场景：

客户端 1 加锁成功，开始操作共享资源
客户端 1 操作共享资源的时间，「超过」了锁的过期时间，锁被「自动释放」
客户端 2 加锁成功，开始操作共享资源
客户端 1 操作共享资源完成，释放锁（但释放的是客户端 2 的锁）

那么如何评估操作共享资源的时间

例如，操作共享资源的时间「最慢」可能需要 15s，而我们却只设置了 10s 过期，那这就存在锁提前过期的风险。

过期时间太短，那增大冗余时间，例如设置过期时间为 20s，这样总可以了吧？

这样确实可以「缓解」这个问题，降低出问题的概率，但依旧无法「彻底解决」问题。

看门狗机制

Redisson 是一个 Java 语言实现的 Redis SDK 客户端，在使用分布式锁时，它就采用了「自动续期」的方案来避免锁过期，这个守护线程我们一般也把它叫做「看门狗」线程。

除此之外，这个SDK还封装了很多易用的功能

可重入锁
乐观锁
公平锁
读写锁
Redlock（红锁，下面会详细讲）

客户端 1 加锁的锁 key 默认生存时间才 30 秒，如果超过了 30 秒，客户端 1 还想一直持有这把锁，怎么办呢？

Redisson 提供了一个续期机制，只要客户端 1 一旦加锁成功，就会启动一个 Watch Dog。

private <T> RFuture<Long> tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId) {
    if (leaseTime != -1) {
        return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
    }
    RFuture<Long> ttlRemainingFuture = tryLockInnerAsync(commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
    ttlRemainingFuture.onComplete((ttlRemaining, e) -> {
        if (e != null) {
            return;
        }

        // lock acquired
        if (ttlRemaining == null) {
            scheduleExpirationRenewal(threadId);
        }
    });
    return ttlRemainingFuture;
}

releaseTime=-1也就是没有设置过期时间

private void scheduleExpirationRenewal(long threadId) {
    ExpirationEntry entry = new ExpirationEntry();
    //将线程放入缓存中
    ExpirationEntry oldEntry = EXPIRATION_RENEWAL_MAP.putIfAbsent(getEntryName(), entry);
    //第二次获得锁后 不会进行延期操作
    if (oldEntry != null) {
        oldEntry.addThreadId(threadId);
    } else {
        entry.addThreadId(threadId);
        
        // 第一次获得锁 延期操作
        renewExpiration();
    }
}

// 进入 renewExpiration()
private void renewExpiration() {
    ExpirationEntry ee = EXPIRATION_RENEWAL_MAP.get(getEntryName());
    //如果缓存不存在，那不再锁续期
    if (ee == null) {
        return;
    }
    
    Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
        @Override
        public void run(Timeout timeout) throws Exception {
            ExpirationEntry ent = EXPIRATION_RENEWAL_MAP.get(getEntryName());
            if (ent == null) {
                return;
            }
            Long threadId = ent.getFirstThreadId();
            if (threadId == null) {
                return;
            }
            
            //执行lua 进行续期
            RFuture<Boolean> future = renewExpirationAsync(threadId);
            future.onComplete((res, e) -> {
                if (e != null) {
                    log.error("Can't update lock " + getName() + " expiration", e);
                    return;
                }
                
                if (res) {
                    //延期成功，继续循环操作
                    renewExpiration();
                }
            });
        }
        //每隔internalLockLeaseTime/3=10秒检查一次
    }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);
    
    ee.setTimeout(task);
}

//lua脚本 执行包装好的lua脚本进行key续期
protected RFuture<Boolean> renewExpirationAsync(long threadId) {
    return evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
            "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                    "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                    "return 1; " +
                    "end; " +
                    "return 0;",
            Collections.singletonList(getName()),
            internalLockLeaseTime, getLockName(threadId));
}

看门狗如何判断线程是否存活？

Watch Dog 机制其实就是一个后台定时任务线程，获取锁成功之后，会将持有锁的线程放入到一个 RedissonLock.EXPIRATION_RENEWAL_MAP里面，然后每隔 10 秒 （internalLockLeaseTime / 3） 检查一下，如果客户端 1 还持有锁 key（判断客户端是否还持有 key，其实就是遍历 EXPIRATION_RENEWAL_MAP 里面线程 id 然后根据线程 id 去 Redis 中查，如果存在就会延长 key 的时间），那么就会不断的延长锁 key 的生存时间。

上述源码读过来我们可以记住几个关键情报：

watch dog 在当前节点存活时每10s给分布式锁的key续期 30s；
watch dog 机制启动，且代码中没有释放锁操作时，watch dog 会不断的给锁续期；
从可2得出，如果程序释放锁操作时因为异常没有被执行，那么锁无法被释放，所以释放锁操作一定要放到 finally {} 中；

释放锁操作异常了,看门狗还会续期吗？

看到3的时候，可能会有人有疑问，如果释放锁操作本身异常了，watch dog 还会不停的续期吗？下面看一下释放锁的源码，找找答案。

// 锁释放
public void unlock() {
    try {
        get(unlockAsync(Thread.currentThread().getId()));
    } catch (RedisException e) {
        if (e.getCause() instanceof IllegalMonitorStateException) {
            throw (IllegalMonitorStateException) e.getCause();
        } else {
            throw e;
        }
    }
}

// 进入 unlockAsync(Thread.currentThread().getId()) 方法 入参是当前线程的id
public RFuture<Void> unlockAsync(long threadId) {
    RPromise<Void> result = new RedissonPromise<Void>();
    //执行lua脚本 删除key
    RFuture<Boolean> future = unlockInnerAsync(threadId);

    future.onComplete((opStatus, e) -> {
        // 无论执行lua脚本是否成功 执行cancelExpirationRenewal(threadId) 方法来删除EXPIRATION_RENEWAL_MAP中的缓存
        cancelExpirationRenewal(threadId);

        if (e != null) {
            result.tryFailure(e);
            return;
        }

        if (opStatus == null) {
            IllegalMonitorStateException cause = new IllegalMonitorStateException("attempt to unlock lock, not locked by current thread by node id: "
                    + id + " thread-id: " + threadId);
            result.tryFailure(cause);
            return;
        }

        result.trySuccess(null);
    });

    return result;
}

// 此方法会停止 watch dog 机制
void cancelExpirationRenewal(Long threadId) {
    ExpirationEntry task = EXPIRATION_RENEWAL_MAP.get(getEntryName());
    if (task == null) {
        return;
    }
    
    if (threadId != null) {
        task.removeThreadId(threadId);
    }

    if (threadId == null || task.hasNoThreads()) {
        Timeout timeout = task.getTimeout();
        if (timeout != null) {
            timeout.cancel();
        }
        EXPIRATION_RENEWAL_MAP.remove(getEntryName());
    }
}

那么如何实现锁的可重入呢？

Redis还提供了一种保证原子性的实现手段

lua脚本

回想下ReetrantLock是如何实现的一个threadId和state变量代表重入次数

那么Redis也可以做类似的设计。使用哈希结构

if (redis.call('exists', KEYS[1]) == 0) then " +
   "redis.call('hincrby', 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]);"

这里 KEYS[1] 代表的是你加锁的 key，比如你自己设置了加锁的那个锁 key 就是 “myLock”。

// create a lock
RLock lock = redisson.getLock("myLock");

这里ARGV[1]代表的是默认的生存时间，默认是30s，ARGV[2] 代表的是加锁的客户端的 ID,类似于下面这样：285475da-9152-4c83-822a-67ee2f116a79:52。至于最后面的一个 1 是为了后面可重入做的计数统计，后面会有讲解到。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-op5iSPpY-1665198005057)(E:\TyporaPic\image-20220922161635176.png)]

127.0.0.1:6379> HGETALL myLock
1) "285475da-9152-4c83-822a-67ee2f116a79:52"
2) "1"

上面这一段加锁的 lua 脚本的作用是：第一段 if 判断语句，就是用 exists myLock 命令判断一下，如果你要加锁的那个锁 key 不存在的话，你就进行加锁。如何加锁呢？使用 hincrby 命令设置一个 hash 结构，类似于在 Redis 中使用下面的操作：

127.0.0.1:6379> HINCRBY myLock 285475da-9152-4c83-822a-67ee2f116a79:52 1
(integer) 1

那么就可以支持下面这种代码：

public void lock() {
    RLock lock = redissonSingle.getLock("myLock");
    try {
        lock.lock();

        // 执行业务
        doBusiness();

        lock.lock();

    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        // 释放锁
        lock.unlock();
        lock.unlock();
        logger.info("任务执行完毕, 释放锁!");
    }
}

抢不到锁怎么的线程呢

看下Redisson的做法

/** 
 * @param waitTime 等待锁的时长  
 * @param leaseTime 锁的持有时间  
 * @param unit 时间单位 
 * @return 
 * @throws InterruptedException 
 */ 
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {    // 剩余的等待锁的时间 
        long time = unit.toMillis(waitTime); 
        long current = System.currentTimeMillis(); 
         
        final long threadId = Thread.currentThread().getId(); 
        // 尝试获取锁，如果没取到锁，则返回锁的剩余超时时间 
        Long ttl = tryAcquire(leaseTime, unit, threadId); 
        // ttl为null，说明可以抢到锁了，返回true 
        if (ttl == null) { 
            return true; 
        } 
         
        // 如果waitTime已经超时了，就返回false，代表申请锁失败 
        time -= (System.currentTimeMillis() - current); 
        if (time <= 0) { 
            acquireFailed(threadId); 
            return false; 
        } 
         
        current = System.currentTimeMillis(); 
        // 订阅分布式锁, 解锁时进行通知，看，这里就用到了我们上面说的发布-订阅了吧 
        final RFuture<RedissonLockEntry> subscribeFuture = subscribe(threadId); 
        // 阻塞等待锁释放，await()返回false，说明等待超时了 
        if (!await(subscribeFuture, time, TimeUnit.MILLISECONDS)) { 
            if (!subscribeFuture.cancel(false)) { 
                subscribeFuture.addListener(new FutureListener<RedissonLockEntry>() { 
                    @Override 
                    public void operationComplete(Future<RedissonLockEntry> future) throws Exception { 
                        if (subscribeFuture.isSuccess()) { 
                         // 等待都超时了，直接取消订阅 
                            unsubscribe(subscribeFuture, threadId); 
                        } 
                    } 
                }); 
            } 
            acquireFailed(threadId); 
            return false; 
        } 
 
        try { 
            time -= (System.currentTimeMillis() - current); 
            if (time <= 0) { 
                acquireFailed(threadId); 
                return false; 
            } 
         // 进入死循环，反复去调用tryAcquire尝试获取锁，跟上面那一段拿锁的逻辑一样 
            while (true) { 
                long currentTime = System.currentTimeMillis(); 
                ttl = tryAcquire(leaseTime, unit, threadId); 
                // lock acquired 
                if (ttl == null) { 
                    return true; 
                } 
 
                time -= (System.currentTimeMillis() - currentTime); 
                if (time <= 0) { 
                    acquireFailed(threadId); 
                    return false; 
                } 
 
                // waiting for message 
                currentTime = System.currentTimeMillis(); 
                if (ttl >= 0 && ttl < time) { 
                    getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS); 
                } else { 
                    getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS); 
                } 
 
                time -= (System.currentTimeMillis() - currentTime); 
                if (time <= 0) { 
                    acquireFailed(threadId); 
                    return false; 
                } 
            } 
        } finally { 
            unsubscribe(subscribeFuture, threadId); 
        } 
//        return get(tryLockAsync(waitTime, leaseTime, unit)); 
    }