亲宝软件园·资讯

展开

Redis解决库存超卖问题 Redis解决库存超卖问题实例讲解

公众号-JavaEdge 人气:0
想了解Redis解决库存超卖问题实例讲解的相关内容吗,公众号-JavaEdge在本文为您仔细讲解Redis解决库存超卖问题的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点:Redis解决库存超卖,Redis解决库存同步问题,Redis缓存和Mysql同步,下面大家一起来学习吧。

商品和订单服务间使用MQ

商品服务的库存变化时,通过 MQ 通知订单服务库存变化。

原始的同步流程

  1. 查询商品信息 (调用商品服务)
  2. 计算总价(生成订单详情)
  3. 商品服务扣库存(调用商品服务)
  4. 订单入库( 生成订单)
// 原始的MySQL同步流程
// 判断此代金券是否加入抢购
SeckillVouchers seckillVouchers = seckillVouchersMapper.selectVoucher(voucherId);
AssertUtil.isTrue(seckillVouchers == null, "该代金券并未有抢购活动");
// 判断是否有效
AssertUtil.isTrue(seckillVouchers.getIsValid() == 0, "该活动已结束");
// 插入数据库
seckillVouchersMapper.save(seckillVouchers);

在订单生成时直接扣库存,这是最原始的扣库存方案,比较简单,但存在问题

避免访问不同服务的 db,原则上同一服务只能操作自身服务的 db。

MQ异步化

首先考虑只将第4步异步。

分析

2,4都是操作db,第4步不再等待,1、2、3成功后立即反馈给用户。

之后通过消息通知服务异步下单,若第4步异步下单失败,重试操作,试图重新生成订单,MQ的消息也可回溯。


订单创建完成后,处于排队状态,然后服务发布一个事件Order Created 到消息队列中。
即订单服务向外界发送消息:我创建了一个订单,由MQ 转发给订阅该消息的服务


如果商品服务收到创建订单消息之后执行扣库存操作。注意,这里可能因为某些不可抗因素导致扣库存失败,无论成功与否,商品服务都会发送一个扣库存消息到 MQ,消息内容即扣库存的结果。
订单服务会订阅扣库存的结果,接收到该消息后:

欲实现上述模型要求,需可靠的消息投递。服务发出的消息,一定会被MQ收到。

商品/订单服务都变成异步化,适合秒杀类场景,当流量不大时,并不太适合。

异步设计

  1. 库存在Redis中保存
  2. 收到请求Redis判断是否库存充足 ,减掉Redis中库存
  3. 订单服务创建订单写入数据库,并发送消息

当订单支付成功后,会有一个出库过程,既然有这个过程,就有可能出库失败。
库存有两部分:

  1. 当客服新增5个库存,则缓存redis和数据库mysql层都需增加5个库存,使用分布式事务的最终一致性来满足:库存要么全加,要么全不加。
  2. 当订单生成时,需要扣除库存,先扣redis库存,如果扣除成功,则生成订单进行支付,这个过程不扣除mysql库存。
  3. 当redis库存扣完,该产品就无法下单了,下单就会失败,就把外层的给挡住了。
  4. 在第2步扣除redis库存成功后,生成订单,进行支付,支付成功,返回我的订单中心, 会发现有一个出库过程。
  5. 出库过程一个MQ异步解耦的任务队列,这个过程是扣除mysql库存:
  1. 订单状态改成取消
  2. 返还redis库存
  3. 退款

redis库存和mysql库存

支付前是预扣,是扣redis库存,是锁定库存的过程
支付后是真正扣,扣mysql库存,保证库存最终一致

但是,在极端情况下会存在数据不一致

这样总体不会出问题,mysql数据库层,保证库存最终不会出问题。

问题

数据库库存和redis库存不一致,如何检测?

如果检测出来不一致,如何同步

没有想出来好的方案
比较暴力的方式,就是找一个低峰期,譬如凌晨1点,周期性强行覆盖。 但是极端情况下还是会存在同步后不准确,譬如在同步的过程中,刚好有一个订单在支付,这个订单支付成功后,出库的过程中,扣除了mysql的库存,但是没有扣除redis的库存

这个就是数据库同步缓存的更新机制方面的问题
属于一致性的逻辑设计的问题
缓存数 = 数据库库存数 - 待扣数
当然这里面也还有其它的方案,以及考虑到一致性的要求高低,可以使用简单或复杂的方案
就看系统复杂度了,越是大系统就要拆得越细
比如待扣数又可以放到一个队列里面,或者缓存里面,同时有计数,直接读计数就行
比如放到mongo,已支付待出库的数量,一般也不会很大,count一下,也不会损失多少
所以一般系统都不能完全保障数据链不出错,但一定要有补偿,就是出错了可以纠错
要保障不出错的代价显然太大
同步是有一套刷新机制,可以定时,也可以通过MQ,或者监控不一至同步等等。。。
也叫做保障缓存数据的新鲜度
一般不会太长时间,半小时,几分钟都有可能,不同场景需求不一样

12306

买火车票的12306,晚上的时间都不能买票,这个时间估计是在同步库存,将数据库库存同步到redis库存中, 但是买火车票之类,在订单生成前,必须扣除实际库存,也就是要扣除mysql的库存,

因为买火车票和购物不一样,购物可以付款后出库,但是买票这种,支付前就必须出库,因此,要将出库过程提前, 只有出库成功,才能生成订单,同样要引入redis库存

先扣缓存中的库存,扣除成功后,然后才可以去扣mysql中的库存。

如果扣除缓存中的库存失败,就会挡在外面,返回库存不足,这些请求不会穿刺到mysql中,挡住了大多数的请求压力。

redis库存会和mysql库存不一致,极端情况下是肯定有的,需要进行库存同步

加载全部内容

相关教程
猜你喜欢
用户评论