秒杀相关问题解决

秒杀

超卖问题

如下,我们先来复现问题,抢购秒杀券的代码逻辑也是很简单,
在这里插入图片描述
先判断优惠券是否开始了,是的化,判断库存是否充足,如果是的化,扣减库存,最后创建订单

如下是代码

@Override
@Transactional
public Result seckillVoucher(Long voucherId) {//1.查询优惠券SeckillVoucher voucher = seckillVoucher.getById(voucherId);if(voucher == null) {return Result.fail("优惠券不存在");}//2.判断秒杀是否开始if(voucher.getBeginTime().isAfter(LocalDateTime.now())) {return Result.fail("秒杀活动还没开始!");}//3.判断秒杀是否结束if(voucher.getEndTime().isBefore(LocalDateTime.now())) {return Result.fail("秒杀活动已经结束了!");}//4.判断库存是否充足if(voucher.getStock() < 1) {return Result.fail("库存不足!");}//5.扣减库存boolean isSuccess = seckillVoucher.update().setSql("stock = stock - 1").eq("voucher_id", voucherId).update();//6.判断是否成功if(!isSuccess) {return Result.fail("扣减库存失败!");}//7.创建订单VoucherOrder voucherOrder = new VoucherOrder();//7.1订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);//7.2用户idLong userId = UserHolder.getUser().getId();voucherOrder.setUserId(userId);//7.3代金券idvoucherOrder.setVoucherId(voucherId);//7.4保存到voucher_order表中save(voucherOrder);//8.返回订单idreturn Result.ok(orderId);
}

问题出现如下代码
在这里插入图片描述
我们判断是否充足的时候,有可能很多线程进来刚好都通过了,就会有问题

测试

在这里插入图片描述

设置jmeter
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
这里是加上token头,因为我的系统写了token头,才能通过,你要是没有的化,就不用

测试结果
在这里插入图片描述
如此就是超卖了

乐观锁 & 悲观锁

理解乐观锁 & 悲观锁

乐观锁有可能你还不是很懂,但是你一定要知道这个,乐观锁,实际上没有加锁,主打的就是一个乐观,如果发现没有问题,就不上锁,如果有问题,就通过特殊的手段保证线程的安全,这里的特殊的手段一般来说,就是类似于cas这样的,使用一个标识来判断是否有线程安全问题

悲观锁就很好理解了,就是平常我们加的粒度很大的锁,例如synchronized

乐观锁的思想

乐观锁的实操都是一个统一的思想,就是cas,比较 + 交换
比较的是什么,得到的旧值 和 我们再一次得到的值(理解为新值) 判断是否是一致的,如果不是一致的,那么就代表着有线程安全问题

我们再来理解一下这里的比较的意思,为什么要比较我们得到的值,举个例子

一开始我们拿到 stock = 100
然后过了几s,我们再去获取stock,发现stock = 98
是不是就说明这里的stock被人用过了,那么就有线程安全问题!此时我们就退出,或者人为再去加锁,都是可以的,一般来说,乐观锁不会直接加锁

我们再来想一个问题,为什么要有乐观锁???
我直接加锁不好吗?? 为的是两个字 性能!!!

我们一旦加了大粒度的锁,就会消耗性能,在那等吗,当然消耗了,所以就有了乐观锁的存在,它实际上是没有锁的,所以性能当然高!!!

乐观锁的缺点

那难道说,乐观锁,就那么好,没什么缺点? 肯定是有的, 会有完成率的问题
完成率不高,甚至于说,本来200 人抢100张优惠券的问题,但是由于设置的乐观锁, 再高并发下,很容易很多的线程都没有抢到,这种问题,在我这里也出现了, 解决办法就是改变比较条件就行,实例请看下面

乐观锁解决超卖

在这里插入图片描述
想我这里就是,简单的cas,判断是否是刚刚的库存

乐观锁完成率不高问题

在这里插入图片描述
我们这里更改了条件,只要库存 > 0的化,就可以成功!

这里为什么可以保证原子性,我觉得需要特别说明一下
我们请求打到数据库的时候那个时间点 有条件 stock > 0
因为有事务的原因,mysql这里的写操作是线程安全的,所以这里不会有问题

一人一单问题

一人一单问题,也是可能会有线程安全问题
我们先来看流程图
在这里插入图片描述
再超卖问题解决之下,去判断是否已经下过一单了,是的化,就不去下单

代码如下

    @Overridepublic Result seckillVoucher(Long voucherId) {//1.查询优惠券SeckillVoucher voucher = seckillVoucher.getById(voucherId);if (voucher == null) {return Result.fail("优惠券不存在");}//2.判断秒杀是否开始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {return Result.fail("秒杀活动还没开始!");}//3.判断秒杀是否结束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {return Result.fail("秒杀活动已经结束了!");}//4.判断库存是否充足if (voucher.getStock() < 1) {return Result.fail("库存不足!");}Long userId = UserHolder.getUser().getId();//5.一人一单int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();if(count > 0) {return Result.fail("你已经买过了");}//6.扣减库存boolean isSuccess = seckillVoucher.update().setSql("stock = stock - 1").eq("voucher_id", voucherId).gt("stock",0).update();//7.判断是否成功if (!isSuccess) {return Result.fail("扣减库存失败!");}//8.创建订单VoucherOrder voucherOrder = new VoucherOrder();//8.1订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);//8.2用户idvoucherOrder.setUserId(userId);//8.3代金券idvoucherOrder.setVoucherId(voucherId);//8.4保存到voucher_order表中save(voucherOrder);//9.返回订单idreturn Result.ok(orderId);}

问题处在这
在这里插入图片描述如果高并发的情况下,就有可能会有问题

复现线程安全问题

jmeter设置: 和超卖问题的复现jmeter设置是一致的

在这里插入图片描述

原先订单数100
在这里插入图片描述

抢购17号优惠券,正常来说,一个用户只能抢1张

测试结果
在这里插入图片描述

下了10单
在这里插入图片描述

这里就是一人一单出了线程安全问题!

加锁解决

    @Autowiredprivate SeckillVoucherServiceImpl seckillVoucher;@Resourceprivate RedisIdWorker redisIdWorker;@Overridepublic Result seckillVoucher(Long voucherId) {//1.查询优惠券SeckillVoucher voucher = seckillVoucher.getById(voucherId);if (voucher == null) {return Result.fail("优惠券不存在");}//2.判断秒杀是否开始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {return Result.fail("秒杀活动还没开始!");}//3.判断秒杀是否结束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {return Result.fail("秒杀活动已经结束了!");}//4.判断库存是否充足if (voucher.getStock() < 1) {return Result.fail("库存不足!");}return createVoucherOrder(voucherId);}    @Transactionalpublic synchronized Result createVoucherOrder(Long voucherId) {Long userId = UserHolder.getUser().getId();//5.一人一单int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();System.out.println("此时count为" + count);if (count > 0) {return Result.fail("用户已经购买过一次");}//6.扣减库存boolean isSuccess = seckillVoucher.update().setSql("stock = stock - 1").eq("voucher_id", voucherId).gt("stock", 0).update();//7.判断是否成功if (!isSuccess) {return Result.fail("扣减库存失败!");}//8.创建订单VoucherOrder voucherOrder = new VoucherOrder();//8.1订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);//8.2用户idvoucherOrder.setUserId(userId);//8.3代金券idvoucherOrder.setVoucherId(voucherId);//8.4保存到voucher_order表中save(voucherOrder);//9.返回订单idreturn Result.ok(orderId);}

再整个方法上加锁,这样确实是万无一失

测试
在这里插入图片描述

结果是正确的

优化加锁

如果直接再方法上加锁的化,那么锁的是类对象,也就是这里的service类对象,那么单用户情况下就没问题,但是在多用户情况下就会有问题,因为这里的锁是service类,那么相当于锁的是全部人,也就是说,别的用户还得等你抢完了才能枪,所以这里的锁的粒度有问题,应该锁的是对应的用户而不是所有用户!!!

    @Transactionalpublic Result createVoucherOrder(Long voucherId) {//只锁住相同用户,所以这里用userIdLong userId = UserHolder.getUser().getId();//这里是更细粒度的锁,这里不能直接用Long userId来锁,因为有可能是同一个对象,jvm知识//所以这里用字符串对象,但是Long的toString()里边也是new String(),所以这里要intern()//避免相同的用户却有着不同的锁,再字符串池里边找到我们那个唯一的用户stringsynchronized (userId.toString().intern()) {//5.一人一单int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();System.out.println("此时count为" + count);if (count > 0) {return Result.fail("用户已经购买过一次");}//6.扣减库存boolean isSuccess = seckillVoucher.update().setSql("stock = stock - 1").eq("voucher_id", voucherId).gt("stock", 0).update();//7.判断是否成功if (!isSuccess) {return Result.fail("扣减库存失败!");}//8.创建订单VoucherOrder voucherOrder = new VoucherOrder();//8.1订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);//8.2用户idvoucherOrder.setUserId(userId);//8.3代金券idvoucherOrder.setVoucherId(voucherId);//8.4保存到voucher_order表中save(voucherOrder);//9.返回订单idreturn Result.ok(orderId);}}

这样子锁的才是用户,多人抢的化,就不会相互干涉

事务失效

提到这个我不得不说,这个问题比较难理解,这里的问题相关springboot中的事务

我们来看这里的代码

在这里插入图片描述

在这个方法上我们加上了事务 @Transactional 也就是springboot事务处理
,这个注解默认什么都不写的情况下,事务的隔离级别是数据库的隔离级别,而我这里的数据库是mysql,也就是读已提交
什么是读已提交,也就是说,只能读到已经提交的事务,那些没有提交的事务,别的事务是看不到的

这个隔离级别就是为了解决脏读 + 脏写的问题来着,但是反而在这里会出现问题

我门来看这里的流程

  • 事务开始
  • 上锁
  • 业务代码
  • 释放锁
  • 事务结束

因为这里的锁是嵌套在这个方法里边的,并不是方法上的,所以说,我们释放锁的时候,事务不一定结束!! 换种方法说,就是事务没有提交!

这个问题很关键! 你事务没有提交,意思是别人根本读不到你这里的已经下了单的order,并且你还已经释放锁了,所以别的线程进来,就可以又来下单

所以总的来说,你看这个代码,这个问题的出现就是那么一瞬间的事,但是还是有可能会出现问题的

我们总结一下,为什么会出现这个问题,就是因为释放锁 和 事务的提交不同步,先释放锁了,才去提交事务,这样别人就有可乘之机,所以我们的解决方法就是先去提交事务,再去释放锁

那么我门的锁,就应该锁的是这整个方法了

代码

    @Overridepublic Result seckillVoucher(Long voucherId) {//1.查询优惠券SeckillVoucher voucher = seckillVoucher.getById(voucherId);if (voucher == null) {return Result.fail("优惠券不存在");}//2.判断秒杀是否开始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {return Result.fail("秒杀活动还没开始!");}//3.判断秒杀是否结束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {return Result.fail("秒杀活动已经结束了!");}//4.判断库存是否充足if (voucher.getStock() < 1) {return Result.fail("库存不足!");}Long userId = UserHolder.getUser().getId();synchronized (userId.toString().intern()) {return createVoucherOrder(voucherId);}}@Transactionalpublic Result createVoucherOrder(Long voucherId) {Long userId = UserHolder.getUser().getId();//5.一人一单int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();System.out.println("此时count为" + count);if (count > 0) {return Result.fail("用户已经购买过一次");}//6.扣减库存boolean isSuccess = seckillVoucher.update().setSql("stock = stock - 1").eq("voucher_id", voucherId).gt("stock", 0).update();//7.判断是否成功if (!isSuccess) {return Result.fail("扣减库存失败!");}//8.创建订单VoucherOrder voucherOrder = new VoucherOrder();//8.1订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);//8.2用户idvoucherOrder.setUserId(userId);//8.3代金券idvoucherOrder.setVoucherId(voucherId);//8.4保存到voucher_order表中save(voucherOrder);//9.返回订单idreturn Result.ok(orderId);}

这里还有一个问题,就是这里没有调用事务

这里的 return createVoucherOrder(voucherId);
实际上的写法是这样
return this.createVoucherOrder(voucherId);

是用这个类的对象来调用的,但是由于spring底层是通过aop来实现事务管理的,我们要用代理对象才能发起一个事务,不然还是会有问题!!!

代码

    @Overridepublic Result seckillVoucher(Long voucherId) {//1.查询优惠券SeckillVoucher voucher = seckillVoucher.getById(voucherId);if (voucher == null) {return Result.fail("优惠券不存在");}//2.判断秒杀是否开始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {return Result.fail("秒杀活动还没开始!");}//3.判断秒杀是否结束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {return Result.fail("秒杀活动已经结束了!");}//4.判断库存是否充足if (voucher.getStock() < 1) {return Result.fail("库存不足!");}Long userId = UserHolder.getUser().getId();synchronized (userId.toString().intern()) {//获取代理对象IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();return proxy.createVoucherOrder(voucherId);}}@Transactionalpublic Result createVoucherOrder(Long voucherId) {Long userId = UserHolder.getUser().getId();//5.一人一单int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();System.out.println("此时count为" + count);if (count > 0) {return Result.fail("用户已经购买过一次");}//6.扣减库存boolean isSuccess = seckillVoucher.update().setSql("stock = stock - 1").eq("voucher_id", voucherId).gt("stock", 0).update();//7.判断是否成功if (!isSuccess) {return Result.fail("扣减库存失败!");}//8.创建订单VoucherOrder voucherOrder = new VoucherOrder();//8.1订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);//8.2用户idvoucherOrder.setUserId(userId);//8.3代金券idvoucherOrder.setVoucherId(voucherId);//8.4保存到voucher_order表中save(voucherOrder);//9.返回订单idreturn Result.ok(orderId);}

要设置这个还得加一个依赖

 <dependency><groupId>org.aspectj</groupId><artifactId>aspectjweaver</artifactId></dependency>

在主启动类上

@EnableAspectJAutoProxy(exposeProxy = true)
@MapperScan("com.hmdp.mapper")
@SpringBootApplication
public class HmDianPingApplication {public static void main(String[] args) {SpringApplication.run(HmDianPingApplication.class, args);}}

一人一单(集群)

搭建集群

我这里搭建的集群是jvm的集群,在idea中的jvm集群

idea复用一个8082接口的应用程序

按alt + 8 可以跳出service

然后复制一份应用程序
在这里插入图片描述
更改端口
在这里插入图片描述

nginx配置

打开nginx conf文件下的nginx.conf

这里需要修改就是,下面的把注释打开,并且把上面的8081固定的关闭

这里的意思就是,请求8080,转到http://backend

然后nginx自动会轮询这两个server,一个是8081,一个是8082

在这里插入图片描述


worker_processes  1;events {worker_connections  1024;
}http {include       mime.types;default_type  application/json;sendfile        on;keepalive_timeout  65;server {listen       8080;server_name  localhost;# 指定前端项目所在的位置location / {root   html/hmdp;index  index.html index.htm;}error_page   500 502 503 504  /50x.html;location = /50x.html {root   html;}location /api {  default_type  application/json;#internal;  keepalive_timeout   30s;  keepalive_requests  1000;  #支持keep-alive  proxy_http_version 1.1;  rewrite /api(/.*) $1 break;  proxy_pass_request_headers on;#more_clear_input_headers Accept-Encoding;  proxy_next_upstream error timeout;  
#             proxy_pass http://127.0.0.1:8081;proxy_pass http://backend;}}upstream backend {server 127.0.0.1:8081 max_fails=5 fail_timeout=10s weight=1;server 127.0.0.1:8082 max_fails=5 fail_timeout=10s weight=1;}  
}

更改完之后,要在cmd上重新启动一下

nginx.exe -s reload

在这里插入图片描述

问题出现

将两个应用程序以调试的模式打开

在这里打个断点
在这里插入图片描述

apifox的设置

在这里插入图片描述

第一个用户的配置

第二个用户是一样的

也就是说是同一用户,不过是不同的集群

测试

原先数据库的数据
首先是优惠券表
在这里插入图片描述
然后是优惠券订单表
在这里插入图片描述

是空的

2个接口都发起请求

发现两个应用程序都进去了

在这里插入图片描述
测试发现两个请求都进来了,这和我们的一人一单有问题,他这里会生成两个订单

如下
在这里插入图片描述
在这里插入图片描述
正常来说,我这里设了锁,应该是只能下一单,但是这里再集群情况下,下了两单,所以发生了线程安全问题!

发生问题的有原因

我门要先搞清楚集群的问题,如果是两个集群的化,那么代表的是两个jvm,相当于两个不同的进程,而我们之前那样子加锁,它的范围是jvm的内部,所以这里加锁无效,从这,就引申出分布式锁的概念

简单总结一下,就是没锁上,需要更大范围的锁!

分布式锁

分布式锁有三种实现
-在这里插入图片描述
对于mysql来说,它的互斥锁的实现就是通过事务来实现的,我们再写的时候,会再写上加锁,但我认为这个还是很难的,如果要实现的哈

用redis来实现,比较好实现,就是用setnx,来实现互斥锁

zookeeper 我还不懂,掠过

我这里的获取锁 + 释放锁,已经写好了
代码如下

    /*** 尝试获取锁* @param pattern key* @param value 值* @param <T>* @return*/public <T> boolean tryLock(String pattern,T value){Boolean flag = redisTemplate.opsForValue().setIfAbsent(pattern, value, 2, TimeUnit.MINUTES);return BooleanUtil.isTrue(flag);}/*** 解锁* @param pattern*/public void unlock(String pattern) {//删除锁redisTemplate.delete(pattern);}

给我封装到了我的redis 操作的工具类里边了

问题解决

我们先来看,解决问题的流程,做好一个心里预期
在这里插入图片描述
这个流程还算简洁的

我们直接看解决的代码

@Service
@Slf4j
public class VoucherOrderServiceImpl extends ServiceImpl<VoucherOrderMapper, VoucherOrder> implements IVoucherOrderService {@Autowiredprivate ISeckillVoucherService seckillVoucherService;@Autowiredprivate RedisIdWorker redisIdWorker;@Autowiredprivate RedisCache redisCache;/*** 抢购秒杀券** @param voucherId* @return*/@Override
//    @Transactionalpublic Long seckillVoucher(Long voucherId) {SeckillVoucher voucher = seckillVoucherService.getById(voucherId);log.info("当前库存为 : {}", voucher.getStock());if (Objects.isNull(voucher)) {throw new BaseException("优惠券不存在!");}LocalDateTime nowTime = LocalDateTime.now();//优惠券时间是否开始了if (voucher.getBeginTime().isAfter(nowTime)) {throw new BaseException("优惠券时间还没开始!");}//是否结束了if (voucher.getEndTime().isBefore(nowTime)) {throw new BaseException("优惠券时间已经结束了");}//判断库存是否充足if (voucher.getStock() < 1) {throw new BaseException("库存不足!");}Long userId = UserHolder.getUser().getId();//锁的value是当前线程idlong threadId = Thread.currentThread().getId();boolean isSuccess = redisCache.tryLock(RedisConstants.LOCK_SECKILL_VOUCHER_KEY, threadId + "", RedisConstants.LOCK_SECKILL_VOUCHER_TTL, TimeUnit.SECONDS);if (!isSuccess) {throw new BaseException("用户已经买过了!");}try {IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();return proxy.createVoucherOrder(voucherId);} finally {String lockId = redisCache.getObject(RedisConstants.LOCK_SECKILL_VOUCHER_KEY);//判断是否是一样的锁if (StrUtil.isNotBlank(lockId) && lockId.equals(Thread.currentThread().getId() + "")) {redisCache.unlock(RedisConstants.LOCK_SECKILL_VOUCHER_KEY);}}}@Transactionalpublic synchronized Long createVoucherOrder(Long voucherId) {Long userId = UserHolder.getUser().getId();//一人一单问题LambdaQueryWrapper<VoucherOrder> orderWrapper = new LambdaQueryWrapper<>();orderWrapper.eq(VoucherOrder::getUserId, UserHolder.getUser().getId()).eq(VoucherOrder::getVoucherId, voucherId);int count = count(orderWrapper);if (count > 0) {throw new BaseException("你已经买过了!");}//扣减库存boolean isSuccess = seckillVoucherService.update().setSql("stock = stock - 1").eq("voucher_id", voucherId).gt("stock", 0).update();if (!isSuccess) {throw new BaseException("扣减库存失败!");}long orderId = redisIdWorker.nextId("order");VoucherOrder voucherOrder = VoucherOrder.builder().id(orderId).userId(userId).voucherId(voucherId).build();save(voucherOrder);return orderId;}
}

改动的代码如下
在这里插入图片描述

代码很简洁,就是加一个锁,只不过这个锁是再redis中,如果获取失败,那就说明,有人再抢,有人再抢的化,就直接爆错退出,这样才符合一人一单

测试

这里的测试我就不写了,因为没什么意思,最后结果就是一人一单

小问题

这里的小问题,就是如果按照我门上面这种写法,锁住是所有的用户,而我们加锁是对各个用户加锁,做到一人一单,用户之间应该是隔离的才对,所以这里应该再锁上加上用户的标记,这样别的用户就可以进来了,去枪单

这里实现还是很简单的,就是写rediskey的时候加上 userId

在这里插入图片描述

分布式锁误删问题

因为我们加了redis分布式锁,并且这里的分布式锁,是有过期时间的,所以就会延申出这个问题

为什么要设置过期时间

我们首先先声明一点,为什么必须要加过期时间,咱们这个问题的出现就是由于这个过期时间的问题,为什么我们不能做成永久key呢?

这个问题的答案,就是如果我们做成永久key,一个线程拿到了锁,然后突然发生异常了,或者业务阻塞了, 那么就相当于说,锁释放不了了,那么程序的性能就会大大降低,甚至于我们有可能得人为去干预这个问题

虽然说,我们这个例子,理论上来说,是可以用永久key的,但是大部分的业务是不行的,所以这里要设置过期时间

问题的出现

这个问题得想一想才行

这个情况是比较极端的,但是不代表没有可能会出现

在这里插入图片描述
极端情况下,我们线程1占有了锁,然后突然业务阻塞了,但是业务阻塞的时间比锁的过期时间还要长,这就会导致业务还没结束,锁已经被释放了!


在这里插入图片描述
那么在高并发的情况下,另外一个线程2,乘虚而入,拿到了锁,并且开始执行业务

而在这个时候,在线程2拿到了锁,线程1突然醒了过来,执行了业务代码,然后去执行释放锁的代码

那么这里就会出问题了,线程1不知道这个锁已经被换了主人了,他直接就把锁释放掉了

那么会导致什么结果呢???

在高并发的情况下,线程3一看没有锁了,就乘虚而入

在这里插入图片描述

在这里插入图片描述

线程2还没执行完
线程3就拿到了锁

这样下去,当线程2完成了业务,他就释放了锁,那么此时的线程3本来持有锁的,锁被人删了,后面线程4就乘虚而入

这样就像线程1删了线程2的锁
线程2删了线程3的锁
线程3删了线程4的锁

这样子迭代下去,不出问题才怪

这个问题属于是线程安全问题

解决办法

解决办法的思想也很简单,既然你删错锁了,是因为你不知道此时的锁的主人是谁,你以为是自己的,那么我门只要在锁上写上一个标记,代表着此时的锁是谁的.我们去释放锁的时候,就去判断是不是自己的锁,这样就没什么问题了

代码

在这里插入图片描述
按道理来说这里不应该用线程id来当作标识,因为还是有可能会重复,所以应该用uuid来当标识才对

修改如下
在这里插入图片描述
这样就不会有可能是有重复的问题了

原子性问题的出现

我们看上面的解决办法,好像已经很不错了,但是还是有一个漏洞,那就是这里的流程 判断锁是不是自己 和 释放锁不是一个原子操作

在这里插入图片描述
我们来看这个图,就能看明白,这里是一个很极端的情况

首先线程1拿到锁,然后执行完业务,想要释放锁,按照我们的解决方法,我们获取锁,是不是自己,发现是, 就在这个瞬间,突然线程1发生了阻塞

这里的阻塞,有可能是jvm的垃圾回收所导致,或者其他

当我们阻塞的时间超过了锁的过期时间,就会超时释放锁

那么线程2也会乘虚而入,拿到锁

当线程1醒过来的时候,因为前面已经判断过了,所以就会去删线程2的锁

还是会出现误删问题!!!

当然了,出现这个问题的条件是很苛刻的,就是线程1在判断完锁是自己的时候,突然发生阻塞,并且阻塞的时间超过redis锁的过期时间

解决办法

所以我们要想解决这个棘手的问题,我们就要让判断锁是不是自己 和 释放锁变成一个原子操作

这里就引出了redis 的lua脚本,它可以做到原子性!

LUA脚本

简单的介绍lua脚本

它是一个脚本语言,有点类似于js

在这里插入图片描述

在redis中,执行lua脚本
在这里插入图片描述

这里的key 和 value可以不用写死,可以作为参数传递

特别要注意这里的KEYS,和ARGV数组,需要注意的是,这里的数组是从1开始的

解决上面的问题

先写一个lua脚本
在这里插入图片描述
脚本的意思就是判断锁 + 释放锁

原先java代码的改变

    /*** 释放锁*/private void unlock(String lockKey,String uuid) {DefaultRedisScript<Long> longDefaultRedisScript = new DefaultRedisScript<>();longDefaultRedisScript.setLocation(new ClassPathResource("unlock.lua"));longDefaultRedisScript.setResultType(Long.class);redisCache.execute(longDefaultRedisScript,Arrays.asList(lockKey),uuid);}

这里不再我的工具类里边写unlock了,这里的unlock比较特殊所以要自己写一个方法在下边

在这里插入图片描述

这样字,这样的代码就十分健壮了

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/676883.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

C#使用哈希表对XML文件进行查询

目录 一、使用的方法 1.Hashtable哈希表 2.Hashtable哈希表的Add方法 &#xff08;1&#xff09;定义 &#xff08;2&#xff09;示例 3.XML文件的使用 二、实例 1.源码 2.生成效果 可以通过使用哈希表可以对XML文件进行查询。 一、使用的方法 1.Hashtable哈希表…

证明之黄金分割比的无理性

黄金分割比的无理性 “黄金分割比的神奇之处&#xff1a;视觉化证明与数学的魅力” 人们在学习高等数学时&#xff0c;走到一个证明的结尾处&#xff0c;通常会经历这样的思考&#xff1a;“我理解每一行是怎样由前一行得到的&#xff0c;但是我却不明白为什么这个定理是正确…

【北邮鲁鹏老师计算机视觉课程笔记】01 introduction

1 生活中的计算机视觉 生活中的各种计算机视觉识别系统已经广泛地应用起来了。 2 计算机视觉与其他学科的关系 认知科学和神经科学是研究人类视觉系统的&#xff0c;如果能把人类视觉系统学习得更好&#xff0c;可以迁移到计算机视觉。是计算机视觉的理论基础。 算法、系统、框…

Sodinokibi(REvil)勒索病毒最新变种,攻击Linux平台

前言 国外安全研究人员爆光了一个Linux平台上疑似Sodinokibi勒索病毒家族最新样本&#xff0c;如下所示&#xff1a; Sodinokibi(REvil)勒索病毒的详细分析以及资料可以参考笔者之前的一些文章&#xff0c;这款勒索病毒黑客组织此前一直以Windows平台为主要的攻击目标&#xf…

c语言--指针运算

目录 一、指针-整数二、指针-指针2.1条件2.2两个指针指向同一块空间代码2.2.1运行结果 2.3两个指针指向不同块空间代码2.3.1运行结果 2.4总结 三、指针的关系运算3.1代码3.1.1运行结果3.1.2分析 一、指针整数 用数组举例&#xff1a; 因为数组在内存中是连续存放的&#xff0c…

Git版本与分支

目录 一、Git 二、配置SSH 1.什么是SSH Key 2.配置SSH Key 三、分支 1.为什么要使用分支 2.四个环境及特点 3.实践操作 1.创建分支 2.查看分支 3.切换分支 4.合并分支 5.删除分支 6.重命名分支 7.推送远程分支 8.拉取远程分支 9.克隆指定分支 四、版本 1.什…

IOS破解软件安装教程

对于很多iOS用户而言&#xff0c;获取软件的途径显得较为单一&#xff0c;必须通过App Store进行下载安装。 这样的限制&#xff0c;时常让人羡慕安卓系统那些自由下载各类版本软件的便捷。 心中不禁生出疑问&#xff1a;难道iOS世界里&#xff0c;就不存在所谓的“破解版”软件…

【机房预约系统(C++版)】

一、机房预约系统需求 1.1、系统简介 学校现有几个规格不同的机房&#xff0c;由于使用时经常出现“撞车“现象,现开发一套机房预约系统&#xff0c;解决这一问题。 1.2、身份简介 分别有三种身份使用该程序学生代表:申请使用机房教师:审核学生的预约申请管理员:给学生、教…

【Java八股面试系列】并发编程-并发关键字,线程池

目录 并发关键字 Synchronized synchronized最主要的三种使用方式&#xff1a; 具体使用&#xff1a;双重校验锁单例模式 synchronized 底层实现原理&#xff1f; synchronized锁的优化 偏向锁 轻量级锁 重量级锁 Mark Word 与 Monitor 之间的关系 总结 偏向锁、轻量…

蓝桥杯刷题day08——完全日期

1、题目描述 如果一个日期中年月日的各位数字之和是完全平方数&#xff0c;则称为一个完全日期。 例如&#xff1a;2021年6月5日的各位数字之和为20216516&#xff0c;而16是一个完全平方数&#xff0c;它是4的平方。所以2021年6月5日是一个完全日期。 请问&#xff0c;从200…

操作系统(13)-----文件管理

目录 一.内存映射文件 传统的文件访问方式&#xff1a; 内存映射文件&#xff1a; 内存映射文件与传统文件访问方式的区别&#xff1a; 文件共享的实现&#xff1a; 内存映射文件的优点&#xff1a; 二.文件的属性 三.文件的逻辑结构 1.无结构文件 2.有结构文件 四.…

书生·浦语大模型全链路开源体系

参考&#xff1a;https://www.bilibili.com/video/BV1Rc411b7ns/?spm_id_from333.788&vd_source3bbd0d74033e31cbca9ee35e111ed3d1 背景&#xff1a; 人工智能的发展从针对特定任务&#xff0c;用一个模型解决一个问题过渡到一个模型来应对多模态、多任务&#xff0c;大模…

门诊单据打印用什么软件,线下处方单生成系统教程

门诊单据打印用什么软件&#xff0c;线下处方单生成系统教程 一、前言 以下软件教程以 佳易王诊所电子处方管理系统软件V17.3为例说明 软件文件下载可以点击最下方官网卡片——软件下载——试用版软件下载 如上图&#xff0c;电子处方或病历记录开单生成保存后&#xff0c;可…

【数学建模】【2024年】【第40届】【MCM/ICM】【A题 七鳃鳗性别比与资源可用性】【解题思路】

我们通过将近半天的搜索数据&#xff0c;查到了美国五大湖中优势物种的食物网数据&#xff0c;以Eric伊利湖为例&#xff0c;共包含34各优势物种&#xff0c;相互之间的关系如下图所示&#xff1a; 一、题目 &#xff08;一&#xff09; 赛题原文 2024 MCM Problem A: Reso…

推荐几个Python爬虫接单渠道

前言 平时工作有闲的家人们&#xff0c;今天给大家推荐一些用Python爬虫做私活的渠道&#xff01; 【Python爬虫学习资料】 先给各位还不熟悉Python爬虫的朋友介绍一下&#xff01; 可以短时间获得大量资料~ 可以进一步数据分析 当然也可以获得收益&#xff01; 学会Python…

第十七篇【传奇开心果系列】Python的OpenCV库技术点案例示例:自适应阈值二值化处理图像提取文字

传奇开心果短博文系列 系列短博文目录Python的OpenCV库技术点案例示例系列短博文目录前言一、自适应阈值二值化处理图像提取文字轮廓的初步示例代码:二、扩展思路介绍三、调整自适应阈值二值化的参数示例代码四、对二值化图像进行形态学操作示例代码五、使用轮廓特征进行筛选示…

113.路径总和 II

给你二叉树的根节点 root 和一个整数目标和 targetSum &#xff0c;找出所有 从根节点到叶子节点 路径总和等于给定目标和的路径。 叶子节点 是指没有子节点的节点。 示例 1&#xff1a; 输入&#xff1a;root [5,4,8,11,null,13,4,7,2,null,null,5,1], targetSum 22 输出&a…

【开源】JAVA+Vue+SpringBoot实现实验室耗材管理系统

目录 一、摘要1.1 项目介绍1.2 项目录屏 二、功能模块2.1 耗材档案模块2.2 耗材入库模块2.3 耗材出库模块2.4 耗材申请模块2.5 耗材审核模块 三、系统展示四、核心代码4.1 查询耗材品类4.2 查询资产出库清单4.3 资产出库4.4 查询入库单4.5 资产入库 五、免责说明 一、摘要 1.1…

RocketMQ客户端实现多种功能

目录 RocketMQ客户端基本流程 消息确认机制 1、消息生产端采用消息确认加多次重试的机制保证消息正常发送到RocketMQ 单向发送 同步发送 异步发送 2、消息消费者端采用状态确认机制保证消费者一定能正常处理对应的消息 3、消费者也可以自行指定起始消费位点 广播消息 …

【Web】基于Mybatis的SQL注入漏洞利用点学习笔记

目录 MyBatis传参占位符区别 不能直接用#{}的情况 in多参数值查询 like %%模糊查询 order by列名参数化 MyBatis传参占位符区别 在 MyBatis 中&#xff0c;#{} 和 ${} 都是用于传参的占位符&#xff0c;但它们之间有很大的区别&#xff0c;主要体现在两个方面&#xff1a…