产品沉淀

最近工作遇到个实例，头痛不已。大致背景是这样：
内部产品（销售端+管理端全部是自研产品）：供应链上了独立的库存中心，数据分为三层——销售层、调度层、实物层，实物层对应实物的管理 数字化映射，调度层是对实物层的管道切分+调度算法分配，销售层来源实物层+自己渠道的独立销售配置规则。每层库存均分为：账面库存、可用库存、锁定库存。

外部产品（供应仓储端是外部wms产品）：仓储端使用独立的三方wms进行独立仓内数实管理。和内部产品进行双向通信。有内部产品驱动的仓内出库、入库指令，也有外部产品驱动的仓内调拨、报损指令。最终数据一致性落脚放在内部的库存中心数据库上。

由于内外产品通信机制、锁库机制：消息推动都是MQ形式没有同步实时接口，锁库机制也存在颗粒度层级差异，从而遇到棘手的问题——操作意志的冲突。内到外的操作是从库存中心数据作为指令驱动，外到内是以仓内实物作为指令驱动，时间差和指令源的冲突，体现在对库存中心数据库的可用库存上面，当可用库存为0时，二者就无法玩推箱子游戏了。必然产生死信堆积。

核心矛盾：
双边数据库想要最终一致性vs变动指令源冲突且时差
仅从数据层面确保指令的可执行性vs忽略了数据仅仅是对实物世界的表达

抽象解构：
实物驱动数据变化，实物变化优先，实物驱动的数据变化可以在数据维度进行超扣

数据分为：实物数量（恒定）=数据占用数量+数据可用数量

数据占用数量是各个来源业务的零和数据，数据可用数量是其余2者的余数

核心逻辑：
实物层面，实物驱动的来源业务和外部业务来源实物驱动意向之间，以实物执行为准，进行数据的更新；实物驱动数据超扣，实物驱动数据释放的自动对冲超扣数量，原则是实物的零和原则。