今天我们就来探讨一下存货抵扣方案。生活中，我们总是会通过各种电商APP抢购商品，但是存货很少，尤其是在闪购场景中，可能只有一件商品，那么如何保证不会出现超卖的情况呢？1.扣减库存三种选择1.1下单时减库存优点：实时减库存，避免付款时因库存不足而减库存的问题缺点：恶意买家大量下单，用完库存，但是不付钱，真想买的人是买不到的。1.2付款减少库存订单页面显示的是最新库存，下单时不会立即减少库存，但会在付款时减少库存。优点：防止恶意买家大量下单耗尽库存，避免因下单减少库存。缺点：订单页面显示的库存号可能不是最新的库存号。刷新，如果下单数量超过库存数量，支付订单数量超过库存数量，支付失败。1.3预留库存订单页面显示最新库存，下单后库存会保留一段时间（如10分钟）。超过保留时间后，库存将被释放。如果您在预订时间之后付款，如果没有库存，付款将失败。优势：结合下单减少库存的优势，实时减少库存，缓解买家恶意下单大量下单的问题。如果未在保留期内付款，库存将被释放。劣势：预订期间，恶意买家大量下单导致库存耗尽。当并发量高的时候，下单的数量还是会超过股票的数量。2、如何解决恶意买家下单问题这里的恶意买家是指短时间内大量下单，库存耗尽的买家。2.1限制用户下单数量优点：限制恶意买家下单缺点：用户想多买几件，会被限制，会降低销量2.2识别恶意买家通过识别用户的设备id或会员id,添加用户黑名单的缺点是有些用户是模拟的，无法识别他们是否是真正的恶意买家。3、如何解决下单成功但支付失败（库存不足）的问题3.1备用库存用完后，如仍有用户付款，将直接扣除备用库存。优点：缓解部分用户支付失败问题。缺点：备货只能缓解问题，不能从根本上解决问题。另外，普通商品可以使用备用库存，但对于库存低的特殊商品，备用库存不会很大，仍然会出现大量用户下单成功但付款失败的问题由于库存不足。4.高并发下库存超卖场景如何解决库存超卖最简单的解释就是订单卖多了，无法发货。场景用户A和B成功下单，支付时扣掉库存，当前库存为10。由于A和B都查询了库存，还有库存，所以A和B都可以支付。A和B同时付款。A、B支付完成后，可以看做是两次请求回调后台系统扣除库存。有两个线程处理请求，两个线程查询到的库存数量为inventory=10。然后线程A更新最终库存：lastInventory=inventory-1=9，线程B更新库存：lastInventory=inventory-1=9.但是实际最终库存应该是8个，这样一来库存就超卖了，无法发货。那么如何解决库存超卖的情况呢？下面的解决方案都是基于数据库层面的。可能有同学会问是否可以使用Redis分布式锁，这个后面会讲到。方案1SQL语句直接更新库存，而不是先查询，然后赋值UPDATE[inventorytable]SETinventorynumber-1.用方案2的SQL语句更新库存时，如果库存号扣除inventory，直接抛出异常，利用事务的原子性自动回滚。解决方案3使用SQL语句更新库存，防止库存为负。5.闪购场景下如何降低库存5.1使用订单降低库存因为在闪购场景下，大部分用户是想直接购买商品，下单就可以直接降低库存。大量用户和恶意用户同时进行。不同的是，普通用户会直接购买产品。恶意用户虽然在争夺抢购名额，但他们拥有与普通用户相同的资格。用户的订单不会造成上述缺点。而且，订单直接从库存中扣除。这个方案比较简单，第一步扣库存。5.2Redis缓存查询缓存比查询数据库快，所以把存货号放到缓存里，直接从缓存中扣除存货。5.3限流秒杀场景，对请求进行了很多限流操作，比如前端页面限流，后端令牌桶限流。到了扣库存这一步，请求的数量就很少了。因此，限流常用于秒杀方案中。感觉可以再写一篇限流的文章。另外，在实际项目中，更多的是采用机制来保证库存能够正常抵扣。本文以抛砖引玉的方式介绍。希望大家提出宝贵的建议和解决方案~。呈现闪杀场景方案总结：本文转载自微信公众号“悟空聊天架构”，可通过以下二维码关注。转载本文请联系WukongChatArchitecture账号。
