在上一期的“交易中心，让买卖随时随地发生”中提到：胜天半子营销中台把交易作为核心，从业务端看交易的本质是业务流转云端的能力，不管什么样的业务场景与应用，只要交易场景存在，交易能力就应该能覆盖。本期文章我们将以商品库存为重点，继续探索业务中台。

定位

不论互联网电商还是传统ERP，库存都是需要重视的，甚至可以定位为企业的“命门”。企业进销存业务都是直接与库存挂钩，不管是库存过多导致滞销，还是库存过少导致供货不足，都对企业影响很大，所以说：库存周转率直接影响着企业的现金周转效率、利润率。

商品库存中心——也就是胜天半子的选品中台，通过后台可以随时查看商品库存数据变化，精准跟踪变化，统一管控全渠道商品库存数据。

商品库存贯穿整个进销存价值链路，无论是从供应链的采购、调配、采购退货、盘点等环节，还是从销售线的下单、发货、售后等流程都与之息息相关。各方业务对库存的高度关联催生“高内聚低耦合”库存中心服务能力，统一对外提供服务，避免“烟囱式”IT系统架构。

业务

从表面看商品库存中心就是管理商品在仓库的库存数据，包括仓储总库存和各线下店铺库存：

店铺库存：即前台库存，也就是面向用户的商品库存数量；

仓库库存：即后台库存，就是面向仓库的库存数量。

主要为了维护仓储数据和店铺数据，实时把控仓库数据的精准性。下图简单反映库存中心的业务范畴：

数据模型

根据以上业务看出仓库、仓库库存、店铺仓库、店铺库存、仓库映射、出入库明细等数据模型，同时支撑前端应用电商ERP\商城对库存中心的诉求，如下图所示：

服务能力

根据业务+数据模型，沉淀其服务能力，以API形式对外赋能，通过服务编排、接口组装，灵活搭配前端应用功能。

服务接口设计遵循规则如下：

解决方案

1.秒杀、拼团、砍价等高并发场景下，如何支撑库存扣减服务？

【现象】

流量瞬间剧增，造成秒杀库存的争抢；

高并发下应用、数据库负载连接突然飙升；

黄牛刷单、恶意刷单。

【应对】

交易库存无锁化设计，避免数据库锁资源争用；

应用集群化设计，应对超大规模业务处理负载；

分布式数据库消除数据读写瓶颈，自由弹性伸缩；

风控中心实现不同维度的限流规则，对恶意请求进行拦截，在业务洪峰来临时对系统进行过载保护。

2.如何避免库存超卖？

避免超卖是库存系统架构设计和系统实施的底线原则，设计总思路如下：

提交订单锁定库存时，比较秒杀数量与可锁定库存的大小，如果秒杀数量大于可锁定库存，则秒杀失败。原理看似简单，但要考虑过在高并发场景下如何保证秒杀库存不超卖？具体细节可留言讨论，本文就不过多透露了！

3.如何最大化提高库存中心性能&保证库存数据完整性？

除了架构上实现集群分布式部署，为了更好地提升服务能力、提高接口性能，库存中心60%~70%链路使用异步调用。异步调用主要有消息队列、异步任务、并行调用策略等。

为什么订单链路上锁定库存逻辑、店铺库存重新计算分配如此快？是由于大部分链路使用的是异步调用，而只有核心链路中某些最核心的环节中才会使用同步调用。

另外，将服务主链路拆分成各个异步子链路，可增强系统可维护性，各个子链路调用失败支持自动+手工重试。库存中心基于任务集群分片、分治做异步调度，实现适配业务的各种定时任务类型：

实时任务：作用于主链路逻辑的异步化；

小时任务：作用于接口调用失败后重试；

日结任务：作用于业务数据日结，保证最终一致。

另外，库存中心的其他关键性设计如下：

库存异动实时分发，应用解耦、搞定数据异构；

具备接口、应用级别限流、降级、熔断的能力；

具备全链路调用跟踪、接口性能与监控告警能力；

具备运行环境状态监控与宕机告警能力；

具备实时分析海量日志的能力。