1 同步流程
- 查询商品信息 (调用商品服务)
- 计算总价(生成订单详情)
- 商品服务扣库存(调用商品服务)
- 订单入库( 生成订单)
在【订单生成】时直接【扣库存】，这是最原始的扣库存方案，较简单，但可能存在问题：
可能很多订单把产品库存扣除而未支付，就需有个后台脚本，将一段时间内未支付的订单的库存释放，把订单取消
即时扣库存，并发差
1、3步商品服务，操作商品服务的 db，2、4步订单服务，操作订单服务的 db。
实际开发时，同一服务应该只能操作服务自身的 db。
2 MQ异步化
先考虑只异步化第4步：
分析
2、4都是操作db，第4步不再等待，1、2、3成功后立即反馈给用户。
之后通过MQ通知服务异步下单，若第4步异步下单失败，重试操作，试图重新生成订单，MQ的消息也可回溯。
订单创建完成后，处于排队状态，然后服务发布一个Order Created消息到MQ，即订单服务向外界发送消息：我创建了个订单，由 MQ 转发给订阅该消息的服务。
若商品服务收到创建订单消息之后，执行扣库存。
这里可能因某些不可抗因素导致扣库存失败，无论成功与否，商品服务都会发送一个扣库存消息到 MQ，消息内容即扣库存的结果。
订单服务会订阅扣库存的结果，接收到该消息后：
- 若扣库存成功，将订单状态改为
已确认，下单成功 - 若扣库存失败，将订单的状态改为
已取消，下单失败
欲实现上述模型要求，需可靠的消息投递：服务发出的消息，一定会被MQ收到。
用户体验的变化
前端配合排队中等界面。
商品、订单服务都变成异步化，适合秒杀类场景，当流量不大时，并不太适合。
3 异步设计
- 库存在Redis中保存
- 收到请求Redis判断是否库存充足，减掉Redis中库存
- 订单服务创建订单写入数据库，并发送消息
当订单支付成功后，会有一个出库过程，既然有这个过程，就有可能出库失败。
库存有两部分：
- 缓存redis层
- 数据库mysql层
- 当客服新增5个库存，则缓存redis和数据库mysql层都需增加5个库存，使用分布式事务的最终一致性来满足：库存要么全加，要么全不加。
- 当订单生成时，需要扣除库存，
先扣redis库存，如果扣除成功，则生成订单进行支付，这个过程不扣除mysql库存。 - 当redis库存扣完，该产品就无法下单了，下单就会失败，就把外层的给挡住了。
- 在第2步
扣除redis库存成功后，生成订单，进行支付，支付成功，返回我的订单中心， 会发现有一个出库过程。 出库过程
一个MQ异步解耦的任务队列，这个过程是扣除mysql库存：
- 如果扣mysql库存成功，出库成功，完成下订单整个流程，进入发货状态
- 如果扣mysql库存失败，出库失败，进行一系列的操作
- 订单状态改成取消
- 返还redis库存
- 退款
