当一个业务执行时间超过自己设定的锁释放时间,那么会导致有其他线程进入,从而抢到同一个票,所有需要使用看门狗策略,其实就是开一个守护线程,让守护线程去监控key,如果到时间了还未结束,就会将这个key重新set一次,重置到原来的时间,只要主线程未结束,守护线程就会一直存在,这里还是会有一些问题,就是如果redis宕机了,导致第一个线程拿到了锁,第二个线程也拿到了锁,为了解决这个就需要引入红锁
1. 导入依赖,这里导入依赖可能会和原先的redis依赖冲突,所以只能留下一个,不然可能会出错
去除spring-boot-starter-data-redis
<!-- 集成redis-->
<dependency>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-starter-data-redis</artifactid>
</dependency>添加redisson
<dependency>
<groupid>org.redisson</groupid>
<artifactid>redisson-spring-boot-starter</artifactid>
<version>3.21.0</version>
</dependency>2. 修改配置文件,将之前的配置缓存redisson的
spring:
data:
redis: # redis配置
url: redis://:127.0.0.1:63793. 开始分布式锁-看门狗策略,找到高频访问的业务添加以下代码
在业务方法开始的头添加

在方法末尾添加释放锁,别忘了添加try-catch-finally块

这是一段完整的分布式处理,有需要直接copy后修改即可
public void doconfirm(confirmorderdoreq req) {
string lockkey = dateutil.formatdate(req.getdate()) + "-" + req.gettraincode();
rlock lock = null;
try {
lock = redissonclient.getlock(lockkey);
boolean trylock = lock.trylock(0, timeunit.seconds);
if (trylock) {
log.info("抢到锁,开始处理订单");
} else {
log.info("很遗憾,没有抢到锁");
//当前抢票人数多,请稍后再试
throw new businessexception(businessexceptionenum.confirm_order_lock_fail);
}
//业务处理。。。。
} catch (interruptedexception e) {
log.error("抢票失败", e);
throw new businessexception(businessexceptionenum.confirm_order_lock_fail);
} finally {
log.info("锁被释放了");
// 释放锁
if (lock != null && lock.isheldbycurrentthread()){
lock.unlock();
}
}
}到此这篇关于redis解决高并发看门狗策略的实现的文章就介绍到这了,更多相关redis 高并发看门狗策略内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
发表评论