// 原始的MysqL同步流程
// 判断此代金券是否加入抢购
SeckillVouchers seckillVouchers = seckillVouchersMapper.selectVoucher(voucherId);
AssertUtil.isTrue(seckillVouchers == null, “该代金券并未有抢购活动”);
// 判断是否有效
AssertUtil.isTrue(seckillVouchers.getIsValid() == 0, “该活动已结束”);
// 插入数据库
seckillVouchersMapper.save(seckillVouchers);
在订单生成时直接扣库存，这是最原始的扣库存方案，比较简单，但存在
问题
- 可能导
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》
致很多订单把产品库存扣除而未支付，这就需要有一个后台脚本，将一段时间内没有支付的订单的库存释放，把订单取消
- 即时扣库存，并发差
1、3步商品服务，操作商品服务的 db，2、4步订单服务，操作订单服务的 db。
避免访问不同服务的 db，原则上同一服务只能操作自身服务的 db。
首先考虑只将第4步异步。
分析
2,4都是操作db，第4步不再等待，1、2、3成功后立即反馈给用户。
之后通过消息通知服务异步下单，若第4步异步下单失败，重试操作，试图重新生成订单，MQ的消息也可回溯。
订单创建完成后，处于排队状态，然后服务发布一个事件Order Created 到消息队列中。
即订单服务向外界发送消息：我创建了一个订单，由MQ 转发给订阅该消息的服务。
如果商品服务收到创建订单消息之后执行扣库存操作。注意，这里可能因为某些不可抗因素导致扣库存失败，无论成功与否，商品服务都会发送一个扣库存消息到 MQ，消息内容即扣库存的结果。
订单服务会订阅扣库存的结果，接收到该消息后：
-
如果扣库存成功，将订单的状态改为
已确认，即下单成功 -
如果扣库存失败，将订单的状态改为
已取消，即下单失败
欲实现上述模型要求，需可靠的消息投递。服务发出的消息，一定会被MQ收到。
- 用户体验的变化
前端配合排队中等界面。
商品/订单服务都变成异步化，适合秒杀类场景，当流量不大时，并不太适合。
===================================================================
当订单支付成功后，会有一个出库过程，既然有这个过程，就有可能出库失败。
库存有两部分：
-
当客服新增5个库存，则缓存redis和数据库MysqL层都需增加5个库存，使用分布式事务的最终一致性来满足：库存要么全加，要么全不加。
-
当redis库存扣完，该产品就无法下单了，下单就会失败，就把外层的给挡住了。
-
出库过程
==============================================================================
支付前是预扣，是扣redis库存，是锁定库存的过程
支付后是真正扣，扣MysqL库存，保证库存最终一致
但是，在极端情况下会存在数据不一致
这样总体不会出问题，MysqL数据库层，保证库存最终不会出问题。
=================================================================
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
