电商库存系统的防超卖和高并发扣减方案

摘要：如果你要开发一个电商库存系统，最担心的是什么？闭上眼睛想下，当然是高并发和防超卖了！本文给出一个统筹考虑如何高并发和防超卖数据准确性的方案。读者可以直接借鉴本设计，或在此基础上做出更切合使用场景的设计。

下面用电商库存为示例，来说明如何高并发扣减库存，原理同样适用于其他需要并发写和数据一致性的场景。

库存数量模型示例

为了描述方便，我们使用简化的库存数量模型，真实场景中库存数据项会比我的示例多很多，但已经够说明原理。如下表，库存数量表(stockNum)包含商品标识和库存数量两个字段，库存数量代表有多少货可以卖。

| 字段名 | 英文名 | 字段类型 | | -------- | ------ | -------- | | 商品标识 | skuId | 长整型 | | 库存数量 | num | 整数 |

传统通过数据库保证不超卖

库存管理的传统方案为了保证不超卖，都是使用数据库的事务来保证的：通过Sql判断剩余的库存数够用，多个并发执行update语句只有一个能执行成功；为了保证扣减不重复，会配合一个防重表来防止重复的提交，做到幂等性，防重表示例(antiRe)设计如下：

| 字段名 | 英文名 | 字段类型 | | ------ | ------ | ------------------ | | 标识 | id | 长整型 | | 防重码 | code | 字符串(唯一索引) |

比如一个下单过程的扣减过程示例如下：

事务开始 Insert into antiRe(code) value (‘订单号+Sku’) Update stockNum set num=num-下单数量 where skuId=商品ID and num-下单数量>0 事务结束

面临系统流量越来越大，数据库的性能瓶颈就会暴露出来：就算分库分表也是没用的，促销的时候高并发都是针对少量商品的，最终并发流量会打向少数表，只能去提升单分片的抗量能力。我们接下来设计一种使用Redis缓存做库存扣减的方案。

综合使用数据库和Redis满足高并发扣减的原理

扣减库存其实包含两个过程：第一步是超卖校验，第二步是扣减数据的持久化；在传统数据库扣减中，两步是一起完成的。抗写的实现原理其实是巧妙的利用了分离的思想，分离开防超卖和数据持久化；首先防超卖是由Redis来完成的；通过Redis防超卖后，只要落库就可以；落库通过任务引擎，业务数据库使用商品分库分表，任务引擎任务通过单据号分库分表，热点商品的落库会被状态机分散开，消除热点。

整体架构如下：

第一关解决超卖检验：我们可以把数据放入Redis中，每次扣减库存，都对Redis中的数据进行incryby 扣减，如果返回的数量大于0，说明库存够&#