Redisson分布式锁会续命么?

1. 基础用法



由于数据库和应用服务的双重水平、垂直切分,会导致一个完整业务需要跨多个数据处理的情况,很多并发情况下会发生数据一致性问题,为了解决该问题,本项目引入了Redisson作为分布式锁解决方案,项目地址https://github.com/redisson/redisson



在需要加锁的地方,首先生成lockKey,然后调用tryLock获取状态,该方法返回的状态必须做判断,失败的时候也一定要做好合适的失败处理:
image.png
需要注意的是:锁和解锁必须成对出现!


2. 分布式锁的时间问题



上面的组件是经过我们封装过的,实际上,在发起锁(tryLock)的时候,我们传入了两个参数:



default_wait_time:锁等待时间,该时间内无法得到锁,则获取失败(false)



default_expire_time:锁失效时间,超过该时间,则会自动释放锁



这两个参数在很多分布式锁框架里面都存在,这里解释一下。



第一个很好理解,当并发量很大时,锁的争抢非常严重,执行体等待时间过长,会导致调用端耗时严重,等待时间过短,则失败率会提高,目前我默认设置3秒,即:3秒内拿不到锁,则返回失败,调用端可能需要发起重试或者直接失败(假如允许失败的话)。



第二个参数会有一些坑点存在,比如某个执行逻辑很耗时,超过了我们的锁失效时间,此时会自动释放锁,那么新的线程/进程会拿到该锁,最终导致前一个执行体未执行完,新的执行就开始了,进而产生数据不一致的情况。目前我项目里面设置的是30秒,有兴趣可以看RedissonLockComponent。

不过,假如用的是用的Redisson,从内部源码看,它会在默认过了2/3时间的时候自动续命。此时你唯一要祈祷的是:Redis服务千万不要挂了。。。




暂无评论