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
电商库存系统的防超卖和高并发扣减方案_qryc的博客-CSDN博客_数据库防止超卖引言如果你要开发一个电商库存系统，我最担心的是什么？闭上眼睛想下，当然是高并发和防超卖了！本文给出一个统筹考虑如何高并发和防超卖数据准确性的方案。读者可以以此为思考原点，或直接使用本设计，或在此基础上做出更有的设计。下面用电商库存为示例，来说明如何高并发扣减库存，原理同样适用于其他需要并发写和数据一致性的场景。库存数量模型示例为了描述方便，我们使用简化的库存数量模型，真实场景中库存数据项会比我的示例多很多，但已经够说明原理。如下表，库存数量表(stockNum)包含商品标识和库存数量两个字段https://blog.csdn.net/qrycf/article/details/119462589
