扣库存流程

一时失言乱红尘 2023-10-14 12:05 62阅读 0赞

**1. 同步扣库存**

在订单生成的时候直接扣库存，这是最初等的方式扣库存，这种方式比较简单，但是也有一系列的问题：

1.1、会造成有很多订单把产品库存扣除而并没有支付，这就需要有一个后台脚本，将一段时间内没有支付的订单的库存释放，把订单取消掉

1.2、即时扣库存，并发差

**2. 异步扣库存**

对于电商系统，譬如某狗东，会注意到，当订单支付成功后，会有一个 `出库` 过程，既然有这个过程，就有可能 `出库失败` ， 他的流程是怎么样子的呢？（下面是讨论的结果，本人并不实际了解狗东的流程）

>  **库存有两部分：一个缓存 redis 层，一个数据库 mysql 层**

2.1 当客服新增了 5 个库存，那么， `缓存redis` 和 `数据库mysql` 层都需要增加 5 个库存，这个使用分布式事务的最终一致性来满足要么全加，要么全不加库存。

2.2 当订单生成的时候，需要扣除库存，先扣除 `redis库存` ，如果扣除成功，则生成订单进行支付，注意，这个过程是不扣除 `mysql库存` 的。

2.3 当 `redis库存` 扣干净了，那么这个产品就无法下单了，下单就会失败，就把外层的给挡住了。

2.4 在 2.2 步扣除 `redis库存` 成功后，生成订单，进行支付，支付成功，返回我的订单中心， 会发现有一个 `出库` 过程

2.5 `出库` 过程是一个 MQ 异步解耦的任务队列，这个过程是扣除 `mysql产品库存` ，如果扣除 `数据库mysql产品库存` 成功，那么出库成功，完成下订单的整个流程，进入到发货状态

如果扣除 `mysql中库存` 失败，那么就会出库失败，进行一系列的操作 a) 订单状态改成取消，b) 返还 `redis库存` ，c) 退款

**3.Redis库存 和 mysql库存**

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

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

3.1 如果 `redis库存` 和 `mysql库存` 一致，不会有问题

3.2 如果 `redis库存` 比 `mysql库存` 少，不会有超卖问题，但会存在实际有库存，但是没有卖的情况

3.3 如果 `redis库存` 比 `mysql库存` 多，就会超卖，超卖的订单，在出库的过程中会失败

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

**4. 但是会有以下的问题：**

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

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

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

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

**5.火车票12306扣库存的设计**

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

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

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

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

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

5.3.1 当缓存库存比数据库库存多，那么就会出现，查询有票，但是就无法下单，下单的时候就说库存不足， 这样也不会超卖，当 redis 的库存多的那部分扣完了，就可以把请求全部当在外面了。 对于 12306，有时候，查询的时候有票，但是下单的时候返回库存不足，然后重新查询发现还是有库存， 这种情况应该就是 redis 中库存和 mysql 中库存不一致造成的。

5.3.2 当缓存库存比数据库缓存少，那么不会出问题，只会出现有票，但是没有出售的情况，等完成库存同步一下， 明天又准确了。

5.3.3 当然，mysql 扣除库存的部分，还需要在前面加入队列缓冲，避免请求过多，让应用程序或数据库崩溃。

> [ 订单系统：从0到1设计思路 - 知乎 (zhihu.com) ][_0_1_ - _ _zhihu.com_]

[_0_1_ - _ _zhihu.com_]: https://www.oschina.net/action/GoToLink?url=https%3A%2F%2Fzhuanlan.zhihu.com%2Fp%2F73073164