订单减库存设计

标签：red   部分   下单   div   库存量   用户   就是   tar   库存   

一、扣减库存的三种方案

（1）下单减库存
　　用户下单时减库存

　　优点：实时减库存，避免付款时因库存不足减库存的问题

　　缺点：恶意买家大量下单，将库存用完，但是不付款，真正想买的人买不到

（2）付款减库存
　　下单页面显示最新的库存，下单时不会立即减库存，而是等到支付时才会减库存。

　　优点：防止恶意买家大量下单用光库存，避免下单减库存的缺点

　　缺点：下单页面显示的库存数可能不是最新的库存数，而库存数用完后，下单页面的库存数没有刷新，出现下单数超过库存数，若支付的订单数超过库存数，则会出现支付失败。

（3）预扣库存
　　下单页面显示最新的库存，下单后保留这个库存一段时间（比如10分钟），超过保留时间后，库存释放。若保留时间过后再支付，如果没有库存，则支付失败。例如：要求30分钟内支付订单。

　　优点：结合下单减库存的优点，实时减库存，且缓解恶意买家大量下单的问题，保留时间内未支付，则释放库存。

　　缺点：保留时间内，恶意买家大量下单将库存用完。并发量很高的时候，依然会出现下单数超过库存数。

二、如何解决恶意买家下单的问题

这里的恶意买家指短时间内大量下单，将库存用完的买家。

（1）限制用户下单数量
　　优点：限制恶意买家下单

　　缺点：用户想要多买几件，被限制了，会降低销售量

（2）标识恶意买家
　　优点：卖家设定一个备用库存，当支付时，库存已用完，扣减备用库存数，这就是常见的补货场景

　　缺点：因高并发场景下，数据可能存在不一致性的问题

三、如何解决下单成功而支付失败（库存不足）的问题

（1）备用库存
　　商品库存用完后，如果还有用户支付，直接扣减备用库存。

　　优点：缓解部分用户支付失败的问题

　　缺点：备用库存只能缓解问题，不能从根本上解决问题。另外备用库存针对普通商品可以，针对特殊商品这种库存少的，备用库存量也不会很大，还是会出现大量用户下单成功却因库存不足而支付失败的问题。

四、如何解决高并发下库存超卖的场景

库存超卖最简单的解释就是多成交了订单而发不了货。

场景：

用户A和B成功下单，在支付时扣减库存，当前库存数为10。因A和B查询库存时，都还有库存数，所以A和B都可以付款。

A和B同时支付，A和B支付完成后，可以看做两个请求回调后台系统扣减库存，有两个线程处理请求，两个线程查询出来的库存数 inventory=10，

然后A线程更新最终库存数 lastInventory=inventory - 1 = 9，

B线程更新库存数 lastInventory=inventory - 1 = 9。

而实际最终的库存应是8才对，这样就出现库存超卖的情况，而发不出货。

那如何解决库存超卖的情况呢？

1.SQL语句更新库存时，如果扣减库存后，库存数为负数，直接抛异常，利用事务的原子性进行自动回滚。

2.利用SQL语句更新库存，防止库存为负数

1.  
   UPDATE [库存表] SET 库存数 - 1 WHERE 库存数 - 1 > 0
2.  
    
3.  
   如果影响条数大于1，则表示扣减库存成功，否则订单失败，并退款。

五、秒杀场景下如何扣减库存

（1）下单减库存
因秒杀场景下，大部分用户都是想直接购买商品的，可以直接用下单减库存。

大量用户和恶意用户都是同时进行的，区别是正常用户会直接购买商品，恶意用户虽然在竞争抢购的名额，但是获取到的资格和普通用户一样，所以下单减库存在秒杀场景下，恶意用户下单并不能造成之前说的缺点。

而且下单直接扣减库存，这个方案更简单，在第一步就扣减库存了。

（2）将库存放到redis缓存中
　　查询缓存要比查询数据库快，所以将库存数放在缓存中，直接在缓存中扣减库存。然后在通过MQ异步完成数据库处理。

（3）使用量自增方式
可以先增加已使用量，然后与设定的库存进行比较，如果超出，则将使用量减回去。

项目中用到了很多机制，但是没有总结出来，学习架构需要不断地总结。

六 第三方支付

1 支付成功多次回调：把减库存放在微信支付的成功回调URL的方法里面。但是微信支付成功之后微信支付平台会发送8次请求到回调地址。这样的做法就会导致库存减少，一定要验证返回的编号是否已经完成扣减。

订单减库存设计

标签：red   部分   下单   div   库存量   用户   就是   tar   库存   

原文地址：https://www.cnblogs.com/lichihua/p/10803305.html