redission与setIfAbsent分布式锁

项目中迁移,发现项目中有使用两种分布式锁,redission锁和redis的setIfAbsent锁。虽然redission简单方便好用,但是测试下来发现速度很慢,会导致响应超时的情况,影响前端响应。然后打算用setIfAbsent写在需要有及时响应的接口上。但是测试时加锁不上、空异常,因对本次异常做个解决方案和使用方法做个记录。

出现的问题

由于redission版本导致redis的setIfAbsent返回空。

.前提redis版本使用spring内置的版本

.pom文件改动,升级redission版本在3.16以上

.application.yml文件改动,配置改为文件引用

.redission.yml配置文件改动

  1. setIfAbsent使用示例

setIfAbsent方法等同于SETNX命令,加锁和设置过期时间必须是一个原子操作,在调用setIfAbsent传入锁名的同时必须传入过期时间。设置的过期时间一般大于业务执行的最大时间,value存入一个uuid,释放的时候先查询是否存在该uuid再释放,保证释放的是同一线程的锁。

  1. redission使用示例

未设置过期时间(-1)时则会有watchDog锁续约,释放锁判断是否为同一线程的锁。

lock会阻塞,trylock加锁失败会返回false,所以使用trylock释放锁的时候需要判断锁的状态

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
首先,setIfAbsent命令在Redis中可以用来实现分布式锁,它可以确保只有一个客户端能够成功地获取锁。当多个客户端同时尝试获取锁时,只有其中一个客户端会成功地将键设置为不存在的状态,即获取到锁。 如果你遇到了setIfAbsent分布式锁失败的情况,可能有以下几个原因: 1. 网络延迟:由于网络延迟的存在,在一个客户端尝试获取锁操作后,可能有一段时间内其他客户端还无法感知到该键已经被设置为存在。这样就可能导致多个客户端同时认为自己获取到了锁,造成冲突。 2. 客户端执行时间过长:如果一个客户端在获取到锁之后执行时间过长,超过了锁的有效期,那么其他客户端就可以再次获取到该锁。这会导致之前获取锁的客户端在执行完后释放锁时,实际上释放的是其他客户端获取到的锁。 3. 锁的有效时间设置不合理:如果锁的有效时间设置得过长,可能会导致其他客户端长时间等待锁的释放。这可能会影响系统的性能和并发能力。 解决这个问题的一种方式是在获取锁时添加一个唯一标识符,确保每个客户端持有独一无二的锁。另外,可以根据具体业务需求,适当调整锁的有效时间,避免锁过早释放或过长占用。 需要注意的是,Redis自身并不提供完全可靠的分布式锁,因为它在面对网络分区等异常情况时可能出现问题。如果对于分布式锁要求高的场景,可以考虑使用基于Redis的第三方分布式锁实现,例如Redlock或基于ZooKeeper的Curator库等。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值