vivo全球商城：库存系统架构设计与实践

库存系统是电商商品管理的核心系统，本文主要介绍vivo商城库存中心发展历程、架构设计思路及应对各种业务场景的实践。

vivo商城原库存系统耦合在商品系统，考虑到相关业务逻辑复杂度越来越高，库存做了服务拆分，在可售库存管理的基础上新增了实物库存管理、秒杀库存、物流时效 、发货限制、分仓管理等功能，满足了商城库存相关业务需求。

本文将介绍vivo商城库存系统架构设计经验以及一些问题的解决方案。

根据vivo大电商的销售渠道与业务场景可以将库存业务架构分为3个层级：仓库层、调度层以及销售层。

仓库层对应实体仓库，包括自营仓库、顺丰仓等第三方仓库以及WMS系统、ERP系统等；调度层负责库存调度与订单发货管理；销售层包含多个服务终端，vivo官方商城、vivo门店、第三方电商分销渠道等。其分层结构如图所示：

• 优点是：不受恶意下单影响。

• 缺点是：当支付订单数大于实际库存，会阻断部分用户支付，影响购物体验。比如说只有100台手机，但可能下了1000个订单，但有900个订单在支付时无法购买。

从用户体验考虑，我们采用的是下单时扣库存 + 回退这种方案。

下单时扣减库存，但只保留一段时间（比如15分钟），保留时间段内未支付则释放库存，避免长时间占用库存。

库存回退基于库存变更日志逐个回退。

库存回退基本流程：订单出库前用户申请退款，回退可售库存、回退预占库存、软删除扣减日志、增加回退日志；一旦商品出库，用户申请退货走处理机流程，可售库存和实物库存均不回退。

发货限制分地区限制时间限制。

• 地区限制：根据收货地址批量设置部分区域无法发货等规则，粒度到省市区维度。

• 时间限制：仓库的发货时效管理，包括每天的发货时段、大促发货时段、以及特殊情况下的停发时段。

本系统采用的是保证接口幂等性的方案。

在库存扣减接口入参中增加订单序列号作为唯一标识，库存扣减时增加一条扣减日志。当接口重复请求时，会优先校验是否已经存在扣减记录，如果已存在则直接返回，避免重复扣减问题，具体流程如下：

该方案的优点是：

•  实库实扣，不会出现超卖；

• 数据库乐观锁保证并发扣减一致性；

• 数据库事务保证批量扣减正常回滚。

该方案的缺点是：

• 行级锁的原因存在性能瓶颈，高并发会出现请求堵塞超时问题；

• 直连数据库，每次扣库存都是写操作，接口性能较低。

该方案的优点是：

减轻数据库压力，同时还能确保不会超卖。

该方案的缺点是：

每次只能有一个请求抢占锁，不能应对高并发场景。

针对高并发库存扣减，比如秒杀，一般采用的是缓存扣减库存的方式（redis+lua脚本实现单线程库存更新）作为前置流程，代替数据库直接更新。

在redis中扣减库存虽然性能高，可以大大减轻数据库压力，但需要保证缓存数据能完整、正确的入库，以保证最终一致性。

针对缓存数据更新至数据库，目前主流方案有两种：

优点：简单、没有复杂的流程。

缺陷：redis宕机或者故障，可能会造成缓存内库存数据的丢失。

对于疑问1：由于数据库insert比update性能优，insert是在表的末尾直接插入，没有寻址的过程，可以保证性能比较快。

对于疑问2：方案2不同于缓存直接扣减，而是把缓存扣减放在数据库insert的事务内，通过数据库的事务保证整体的事务。

insert的表被称为库存任务表，其中保存了库存扣减的信息，库存任务表结构可以设计的非常简单，主键 + 库存信息（json字符串）就可以了。

后续通过异步任务，从库存任务表表中查询出库存更新信息，将其同步到具体的库存表中，实现最终一致性，这种方案可以避免数据的丢失。

对于疑问3：库存回退是根据业务库中扣减记录进行回退的，由于异步更新业务库必定存在延迟（延迟极低，数秒以内），所以极端场景会存在走退款逆向流程时业务库的库存扣减记录还未更新。

针对这种情况库存回退设置延迟重试机制，如果再极端点达到重试阈值依旧没有扣减记录，则返回回退成功，不做阻断。

目前我们针对秒杀库存扣减，采用的是方案2。但毕竟涉及数据库的更新，为了避免风险，在前置流量校验上做了限制，保证流量的可控：

对于潜在的热点爆款手机，我们会将库存平均分为多行（比如M行），扣减库存时，随机在M行中选取一行库存数据进行扣减。该方案突破了数据库单行锁的瓶颈限制，解决了爆款商品的热点问题。

对于第2种redis单片热点问题，解决方案也是分而治之。将数据库中的库存数据同步到redis时，把key值打散，分散在多个redis单片中。注：我们目前线上的流量峰值还达不到会造成redis单片瓶颈的问题，为避免过度设计，只做了前置限流，没有进行key值的打散。

（1）实物库存同步：

实物库存同步，对接的是仓储系统，通过接口来获取商品的实际库存。实物库存同步分成两种：定时全量同步、指定单品更新。

• 定时全量同步：每天定时全量拉取库存调度平台的实物库存进行全量同步。

• 制定单品：运营也可以手动触发单个sku的商品即时同步实物库存。

由于库存系统多个场景涉及库存变更，运营手动编辑、用户下单退款导致库存扣减回退，还有商品系统内编辑库存数据也会导致库存变更（以前库存系统未独立，库存数据维护在商品系统）。同时很多业务在查询库存时，参考的依旧是商品系统的库存数据。

这里有一个问题：库存系统已经独立出来，为什么还会依赖商品系统的库存数据？

这有两点原因：

• 商城多个业务的后台有商品筛选的需要，商品筛选会有库存数量的筛选项。商品数量很多，筛选是分页的，如果将库存数据全部替换成库存系统的，那么存在跨系统分页问题，分页筛选会存在问题；

• 历史遗留问题，很多业务方依赖的是商品系统的库存数据（包括依赖商品库存离线表的业务方），全部切换到库存系统，成本和影响范围大。

因此，我们需要保证商品系统和库存系统两边库存数据的一致。

库存变更场景多，为了降低业务复杂度、采用简单的方式实现库存同步，我们利用了团队自研的CDC系统（鲁班平台），整体流程如下：