查询商品信息 (调用商品服务)
计算总价(生成订单详情)
商品服务扣库存(调用商品服务)
订单入库( 生成订单)
// 原始的MySQL同步流程
// 判断此代金券是否加入抢购
SeckillVouchers seckillVouchers = seckillVouchersMapper.selectVoucher(voucherId);
AssertUtil.isTrue(seckillVouchers == null, “该代金券并未有抢购活动”);
// 判断是否有效
AssertUtil.isTrue(seckillVouchers.getIsValid() == 0, “该活动已结束”);
// 插入数据库
seckillVouchersMapper.save(seckillVouchers);
在订单生成时直接扣库存,这是最原始的扣库存方案,比较简单,但存在
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》
【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享
致很多订单把产品库存扣除而未支付,这就需要有一个后台脚本,将一段时间内没有支付的订单的库存释放,把订单取消
1、3步商品服务,操作商品服务的 db,2、4步订单服务,操作订单服务的 db。
避免访问不同服务的 db,原则上同一服务只能操作自身服务的 db。
MQ异步化
首先考虑只将第4步异步。
2,4都是操作db,第4步不再等待,1、2、3成功后立即反馈给用户。
之后通过消息通知服务异步下单,若第4步异步下单失败,重试操作,试图重新生成订单,MQ的消息也可回溯。
订单创建完成后,处于排队状态,然后服务发布一个事件Order Created
到消息队列中。
即订单服务向外界发送消息:我创建了一个订单,由MQ 转发给订阅该消息的服务。
如果商品服务收到创建订单消息之后执行扣库存操作。注意,这里可能因为某些不可抗因素导致扣库存失败,无论成功与否,商品服务都会发送一个扣库存消息到 MQ,消息内容即扣库存的结果。
订单服务会订阅扣库存的结果,接收到该消息后:
如果扣库存成功,将订单的状态改为已确认
,即下单成功
如果扣库存失败,将订单的状态改为已取消
,即下单失败
欲实现上述模型要求,需可靠的消息投递。服务发出的消息,一定会被MQ收到。
前端配合排队中等界面。
商品/订单服务都变成异步化,适合秒杀类场景,当流量不大时,并不太适合。
异步设计
===================================================================
库存在Redis中保存
收到请求Redis判断是否库存充足 ,减掉Redis中库存
订单服务创建订单写入数据库,并发送消息
当订单支付成功后,会有一个出库过程,既然有这个过程,就有可能出库失败。
库存有两部分:
缓存redis层
数据库mysql层
当客服新增5个库存,则缓存redis和数据库mysql层都需增加5个库存,使用分布式事务的最终一致性来满足:库存要么全加,要么全不加。
当订单生成时,需要扣除库存,先扣redis库存
,如果扣除成功,则生成订单进行支付,这个过程不扣除mysql库存
。
当redis库存扣完,该产品就无法下单了,下单就会失败,就把外层的给挡住了。
在第2步扣除redis库存成功后
,生成订单,进行支付,支付成功,返回我的订单中心, 会发现有一个出库过程。
出库过程
一个MQ异步解耦的任务队列,这个过程是扣除mysql库存
:
如果扣mysql库存成功,出库成功,完成下订单整个流程,进入发货状态
如果扣mysql库存失败,出库失败,进行一系列的操作
订单状态改成取消
返还redis库存
退款
redis库存和mysql库存
==============================================================================
支付前是预扣
,是扣redis库存
,是锁定库存的过程
支付后是真正扣,扣mysql库存
,保证库存最终一致
但是,在极端情况下会存在数据不一致
如果redis库存 = mysql库存,不会有问题
如果redis库存 < mysql库存,不会有超卖问题,但会存在实际有库存,但是没有卖的情况
如果redis库存 > mysql库存,就会超卖,超卖的订单,在出库的过程中会失败
这样总体不会出问题,mysql数据库层,保证库存最终不会出问题。
问题
=================================================================