本日来跟大家聊下电商平台里的库存系统，相信大家对库存系统最直观的感觉就是商详页上是否显示“插手购物车”可能是“到货通知”。只要能插手购物车就暗示有库存，显示到货通知就暗示没有库存了，并没有以为这内里有多么的庞大。本日来跟大家一起解密下库存系统，来看一看是不是真的如果大家想象中那么的简单。
库存系统的浸染是什么？
最重要的浸染就是打点好各个商品的及时库存数据，实时汇报用户当前商品是否可以购买？还可以购买几件。
为了能够更清楚的介绍库存系统是如果何打点商品库存数据的，这里需要先简单给大家介绍另外一个系统，叫做客栈系统。预计许多人分不清客栈系统跟库存系统之间的干系是什么？
客栈系统实际真正打点的是物理客栈内里的库存的数量。我们经常传闻的京东亚洲一号仓等等这些大型的客栈，由于面积很是大，内里的商品数量也许多，所以需要有一套系统来辅佐打点实体仓内里的库存的数量。
简单来说就是打点这个客栈一天有几何商品进入到这个客栈内里来，每个商品的数量有几何？每天从这个客栈发出去几何个商品？客栈内里每个商品还剩下几何？剩下的这些商品别离存储是客栈的哪个储位上等等。
那么有了客栈系统就可以打点商品的数量，那么为什么还要有库存系统呢？
下面给大家举个例子，让大家了解下客栈系统和库存系统之间的区别是什么？当某个商品A在客栈内里有10个数量的时候，客栈系统卖力打点这个商品A的数量，以及它的位置信息。那么客栈内里这个商品A在网站上是不是必然可以答允卖10个呢？这是不必然的。因为客栈内里有10个商品A，大概网站上已经有3个被用户买掉了，只不外这3个商品还没有出库，所以在客栈系统内里看这个商品Ａ今朝另有10个在客栈，但实际上已经卖掉３个，网站上其实只能卖７个，这种可卖的数量客栈系统是区分不出来的，它只是卖力打点在当前时刻客栈内里一共有几何库存，并不区分商品的状态信息。所以库存系统主要是用来解决这个问题，颠末一系列的计算汇报用户当前时刻商品A一共还可以买几个。客栈系统打点的是客栈内里商品的实际数量，库存系统打点的是商品的可销售数量，这就是库存系统和客栈系统主要的区别。
在电商网站的商详页上展示当前商品可售卖数量对库存系统来说是相比拟力简单的，有货的时候显示当前商品的数量，没货的时候汇报前端此商品库存为0，前端展示到货通知，如果下图：
库存跟客栈系统之间的交互
较量庞大的是如果何对接客栈的各类进出库事件来打点商品的数量。下面来跟你介绍一下库存跟客栈系统之间交互的几个较量重要的事件。
采购入库
当B2C电商网站类似京东、当当这种想卖一个商品的时候首选要提倡采购打算，这时候需要在客栈系统内里成立一个采购单。目的是记录哪个商品采购了几何数量，将会把这批货采购到哪个客栈内里去。
采购单提倡之后过一段时间实际的商品会入库。这时候客栈系统会把相应的商品数量举办变动。这个时候客栈系统同时会通知库存系统，汇报库存系统某个商品入库了，数量是几何，库存系统会把相应的数量加上。
采购入库时序图
下单锁库存
商品采购入库之后库存系统就会增加相应的数量，这时候在网站端这个商品就可以开始卖了。当有人购买这个商品的时候，库存系统会将这个商品数量先锁定。然后期待客栈出货。当客栈真正出货的时候，(店家网：抖音运营资料)，库存系统才会将相应的数量减掉。这里表明下库存系统为什么要有一个锁定的状态？
照旧举个例子来说。当一个手机A采购入库10个的时候，库存系统也会显示这个手机在库存系统内里有10个数量。也就是说网站上可以销售的数量为10。
当一个用户买了一个手机A的时候。库存系统会将这个商品先锁定一件。暗示有一个商品已经有人付钱要举办购买了，(抖音刷粉平台)，这个时候库存系统会汇报网站端此商品今朝能购买的数量为9个。
订单打消解锁库存
当用户下了单买了手机Ａ之后，过了一会大概由于各种原因反悔了，(抖音橱窗开通网站)，可能是不想买了可能是想换一个更好的手机，这个时候用户会将这个订单打消掉。在客栈没有将这个手机发出去之前用户是可以打消的，这个时候我们需要将刚刚锁定的数量解锁掉，变革后的库存数量如果下：
出库扣库存
如果果上面用户没有打消订单，那么客栈内里的事恋人员将这个商品找到、打好包裹、寄出去之后，客栈系统会通知库存系统这个手机已经出库，这个时候库存系统需要将数量淘汰，详细变革如果下：
客栈的实际数量变为９，锁定命量变为０，可售卖的数量仍然为９。
客栈间调拨
这个纯属电商客栈打点的靠山流程，普通用户是感知不到的，稍微大一点的商家可能自营平台，类似京东、苏宁这种自建客栈的平台商家都会有许多个客栈漫衍式在全国各地，商品也是有必然法则的漫衍在各个客栈必然的数量，当用户下单的时候只管从离用户最近的客栈发货，这样速度较量快并且间隔也较量短，物流本钱也较量低。但实际上会由于各类原因导致某些商品库存数量分配的并不是很公道，大概南方的客栈已经卖没了，北方的客栈还积存许多没卖出去，这个时候为了让商品尽快的卖出去，需要将这个商品从北方的客栈调拨到南方的客栈，这就是调拨的业务场景。
可以看到调拨是一个商品在两个仓之间的周转，这就为打点增加了难度，(抖音开购物车网站)，完成一次调拨有三个步调：提倡调拨申请、调拨出库、调拨入库。
提倡调拨申请：当抉择把商品Ａ从北方仓调拨到南方仓的时候，首选需要提倡一个申请，暗示哪个商品从哪个仓调拨到哪个仓，调拨的数量是几何。
为了利便大家明白，我们举个例子，将商品Ａ从北方仓调拨到南方仓100个。当提倡调拨申请的时候，库存系统会先在北方仓锁定100个商品A的数量。库存的变革如果下：
提倡调拨前
提倡调拨后
看到这里有同学会奇怪为什么提倡调拨的时候也要先将调拨数量举办锁定，因为如果果不举办锁定的话极度环境下北方仓的这个商品大概溘然就卖掉了950件，这时候客栈只剩下了50个，客栈就没有步伐举办100个商品的调拨，会影响商家的整体统筹布置，所以需要在提倡调拨的时候预先锁下，担保调拨可以正常举办。
调拨出库：即当A商品从北方仓出库的时候，这个时候我们需要将库存数量举办相应的调解，调解后数量如果下：
将北方仓的实际库存数量和锁定命量都减掉100，可销售的数量仍然是900。
调拨入南方仓
在这100个商品进入到南方仓之前，我们看下南方仓的库存数量，如果下：
当这个100个单品进入到南方仓之后，南方仓这个商品的数量会举办调解，如果下：
实际数量和可售卖数量都酿成了100。
至此我们完成了一次完成的调拨流程。这内里大家可以看到，其实库存与客栈之间交互的事件较量多，逻辑也较量庞大。上面只是简单列举了几个较量核心的流程。实际出产中另有许多更细节的事件需要打点。比方果，退货的流程、换货的流程、损益的流程等等。如果果任何一个处所呈现误差，就会导致客栈的数量与库存的数量纷歧致。
如果果呈现纷歧致，那就是库存系统的最大失败，库存系统就是用来打点库存的，这就是它的职责。可是实际业务中由于庞大的逻辑会呈现一部分商品库存打点呈现错误，这时候会导致两种效果，一种是客栈系统明明只有5个商品，库存何处计算成了10个。这样大概会有10个用户来购买，可是客栈只有5个，会导致有5个用户的商品不能发货，这就是我们所谓的超卖。这种是较量严重的效果，用户的体验很是不友好。另外一种环境是客栈内里另有10个商品，可是库存系统计算成只有5个，这样会导致商品少卖会造成商品在客栈的积存。所以客栈跟库存另有一个较量重要的逻辑就是对账每天都要查对一下两边的库存数量是否一致。
上面跟大家介绍了下库存系统的概略业务逻辑，(www.hongke123.com)，相信已经有不少人已经看晕了，后头再找时间跟大家介绍下如果此庞大的库存系统是如果何实现的？这里需要解决的问题是如果何保数据一致性？跨库的事务如果何解决？回收什么样的计策举办赔偿？对账如果何做？商详的请求量较量大，如果何担保库存的机能？等等。有好的方案欢迎留言接头。
