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
//事务结束