天下事有难易乎?为之,则难者亦易矣;不为,则易者亦难矣。

京东二面:商品库存的扣除过程,如何防止超卖?

itzoo 469次浏览 0个评论

点击“终码一生”,关注,置顶公众号

每日技术干货,第一时间送达!



在商品购买的过程中,库存的抵扣过程,一般操作如下:


  • select根据商品id查询商品的库存。

  • 根据下单的数量,计算库存是否足够,如果存库不足则抛出库存不足的异常,如果库存足够,则减去扣除的库存得到最新的库存剩余值。

  • set设置最新的库存剩余值。


上述过程的伪代码如下:


// 根据商品id获取商品剩余库存
select stock_remaing from stock_table where id=${goodsId};
 
// 操作库存
// 比较库存
if(stock_remaing <quantity){
   // 抛出库存不足的异常
}
else{
// 抵扣以后的库存值
int new_stock=stock_remaing - quantity;
}
 
// 根据商品id设置计算后的库存
update stock_table set stock_remaing =${new_stock} id=${goodsId};



1

并发修改数据库存超卖


如果数据库事务的隔离级别不是串行化(serializable),根据事务的特性,在并发修改的时候,可能会出现写覆盖的问题。


假设,商品的剩余库存stock_remaing 为100,客户A下单20,客户B下单30,在并发扣库存的时候,可能存在超卖。如果客户A和客户B同时获取剩余库存为100,则会出现事务后提交的值会覆盖前一个客户提交的值,有可能剩余的库存是80或者70。流程如下:




2

加锁更新存库


为了在事务控制中,防止写覆盖,你会想到使用select for update的方式,将该商品的库存锁住,然后执行余下的操作。


流程如下:



以上,使用悲观锁方式,在分布式服务中,如果并发情况比较高的时候,扣减库存的操作是串行操作,效率很低。



3

使用乐观锁的方式更新


在更新的时候,使用(CAS+版本号更新)+重试条件(重试次数或者重试时间限制)乐观锁的方式更新库存。此时,如果,客户A和客户B同时读取到库存剩余100,在更新的时候,有一个操作会失败。流程如下:



该种方式可以大大提高并发性,也可以保证数据的一致性;通过重试次数和重试时间的条件控制,可以防止过多的重试带来的数据库压力。



4

可以使用直接递减的方式执行么?


在抵扣库存的时候,有的人提议不执行select,计算,set三段式的操作,直接扣减的方式,并且对于扣减到小于零的情况作了判断。伪代码如下:


update stock_table set remaing_stock=remaing_stock-${quantity}
where id =商品id
and remaing_stock>${quantity};


在分布式服务调用中,因为网络异常,获取服务器异常,可能在微服务调用时,存在服务重试。例如,场景的网关超时,服务重试机制。此时,该种方式不满足幂等性,而存在多扣的情况。例如,同一用户扣减库存时,服务重试,极端情况下,该用户扣减库存操作执行多次,则就出现了商品超卖。



5

可以使用redis进行库存的抵扣么?


由于没有研究过redis源码,对于这种方式参考了大牛的回复,答案是可以使用redis的事务性扣减余额,但在CAS机制上比mysql没有优势,高性能是因为其内存存储的原因,带来的副作用是数据有丢失风险。


来源:blog.csdn.net/new_com/article/details/105568124


PS:防止找不到本篇文章,可以收藏点赞,方便翻阅查找哦。 


往期推荐



char和varchar有哪些区别?varchar最大长度是多少?

节后面试必备:Spring 面试常见问题,做好跳槽准备了嘛!?

SpringBoot+flowable快速实现工作流,优秀的工作流轮子

干掉项目中杂乱的 if-else,试试状态模式,这才是优雅的实现方式!

神器 Markmap !!

几款实用的内网穿透工具,推荐!



ITZOO版权所有丨如未注明 , 均为原创丨转载请注明来自IT乐园 ->京东二面:商品库存的扣除过程,如何防止超卖?
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址