IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《Redis解决库存超卖问题实例讲解》，聊聊RedisMySQL，我们一起来看看吧！

  商品和订单服务间使用MQ

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

  原始的同步流程 查询商品信息 (调用商品服务) 计算总价(生成订单详情) 商品服务扣库存(调用商品服务) 订单入库( 生成订单)

// 原始的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收到。

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

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

  当订单支付成功后，会有一个出库过程，既然有这个过程，就有可能出库失败。

  库存有两部分：

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

  支付前是预扣，是扣redis库存，是锁定库存的过程

  支付后是真正扣，扣mysql库存，保证库存最终一致

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

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

  问题

  数据库库存和redis库存不一致，如何检测？

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

  没有想出来好的方案

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

  这个就是数据库同步缓存的更新机制方面的问题

  属于一致性的逻辑设计的问题

  缓存数 = 数据库库存数 - 待扣数

  当然这里面也还有其它的方案，以及考虑到一致性的要求高低，可以使用简单或复杂的方案

  就看系统复杂度了，越是大系统就要拆得越细

  比如待扣数又可以放到一个队列里面，或者缓存里面，同时有计数，直接读计数就行

  比如放到mongo，已支付待出库的数量，一般也不会很大，count一下，也不会损失多少

  所以一般系统都不能完全保障数据链不出错，但一定要有补偿，就是出错了可以纠错

  要保障不出错的代价显然太大

  同步是有一套刷新机制，可以定时，也可以通过MQ，或者监控不一至同步等等。。。

  也叫做保障缓存数据的新鲜度

  一般不会太长时间，半小时，几分钟都有可能，不同场景需求不一样

  12306

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

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

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

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

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

  文中关于redis的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis解决库存超卖问题实例讲解》文章吧，也可关注golang学习网公众号了解相关技术文章。