在一个宁静的午夜，我睡觉正酣。突然电话将我从睡梦中惊醒。生产环境出现事故了...
问题
在线上出现部分客户提交订单失败，大量的错误原因是商品的库存不足。而我们系统的设计先预定库存。客户预订了库存，预订时间不超时的情况下，客户订单结算时出现库存问题，这是不满足产品设计要求的。
背景
我们系统订单库存的扣减流程：
- 用户选择商品后锁定订单库存
第一步锁住订单库存
用户填写表单信息和选择附件商品 （注：为什么我们需要再第一步就锁住订单的库存？是因为系统填写表单的信息较多。如果不预先锁定该订单的库存，等客户费了九牛二虎之力填写完相关信息后，提交出现产品已经售完的信息，这时客户就会F***问候了）
提交表单信息，继续去锁定该订单库存（因为表单页面有新的商品选择）
去支付页面付款，完成订单。
原因分析
具体事例说明：
- 美女A在商品页面上选择了马拉松10公里，点击下一步
后台： 预扣马拉松10公里库存 1， 返回订单ID - 美女A填写表单信息，并添加了跑步道具， 点击下一步
后台：根据最开始的订单ID，继续预扣马拉松10公里和跑步道具库存。
从这里开始，神奇的事情发生了。系统报马拉松10公里产品的库存不足？这个不是在第一步已经预扣了吗？抠脑壳
继续看代码：
对第2步，发现OrderService会首先释放订单中不存在的orderline的库存，且在新的事务中释放，然后再对新的orderLine预扣库存。
这意味着：
马拉松10公里库存的第二次扣减与orderLineId相关，如果第二次预扣库存的orderLineId没有传的话，OMS会先在新的事务中释放该产品的库存预扣；然后产生一个新的orderline, 再去预扣库存。
如果OMS在新的事务中释放掉该产品的库存后， 有一个其它的线程将该库存抢去呢？线上的错误就出现了。
解决问题
product_inventory.png
上面，inventory_reservations跟orderId, orderLineId, productId都有关联。
方案一： 我们仔细想一下，有必要和orderLineId发生关联吗? 用订单ID和产品ID对预扣是否就足够了。
方案二：每次提交预扣，都要把订单ID和相关的orderLine相关的全部信息提交。
