原文链接：关于电商库存扣除实现思路

一个单独的电商服务

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

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

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

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

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

5.3.1当缓存库存比数据库库存多，那么就会出现，查询有票，但是就无法下单，下单的时候就说库存不足，这个情况下，就会造成数据库压力过大，不过12306应该有其他手段来规避这个问题，不过，我确实遇到过，查询的时候有票，但是无法下单的情况。

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