扣库存的场景及问题
扣库存是电商系统里一个非常基础的操作。
在业务上,它必须要能达到:
- 不超卖
- 重试时,不出现假卖
在非功能需求上,它需要做到:
- 应对高并发的流量
单件商品扣库存方案及其优化
约定扣的库存数量为x
方案一 直接更新库存
|
|
由于库存检查是在服务里做的,并发现情况下,容易出现超卖。
设原来的库存是5,用户a扣了库存4,b扣了库存2,流程如下:
- 用户a检查库存
- 用户b检查库存
- 用户a扣库存4
- 用户b扣库存2
- 最终库存为-1
方案一优化 加锁(事务)
为了解决并发修改的问题,可以通过增加锁(事务),把并发变成串行。
这种方案可以解决并发上的问题,但是由于开启事务(锁)的时间较长,会导致严重的性能问题,同时,对于分库后的多个商品,还会存在多库事务的分布式事务问题,成本很高。
方案三 优化锁:减少锁的持有时间
为了优化锁,一个方式是减少锁的持有时间。可以考虑在扣库存时,增加一把乐观锁
|
|
方案四 高并发下的扣库存设计
方案三能解决大部分场景下的扣库存问题,但当碰到秒杀、大促等场景时,由于商品库存有限,扣库存失败的概率很高,这里如果重复尝试扣库存,会对系统造成较大的压力,减少吞吐。
因此需要对并发的流量进行限流。可以考虑对每个商品的并发数加队列或锁,以减少同时并发的数目失败的概率。对于特别热门的商品,还可以把一个商品拆成多个子商品,以增大并发数目。
扣库存的重试
当由于某种原因扣库存失败时,可能需要进行重试。由于扣库存不是一个幂等的操作,容易造成空卖。
可以通过给每个扣库存操作增加一个token来解决这个问题。当token已经使用过时,再次请求直接忽略。
多件商品扣库存方案及其优化
相比于单件商品的扣库存,同时扣多件商品的库存,需要考虑:
- 同时有多个商品,修改、回滚的数目比较多
- 操作商品的模式
最简单的方案是直接把多个商品放在一个事务来实现,但是这样有几个问题:
- 事务时间比较长,还容易造成死锁
- 商品越多,扣库存失败的可能性越大
对于第一个问题,可以把一个事务拆成多个事务,以加大系统吞吐量。这样做还有一个好处,就是这些商品可以不用在同一个库里了(mysql的事务是基于库实例实现的),从而避开了分布式事务的成本。
对于第二个问题,可以使用二阶段提交,先锁定所有商品的库存,然后统一提交。避免频繁回滚。
从扣库存看高并发
扣库存是一个典型的业务型系统,具有以下特点:
- 并发量高
- 数据量大
- 逻辑较轻
它的难点主要体现在:
- 大量高速交易
- 数据的一致性
- 应对各种业务、系统异常情况