是
否
优点：对数据库锁依赖少，业务代码不需要考虑并发的数据问题缺点：Redis一般是针对一个key上锁，目前的业务看需要上一个全局锁，会造成并发能力严重不足。如果需要对多个key上锁解锁需要懂Lua脚本
补充说明：假设我们物料达到了10000个，都是快消品，每个物料分布到32个省，每个省两个仓库。每个商品每天都进货一次。再假设：接口的并发处理能力是200那么以上请求累计需要处理的时间是3200秒，约55分钟
Redis Lock
请求数据进入MQ，等待后续重试
优点：乐观锁原理比较通俗易懂，实现起来比较简单，开发成本低，维护成本低缺点：预计能承担数据库TPS600左右的压力，如果请求量真的很高能达到300/s个入库请求可能需要考虑更换架构
方案2
保存数据，更新库存
Redis unLock
消息队列监听读取消息
保存数据，更新库存，乐观锁
调用请求出库接口
处理出库业务逻辑
库存处理技术方案分析
是否出现异常
是否是消息监听器执行的此程序
结束
子流程
以【接收仓库发送的销售出库指令状态更新接口（出库）】为例
优点：高吞吐量，MQ内存够用即可缺点：消费能力依赖开启的消费者数量，需要用到多线程编程提高消费能力，数据处理的及时性可能没那么高
补充说明：针对数据量很大且及时性不是非常高的情况可以使用此方案，如果要提交消费能力，提交及时性，就需要进行多线程消费
补充说明：Redis命令执行很快，但是出现读线程竞争锁很大的开销是在网络上。导致并发能力不够，水星之前扣库存尝试过，压测只有20tps，后来采用的乐观锁单独对多个SKU上锁需要开发人员懂Lua脚本，开发，学习，维护成本都高
抛出异常
通过乐观锁机制是否更新成功
方案1
数据扔进MQ
方案3
