商品秒杀系统思路

1、使用CAS乐观锁解决秒杀超卖问题。

一开始使用库存,但是发现库存,结果发现没卖完。然后就通过CAS判断库存大于0。

2、又发现问题,一个用户可以下好几单,所以想到用商品id和用户id做个唯一索引,解决了,但是后面发现,我再开同一个商品的秒杀,之前的用户不能抢到了。

所以使用悲观锁,将用户的id锁住

锁在事务外面

Spring中事务是通过代理对象去实现的事务的,但是现在这个相当于是用this调用的,所以事务会失效。通过AopContext获取代理对象

这样就能解决秒杀超买问题了

改进使用分布式锁

获取锁和释放锁

业务上加上分布式锁

但是会出现释放错锁的问题(生成有一个uuid,与线程id做个拼接,获取释放锁的时候进行判断)

解决原子性问题(用lua脚本)

分布式锁缺点

Redission解决

直接使用即可(不需要封装lua脚本)

3、优化(使用lua脚本预扣库存,如果有,并加入消息队列里面)

改造秒杀业务

再利用rabbitMQ去完成异步下单操作。

也可以使用stream去实现

消息队列stream

4、解决用互斥锁解决缓存击穿问题(使用秒杀商品id做一个分布式锁)seckGood:+"GoodId"

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值