电商超卖问题，redis decr能作为防止超卖的解决方案吗？
-2
悬赏园豆：20
[待解决问题]
电商超卖问题，redis decr能作为防止超卖的解决方案吗？
在网上查了不少资料，感觉好多文章对这个问题并没有说清楚。
比如这个帖子的讨论：https://bbs.csdn.net/topics/397658929?list=28802678
注意：redis decr的方案里，redis的库存有可能变成负数的。但redis的库存出现负数也许是可以允许的？只要数据库的库存没有被减成负数就行。如果redis的值出现负数，告诉用户已经抢购完就行了。
我的问题：
1.如果redis decr不能作为超卖解决方案，原因？
2.如果redis decr能作为超卖解决方案，分布式锁时另一个方案。redis decr的性能肯定要比分布
式锁要好，那肯定是优先选redis decr的方案，分布式锁在高并发情况下性能较差。既然redis decr方案能解决，那为什么那么多文章都大谈分布式锁方案，把分布式锁方案当成主流呢？
3.分布式锁方案性能是比较差的。大厂的超高并发，如果用分布式锁方案，性能可能比较差？那大厂的解决方案一般是什么呢？
所有回答(1)
0
- 如果是单纯的用来控制并发减 redis.decr 一定是原子性的.
- 单纯的inc + dec 不能增减库存. 例如我订单取消释放的库存怎么加回去. 这就直接卡死这个方案了.
2.1. 当然, 我们可以用lua脚本来实现. 脚本内dec, 如果是减到了负数就再inc回去. 并返回false.
2.2. 也可以在库存有变化(取消订单要增加)时直接set 真实的库存数量 到redis. - 往往我们的业务是复杂的, 例如涉及到多个商品打包订单(每个商品库存不一样)等很多case, redis.decr方案也支持不了.
所以, 综上所述. 单纯的redis.incr方案不能作为常规的超卖控制逻辑业务解决方案.
方式发锁方案有很多实现: 基于redis的, 基于数据库, zk等都可以.
在不同的高并发和业务等级下可以用不同的实现, 配合不同的限流, 分封而治 等方案.
比如说常规业务用分布式锁, 例如单品抢购就可以用2.1, 2.2方案.
