我司库存扣减业务，现在一般就几种扣减模式： 1. 下单减库存，订单取消回补库存，订单取消接口编排库存回补逻辑 2. 下单预占库存，支付成功减库存，订单超时释放 3. 支付减库存，业务场景并不多 前提：当前使用的数据库是魔改过的，并针对高并发场景下执行 UPDATE value=value-1 做过定制优化，20C 机器提供单行 5w+ TPS 容量 所以 op 需要根据不同场景来看： 场景 1：下单时交易同步调用库存服务完成扣减，库存内部落单并更新库存-1 ；订单取消时，交易负责触发库存的回补动作，对账兜底 场景 2：下单交易同步调用库存预占接口类似 TCC 模式预占库存并发送订单超时队列延迟消息，支付回调触发同步减库存；消费到订单已取消消息后，check 订单支付状态未成功则返还库存信息 场景 3：比较简单不提 实际上业务中基本上都是同步调用，用 MQ 做异步处理会导致系统设计复杂，用户体验并不好，且存在先后顺序问题，不过一般情况下加个时间戳也就解决了
@MoYi123 不懂业务的技术，做起事来往往事倍而功半。还在那自我感动攻克了什么什么技术难题，实际上根本不需要。真真是可笑。 如果你要和我讨论数据一致性问题，请先把业务场景摆出来。电商有电商的一致性需求，银行又有银行的一致性需求。不确定场景，这事太过复杂，就没什么可讨论的价值。
