大家好，我是冰河~~
在【精通高并发系列】的《实践出真知：全网最强秒杀系统架构解密！！》一文中，冰河详细的阐述了高并发秒杀系统的架构设计，也简单提到了如何扣减商品的库存。
也许不少小伙伴会问：扣减商品的库存很简单啊，用户下单的时候扣除对应的商品库存不就行了吗？有那么难吗？
确实，理论上就是用户下单后，减去商品的库存就完事了。但是，如果你的系统流量很大，并发度非常高，比如淘宝的双十一，有一款爆款商品参加了活动，库存只有1000件，有几十万上百万用户抢购，商品售完1000件为止，一件不能多，一件也不能少。你还会觉得简单吗？搞不好就会出现“超卖”的情况，后果就会很严重了。
今天，我们就一起来简单讨论下在高并发秒杀系统中，如何正确的扣减商品的库存。
扣减库存的方式
为了方便大家的理解，我们先来讨论下扣减库存有哪几种方式。总体来说，扣减库存可以分为：下单减库存、付款减库存和预扣库存三种。
下单减库存
我们先来说说下单扣减库存的方式，这种方式很好理解，就是用户提交订单后，在商品的总库存中减去用户购买的商品数量。这种减库存的方式是最简单的，也是对商品库存控制的最准确的。但是，经常会碰到的问题就是：用户提交订单之后，未必就会付款。
这就会存在一个问题：恶意刷单。试想，你作为一个商家参与了淘宝的双十一秒杀活动，如果淘宝平台扣减库存的方式为下单减库存，你的竞争对手得知你参与了双十一秒杀活动，他们通过恶意下单的方式将你参与秒杀的商品全部下单，让你的库存减为0，但是他们并不会付款。那么你参与双十一秒杀的商品就不能正常售卖了。
此时的你会是什么样的心情呢？这就是下单减库存存在的问题。
付款减库存
既然下单减库存存在问题，我们再来看看付款减库存。库存减库存就是用户提交订单后，并不会立刻扣减商品的库存。而是等到用户真正付款后才会扣减库存。这种方式经常遇到的问题就是：用户明明下单成功了，却不能付款。 原因就是用户下单时，不会扣减库存，而是等到真正付款后才会扣减库存，当某个用户下单后，执行付款操作时，相应的商品可能已经被其他人买走了。
付款减库存有可能会造成另一个更为严重的后果：**库存超卖。**这主要就是用户提交订单的时候不会扣减库存，造成用户成功下单的订单数量可能会远远大于商品的库存数量。
预扣减库存
预扣减库存比起前面两种扣减库存的方式，相对来说复杂一些。用户提交订单后，为用户预留购买数量的商品库存，例如预留10分钟，超过10分钟，则释放为用户预留的库存，其他的用户可以继续下单购买。
用户下单预扣减库存之后，在付款时，系统会检验对应的订单是否存在有效的预留库存，如果存在，则真正扣减库存并付款。如果不存在，则会再次尝试预扣减库存。如果库存不足，则不再付款。如果预扣减库存成功，则真正扣减库存并付款。
那么，预扣减库存是否能够解决前面两种扣减库存的问题呢？
答案是，并没有彻底解决。
例如，对恶意下单来说，虽然将有效的付款时间控制在一小段时间内，但是恶意用户完全有可能在一段时间后再次下单。也有可能会在开始下单时，就会一次性选择所有的库存下单。仍然不能彻底解决问题。
那有没有什么办法解决这些问题呢？我们继续往下看。
扣减库存问题的解决
针对恶意用户下单的情况，我这里简单罗列了如下几种解决方案：
（1）我们可以为经常提交订单之后不付款的用户添加对应的标签，当这些用户下单时，进行特殊处理，例如不扣减库存等（具体可以根据需求确定）。
（2）在秒杀期间，为商品设置同一个人的最大购买件数，比如最多购买2件。
（3）对不付款重复下单的操作进行限制，例如，对同一商品下单时，首先校验当前用户是否存在未付款的订单，并且订单中的商品与再次下单的商品是同一款商品，则提示先让用户付款后再提交订单等。
针对库存超卖的情况，我这里简单罗列了如下几种解决方案：
（1）通过补货解决。
（2）用户下单时提示库存不足。
秒杀系统如何扣减库存？
也许有不少小伙伴会说高并发秒杀系统会采用预扣减库存的方式，其实，在真正的高并发、大流量场景下，大部分秒杀系统会采用 下单减库存 的方式。
在下单扣减库存的业务场景中，需要保证大流量、高并发下商品的库存不能为负。
这里，我们可以通过如下方案解决商品库存不能为负的问题、
（1）在扣减库存后，通过在应用程序的事务中判断商品库存是否为负数，如果变成了负数，则回滚事务不再扣减库存。
（2）在数据库中设置库存字段为无符号整数，从数据库层面保证无法出现负数的情况。
说了这么多，原来在高并发、大流量的秒杀系统中，实现正确的扣减商品的库存确实不是一件容易的事情呀！
