【电商经验】之商品下单减库存方案

一、下单减库存方案

在电商项目中设计商品下单减库存时有两种典型的方案：

• 下单后减库存
• 付款后减库存

这两种减库存方案都有各自的优缺点，没有说哪种是最好的，主要看业务场景适合哪种。

1、下单后减库存

用户下单生成一个订单后，库存减一。这种情况下，买家是并没有完成付款，没有走完订单流程的。这种方案存在两个问题：

1）恶意下单

当用户量比较大的时候就会出现恶意下单的情况，即只下单，不付款。对于这种问题，可以设置一个订单超时时间，超过一定时间没有没成付款的话订单就失效，然后库存返回。

2）抢占库存

在限量商品热卖的时候（比如促销），因为一部分人下了单但没有付款完成订单流程，导致其他用户看到已售罄（实际意义上是有库存的），这样就会在某个时间点阻止其他用户购买。对于这种问题可以设置一个提示，下单未付款状态就提示“其他用户正在付款中”，付款完成后就移除提示。

2、付款后减库存

当用户下单并完成付款后再扣减库存，也就是在付款的时候才校验库存数量。这种方案可以避免掉下单减库存的所有问题，但会产生新的问题，即“超卖”：用户下单时有货，付款时却提示没货。

这两种方案正常情况下选择第一种：下单后减库存。第二种在热点商品促销时容易产生大量的的超卖。

二、订单系统设计

在处理下单和扣减库存业务逻辑时，是先操作订单数据还是先操作库存数据？

答案是：先操作订单数据再操作库存数据。

以 MySQL 为例，下单就是生成并往订单表 insert 一条数据，insert 插入是行级锁，支持每秒高达 4W 的并发。而更新库存数据就是 udate 操作，命中索引时也是行级锁，但是这是个独占锁，所有的操作都要等待前一个释放锁后才能继续 update。

而根据 MySQL 的两段锁协议，我们应该把热点操作放到离事务 commit 近的位置，这样可以减少行级锁的持有时间，自然处理效率就更好一些。而这两个操作都是在同一个事务中，操作流程如下：

事务开始 -> insert订单 -> 其他逻辑操作 -> update库存 -> 事务提交。