Redis

关注公众号 jb51net

关闭
首页 > 数据库 > Redis > Redis分布式锁的超时

Redis分布式锁的超时问题及解决

作者:阿飞Sirx

这篇文章主要介绍了Redis分布式锁的超时问题及解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教

Redis分布式锁的超时

Redis的分布式锁并不能解决超时问题,如果在加锁和释放锁之间的逻辑执行得太长,以至于超出了锁的超时限制,就会出现问题,因为这时候第一个线程持有的锁过期了,临界区的逻辑还没有执行完,而同时第二个线程就提前持有了这把锁,导致临界区代码不能得到严格串行执行

为了避免这个问题,分布式锁不要用于较长时间的任务,如果真的偶尔出现了问题,造成的数据小错乱,可能需要人工介入解决

有一个稍微安全一点的方案,是将set指令的value参数设置为一个随机数,释放锁时先匹配随机数是否一致,然后在删除key,这是为了确保当前线程占有的锁不会被其他线程释放,除非这个锁是自动超时,但是匹配value,和删除ke y不是一个原子操作,所以只是相对安全

分布式锁失效问题

分布式锁

1.1集群下的锁失效问题

Synchronized中的重量级锁,底层就是基于锁监视器(Monitor)来实现的。

简单来说就是锁对象头会指向一个锁监视器,而在监视器中则会记录一些信息

比如:

因此每锁一个对象。都会指向一个锁监视器,但是每个锁监视器同一时刻只能被一个线程持有,这样再单机模式下,不同服务的JVM当然不能通信,这样就会出现锁失效问题。所以在分布式环境下就不能使用Synchronized。所以分布式锁一定要满足多JVM都能访问并且互斥的条件。

能满足上述特征的组件有很多,因此实现分布式锁的方式也非常多,例如:

常见的最广泛的应用解决方式就是基于Redis实现的分布式锁。

1.2.简单分布式锁

先来弄清原理,Redis的setnx命令是基于string操作的。

命令如下:

SETNX key value

当且仅当这个key不存在时setnx才能执行成功,并且返回1,其它情况都会执行失败,并且返回0.我们就可以认为返回值是1就是获取锁成功,返回值是0就是获取锁失败,实现互斥效果。

当业务执行完成时,我们只需要通过DEL key命令删除这个即可释放锁。这个时候其它线程又可以再次获取锁(执行setnx成功)了。

不过我们要考虑一种极端的场景。获取成功后,还没释放锁时突然宕机,那么释放锁的动作就不会被执行这就出现了死锁。

# 获取锁,并记录持有锁的线程
SETNX lock thread1
# 设置过期时间,避免死锁
EXPIRE lock 20我们可以利用Redis的KEY过期时间机制,在获取锁时给锁添加一个超时时间:    

但是这显然是两条独立的命令,如果我执行完setnx后宕机,过期时间还未设置,死锁问题又出现了!

为了保证两条命令的原子性使用SET lock thread1 NX EX 20 就能保证原子性。对应的api如下。

@RequiredArgsConstructor
public class RedisLock {
 
    private final String key;
    private final StringRedisTemplate redisTemplate;
 
    /**
     * 尝试获取锁
     * @param leaseTime 锁自动释放时间
     * @param unit 时间单位
     * @return 是否获取成功,true:获取锁成功;false:获取锁失败
     */
    public boolean tryLock(long leaseTime, TimeUnit unit){
        // 1.获取线程名称
        String value = Thread.currentThread().getName();
        // 2.获取锁
        Boolean success = redisTemplate.opsForValue().setIfAbsent(key, value, leaseTime, unit);
        // 3.返回结果
        return BooleanUtils.isTrue(success);
    }
 
    /**
     * 释放锁
     */
    public void unlock(){
        redisTemplate.delete(key);
    }
}

1.3.分布式锁的问题

1.3.1.锁误删问题

第一个问题就是锁误删问题,目前释放锁的操作是基于DEL,但是在极端情况下会出现问题。

假设场景,线程1获取锁成功完成执行,准备释放锁。

 但因为某些原因导致释放锁的操作被阻塞,直到超时放锁

 

这时因为线程1被超时释放,所以线程2拿到了锁。这时候线程1醒了,给线程2的锁删了。

但此时线程2还是在执行中,线程3在来的时候就会认为现在没人拿锁,于是多个线程再次并发执行,并发安全就可能再出现。

为了解决这种场景,我们可以在删除锁之前判断当前锁的中保存的是否是当前线程标示,如果不是则证明不是自己的锁,则不删除;如果锁标示是当前线程,则可以删除。

1.3.2.超时释放问题

总结起来,根源就在于判断锁标识和删除锁是两个动作,又不符合原子性了。

1.3.3分布式锁的其他问题

对应的解决方案也有,就是比较麻烦

我们自己手写解决不仅繁琐,而且实现起来耗费时间,所以我们可以使用开源的框架来实现分布式锁。其中比较完善的一个第三方组件就是Redisson

总结

以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。

您可能感兴趣的文章:
阅读全文