当一个业务执行时间超过自己设定的锁释放时间,那么会导致有其他线程进入,从而抢到同一个票,所有需要使用看门狗策略,其实就是开一个守护线程,让守护线程去监控key,如果到时间了还未结束,就会将这个key重新set一次,重置到原来的时间,只要主线程未结束,守护线程就会一直存在,这里还是会有一些问题,就是如果redis宕机了,导致第一个线程拿到了锁,第二个线程也拿到了锁,为了解决这个就需要引入红锁
- 导入依赖,这里导入依赖可能会和原先的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>
修改配置文件,将之前的配置缓存redisson的
spring:
data:
redis: # redis配置
url: redis://:127.0.0.1:6379开始分布式锁-看门狗策略,找到高频访问的业务添加以下代码
在业务方法开始的头添加
在方法末尾添加释放锁,别忘了添加try-catch-finally块
这是一段完整的分布式处理,有需要直接copy后修改即可
javapublic 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解决高并发看门狗策略
小汤猿人类2025-02-18 6:04
相关推荐
Serene_Dream4 分钟前
JVM 并发 GC - 三色标记rannn_1117 分钟前
【苍穹外卖|Day4】套餐页面开发(新增套餐、分页查询、删除套餐、修改套餐、起售停售)qq_124987075311 分钟前
基于JavaWeb的大学生房屋租赁系统(源码+论文+部署+安装)短剑重铸之日17 分钟前
《设计模式》第十一篇:总结若鱼191940 分钟前
SpringBoot4.0新特性-Observability让生产环境更易于观测觉醒大王1 小时前
强女思维:着急,是贪欲外显的相。forestsea1 小时前
深入理解Redisson RLocalCachedMap:本地缓存过期策略全解析努力学编程呀(๑•ี_เ•ี๑)1 小时前
【在 IntelliJ IDEA 中切换项目 JDK 版本】码农小卡拉1 小时前
深入解析Spring Boot文件加载顺序与加载方式佛祖让我来巡山1 小时前
Redis 为什么这么快?——「极速快递站」的故事
