高并发超卖问题简要解决方案
1、传统通过数据库保证不超卖事务+行锁并不是解决超卖的方案,只是保障数据的统一性。传统通过回滚事务的方式防止某些用户多卖的情况。采用新建一个防重表+事务的方式防止超卖。同一事务中,采用如 用户ID+商品ID的方式作为防重表唯一索引字段的数值,保障超卖时事务的统一回滚。字段名字段类型字段说明id长整型主键code字符串(唯一索引)防重码//事务开始Insert into 防重表(code) ...
1、传统通过数据库保证不超卖
事务+行锁并不是解决超卖的方案,只是保障数据的统一性。传统通过回滚事务的方式防止某些用户多卖的情况。
采用新建一个防重表+事务的方式防止超卖。同一事务中,采用如 用户ID+商品ID 的方式作为防重表唯一索引字段的数值,保障超卖时事务的统一回滚。
字段名 | 字段类型 | 字段说明 |
---|---|---|
id | 长整型 | 主键 |
code | 字符串(唯一索引) | 防重码 |
//事务开始
Insert into 防重表(code) value (‘用户ID+商品ID’)
Update 库存表 set num=num-1 where goodId=商品ID and num>0
//事务结束
该方案在采用 num>0 防止库存负值的出现,需要额外创建防重表防止重复提交。但在有调用外部接口如微信支付时,需要有回滚机制。
2、采用RateLimiter限流有效降低并发超卖概率
private RateLimiter orderCreateRateLimiter;
@PostConstruct
public void init(){
orderCreateRateLimiter = RateLimiter.create(300);
}
//以下为下单方法里面代码开始部分添加
if(!orderCreateRateLimiter .tryAcquire()){
//返回活动太火爆稍后再试
}
该方案只为降低并发,并非解决超卖方案,需结合使用,并每秒令牌数量需要根据系统实际性能评估。
3、采用redis的incrby特性
a、解决超卖检验:我们可以把数据放入Redis中,每次扣减库存,都对Redis中的数据进行incryby 扣减,如果返回的数量大于0,说明库存够,因为Redis是单线程,可以信任返回结果。
b、库存扣减不需要再判断数量是否足够,只需要傻瓜扣减库存就行,对数据库执行如下语句,当然还是需要处理防重幂等的,不需要判断数量是否大于0了,扣减SQL只要如下写就可以。
//事务开始
Insert into 防重表(code) value (‘用户ID+商品ID’)
Update 库存表 set num=num-1 where goodId=商品ID
//事务结束
4、基于Redis以及Mysql瓶颈的升级方案
如何使用Redis实现电商系统的库存扣减?_spring_root的博客-CSDN博客_redis 库存在日常开发中有很多地方都有类似扣减库存的操作,比如电商系统中的商品库存,抽奖系统中的奖品库存等。解决方案使用mysql数据库,使用一个字段来存储库存,每次扣减库存去更新这个字段。还是使用数据库,但是将库存分层多份存到多条记录里面,扣减库存的时候路由一下,这样子增大了并发量,但是还是避免不了大量的去访问数据库来更新库存。将库存放到redis使用redis的incrby特性来扣减库存。分析在上面的第一种和第二种方式都是基于数据来扣减库存。基于数据库单库存第一https://blog.csdn.net/baidu_39322753/article/details/119295670
更多推荐
所有评论(0)