一种通用的库存模型浅谈（一）

      近期工作将告一段落，故想想近来学习生活，遂想写此文，训练训练思维，练练笔头。

      为何要谈“库存”，一则与昔日的工作略微存在关系且被其固有设计所折磨，一则被一篇讲稿阐述的观点深深吸引，一则突觉遍地是库存。

      先谈为何遍地是库存。遍地是库存，因为遍地是商品。商品离不开库存，库存亦离不开商品。何为商品，一件衣服是商品，一个机票是商品，一辆汽车是商品，一份外卖也是商品，甚至一大叠钞票也是商品，衍生到唯物主义，商品即物质。有了物质，自然少不了物质的交换（即物质与物质之间的关系）。所以，淘宝、去哪儿、美团、以及去年相继走上致富道路的各大互联网金融，其本质就是完成一种物质的交换，商品的交易。而交易的核心是什么？是商品，如果我们把所有商品交易从库存角度来描述，那么交易的本质是什么，商品交易的本质即为 商品库存的迁移。说到迁移，您是不是想到了一种库存模型。

      再谈这批讲稿。这批讲稿来着《智慧物流的未来》一文，研究了其中的一个片段。虽然通篇看不到一个公式，但其却阐述出来一个非常强大的公式： 全链路库存透明+ 实时= 超高性能的交易场。看到这个公式，你是不是明白了什么。我们如果做一个电商平台，如何做一个牛逼的电商平台，这个公式似乎能给你答案。全链路库存透明，这个一个很难的问题，也是一个很有挑战性的问题。怎么解决？我想，这里就引出了本文的一个核心。

       首先，谈一下解决这个问题思路。解决思路源于最近看的Raft算法的证明，里面提到了一个我们人人都知道却关键时候往往想不起来的思维方式，极简思维。故本文便套用极简思维，假设几种简单的情况，来试图阐述一种通用的库存模型。

        比如在实际电商平台中，我们假设整个链路只有2个节点，A点为供应商，B点为消费者。那么我们设计库存模型可以设计为。A有一个库存表，B有一个库存表。库存的表结构可以为 ：

        《skuId ， 当前数量》

库存迁移的过程，我们可以用一个关系表来表示，表明我看可以定义为库存迁移表。表结构可以定义为：

        《 skuId，流水id，来源地，目的地，产生流水原因，数量，时间 》，写表的顺序我们可以约定一种偏序关系，即A>B。

同时，我们可以定义一个库存快照表，分别记录在A端、B端，表结构可以定义为：

         《skuId，流水id，产生流水Id前库存、产生流水Id后库存》

那么，基于上述模型，我们一种极其简单的场景。1个供应商只有1个商品，这个商品只有1个库存，只有1个消费者。

那么这个sku，从A到B的过程为：

同样，对于钞票这个商品，也存在一个类似的钞票库存迁移过程，等等。

多商品、多库存就不在演变，不过上文中的库存表似乎是多余的存在，这里未来方便阐述，还是需要存在。

接下来想扯的是

如果我想搞自营模式，sku是我从供应商买过来，卖给消费者的，则多了一个C，即需要一个C库存表和C库存快照表。系统数据流向为A->C->B

如果我想搞建自己仓库，sku是从供应商那里发货、经过我的D仓库、然后在经过我，在到消费者那里，那么我需要引入第四个系统，则多了一个D，系统数据流向为A->C->D->B。等等依次类推。然后什么供应商库存、在途库存、仓库库存、前台库存、销售端库存等等概念就产生了，如果我们把 时间也定义成类似下单引起库存变化原因的话，那么 保质期内库存和过期库存这样的概念也就诞生了。所以，库存迁移表，其实也是一种事件表。

从上面可以看出，我们的一个通用的库存模型雏形已经产生了。

具体实现上：

        如果采用简单的集中式模型，各类商品库存迁移表 放在server端、各个系统client端维护库存自己的库存表和库存快照表。需要哪个库存就去哪个库存查找。对各个库存之间的一致性共识 通过server端的库存迁移表来达成。

       当然，如果我们套用区块链的思想，每一个client端，即是client端又是server端，即每一个 client端即维护库存表和库存快照表，又维护 库存迁移表，那么就走向了分布式模型。

       实际中，集中式和分布式混合使用，才是王道。

       好了，就扯这么多，可以歇着了，

       最后，以上版权所有，纯属虚构。