经过上一章的讨论相信你已经了解库存的一些最基本的实体有了一些了解。但是仅仅了解实体还是不够的，就销售层面的库存其实也比较复杂，需要和一些外部系统打交道，有一些典型的场景需要具体去分析处理。如果你师一只老鸟，非常熟悉库存的系统设计，可以略过了。接下来猿人工厂君，就带着你一起来看看销售层库存系统的设计问题。
那只巨兽又开始动了，猿人君早就料到这些事情了，猿人君早已经说过了，如果这个世界都是资本家强权的社会，那大家还有什么希望？虽千万人，吾往矣。中间细节，猿人君，会在方便的时候公开，程序猿鸭，且行且珍惜。可能会影响到内容章节的更新进度，不过猿人君会尽量去保障，事情完结之后，都会好起来的。
提起库存系统的设计，也许你会说，实体已经找到了，设计还有什么好讲的啊？嘻嘻，你看到的只是实体和属性，还有一些比较典型的场景和对应的核心逻辑，你还是要知道的哈。
在讨论这个问题之前，我们先一起来分析一个典型的场景——用户如何展示剩余库存数。
猛一看这个图片，你也许会觉得好奇，干系系统是什么？哈哈都学习这么久了，还不明白干系系统有哪些吗?
我们一起想想看，商品详情页需要。要是商品不可售，那自然不能售卖了，到一定范围数，比较紧缺的话，有时还需要提示库存紧缺。购物车需要吧？要不怎么提示库存不足？结算页面需要吧？要不怎么判断商品能否购买呢？订单需要吗？先想想看哈，暂时不告诉你。
至于为什么要同时返回库存状态和库存数量？因为有些地方需要数量，有的场景不需要数量，只需要一个状态，有的场景状态和数量都需要，库存系统同时返回就好了。
说完了与展示相关的话题，我们接着聊一聊，库存的变化。第一个变化——订单下单了。我们看看是怎么一回事情。
哈哈，可能你会有个问题，为什么订单不关注库存状态，只发起预占操作呢呢？嘻嘻，都到最后一步了，成败都由库存系统说了算，自然不需要画蛇添足了。
那么订单预占需要什么信息呢？订单预占，自然需要订单号，要不怎么知道是哪个订单来预占的呢？至于其它信息嘛，商品ID、SKUID、SKU数量以及对应的商家信息还是要提供一下的。那库存系统拿到做什么事情呢？我们可以简单的画一下图。
库存系统收到订单预占的要求后，先获取订单内的sku信息，然后先判断订单内sku的库存状态是否有效，如果有一个无效则直接失败，如果都满足，那么对数量进行扣减，所有的数量都扣减成功（不会出现为数量不满足的情况），则预占成功，否则预占失败。从逻辑上来看是这样的，不过到具体的实现嘛，花样蛮多的，后续再说了。
接下来，可以看看另一个变化的场景，用户支付订单。用户支付订单之后，库存就不在是预占了，会发生一些变化，变为实际扣减。我们看看是怎么一回事情。
也许你会说这个图画错了，因为看上去订单系统通知完库存系统之后，就返回支付结果了，似乎并不关心库存的后续操作。哈哈，反正猿人工厂君就先这样画着了，至于为什么以后再讲，有基础的自然懂。我们先关注库存系统逻辑的事情。
库存系统收到订单支付成功的通知之后根据预占信息，将预占的数量减去，同时将锁定数量增加，这个过程没有什么特别的，不过嘛，这个过程真的就这么简单吗？想一想，有什么遗漏的地方吗。
接下来我们看一看订单取消时的一个逻辑变化，订单取消就比较复杂一些了。因为发生的情况不同。刚下单时取消订单和支付后取消订单是有区别的。刚下单时，对于库存系统来说，关注的时预占数的变化，支付后取消关注的是锁定库存的变化噢，我们先画图看下。
订单系统收到用户发起取消的通知之后先根据订单号，获取订单信息，然后判断订单是否已经支付，如果订单未支付，会通知库存取消预占，如果已经支付了，则通知库存取消锁定。
库存接到取消预占或者取消锁定的通知之后，都会发起库存的回退操作，取消预占，则减去预占数量，增加现货数量。取消锁定，则会减去锁定数量，增加现货数量。
库存系统做这些操作的时候，只需要一个订单号就够了，想一想为什么？它是怎么来做到的呢？多想想，是对你有很大帮助的噢。
以上就是库存系统的设计思路，主要偏逻辑一些，也故意留了些东西埋伏起来。开动你的小脑筋，自己先去想一想。下一个章节，猿人工厂君继续带你聊一聊购物的那些事儿。
