当前位置：首页 > news >正文

SETNX的存在问题和redisson进行改进的原理

news 来源：原创 2025/7/18 23:33:47

首先分布式锁的原理就是当锁不存在时则创建，创建到锁的线程则执行业务。但是在这些操作中会有一些问题，下面是redis命令setNX设置锁的代码片段

if(缓存中有){返回缓存中的数据
}else{获取分布式锁if(获取锁成功）{try{查询数据库}finally{释放锁}}}

首先就是没有办法准确得知try中操作的执行时间，如果设置锁的过期时间过长，会导致效率下降，所以引入了finally，当操作执行完毕后手动删除锁。

但是如果过期时间过短，可能在操作还没执行完锁就过期了，这个时候另一个线程可以获取锁，而当前线程执行完操作后会执行finally的解锁操作，这就会导致将另一个刚获取锁的线程的锁删除掉。

所以需要在finally中判断线程与锁的关系，是本线程加的锁才能够删除。

这个时候又会有问题，如果在一个线程获取锁后执行到finally了，先进行判断锁的归属，判断成功了，在准备执行解锁操作的时候，突然锁过期了，由于CPU的调度另一个线程在这个时候创建了一个新的锁开始执行任务。当CPU转回到本线程执行时，则直接进行删锁操作，就又导致了锁被错删。

为了解决这个问题，就需要把判断的过程设置为具有原子性的操作，使用lua脚本。

这样看使用redis命令实现分布式锁比较复杂，所以下面的redisson的方式就更加方便

redisson实现分布式锁：上面的介绍表明SETNX的问题主要来源于这两点，一是锁过期时间不容易判断，二是操作的原子性，这两点引发了后面一系列的问题。redisson则将解决这些问题的操作都进行了封装，并且其继承了jdk中的LOCK接口，使用自旋的ReentrantLock；redisson主要优化了以下两点

1.加锁机制：线程去获取锁，获取成功: 执行lua脚本，保存数据到redis数据库。

线程去获取锁，获取失败: 一直通过while循环尝试获取锁，获取成功后，执行lua脚本，保存数据到redis

2.WatchDog自动续锁看门狗机制：在一个分布式环境下，假如一个线程获得锁后，突然服务器宕机了，那么这个时候在一定时间后这个锁会自动释放，你也可以设置锁的有效时间(当不设置默认30秒时），这样的目的主要是防止死锁的发生

如果线程A业务还没有执行完，时间就过了，线程A 还想持有锁的话，就会启动一个watch dog后台线程，不断的延长锁key的生存时间。

实现：

if(缓存中有){返回缓存中的数据
}else{
RLock lock = redissonClient.getLock("锁名称");
lock.lock();
try {//从数据库中取//查询完成后再存储到redis
}  finally {lock.unlock();
}
}

相关文章：