万级并发！电商库存扣减如何设计，如何做到不超卖？ _电商库存扣减

文章插图

前言：
随着中国消费认知的不断升级，网购走近千家万户，越来越被人们所接受。淘宝、唯品会、考拉、京东、拼多多等逐渐成为我们生活的重要组成部分。
除了常规的购物下单外，这些电商平台还经常搞一些双十一活动，秒杀、大促、限时购，各种营销玩法，层出不穷！今天就来跟大家聊一聊电商技术里的库存扣减。

文章插图

当有很多人同时在买一件商品时（假设库存充足），每个人几乎同时下单成功，给人一种并行的感觉。但真实情况，库存只是一个数值，无论是存在MySQL数据库还是redis缓存，减值时都要控制顺序，只能串行来扣减，当然为了保证安全性，会设计一些锁控制操作。
palm_tree: 库存扣减关键技术点

同一个SKU，库存数量是共享
剩余库存要大于等于本次扣减的数量，否则会出现超卖现象，引发资损
对同一个数量多用户并发扣减时，要注意并发安全，保证数据的一致性
类似于秒杀这样高QPS的扣减场景，要保证性能与高可用
对于购物车下单场景，多个商品库存批量扣减，要保证事务
如果有交易退款，保证库存扣减可以返还
- 返还的数据总量不能大于扣减的总量
- 返还要保证幂等
- 可以分多次返还

palm_tree: 数据库扣减方案主要是依赖数据库特性来保证扣减的一致性，逻辑简单，开发部署成本很低。
依赖的数据库特性：

依赖数据库的乐观锁（比如：版本号或者库存数量）保证数据并发扣减的强一致性
借助事务特性，针对购物车下单批量扣减时，部分扣减失败，数据回滚

文章插图

最上面会查询当前的剩余库存（可能不准确，但没关系，这里只是第一步粗略校验），前置校验，如果已经没有库存，前置拦截生效，减少对数据库的写操作。毕竟读操作不涉及加锁，并发性能高。数据库包含两张表：库存表、流水表。
1、库存表字段
说明
sku_id
商品规格id
leaved_amount
剩余可购买数量

当用户进行取消订单、申请退货退款，需要把数量加回来
如果商家补过库存，需要在此基础上额外加上增量库存

2、流水表字段
说明
id
主键id
sku_id
商品规格id
order_detail_id
订单明细id
quantity_trade
本次购买扣减的数量

用于查看明细、对账、盘货、排查问题等
在扣减后，某些场景下需要返还也依赖流水

单条商品的扣减SQL大致如下：update inventory set leaved_amount = leaved_amount - #{count} where sku_id='123' and leaved_amount >= #{count}此 SQL 采用类似乐观锁的方式实现了原子性，在 where 条件里判断此次购买的数量小于等于剩余的数量。在扣减服务的代码里，判断此 SQL 的返回值，如果值为 1 ，表示扣减成功。否则，返回 0 ，表示库存不足，需要回滚。
扣减成功后，需要记录扣减流水，并与订单明细记录做关联。

当用户归还数量时，需要带回此编号，用来标识此次返还属于历史上的具体哪次扣减。
进行幂等性控制。当用户调用扣减接口出现超时时，因为用户不知道是否成功，用此编号进行重试或反查。在重试时，使用此编号进行标识防重。

palm_tree: 【数据库扣减方案】第一次升级举个极端的例子：最新款iphone秒杀，库存只有5件，活动期间峰值QPS预估在10W，活动结束后，上面的流水表最终只会插入5条记录，但是查询的QPS却接近 10W QPS ，读的压力非常大。
所以，数据库扣减方案第一次升级主要是针对库存前置校验模块的优化，作为前置拦截器，承载的流量很大，如果将流量全部压到主库上，很容易把数据压垮。我们考虑把数据库架构升级。