库存扣多了,到底怎么整

业务复杂、数据量大、并发量大的业务场景下,典型的互联网架构,一般会分为这么几层:

调用层,一般是处于端上的browser或者APP站点层,一般是拼装html或者json返回的web-server层服务层,一般是提供RPC调用接口的service层数据层,提供固化数据存储的db对于库存业务,一般有个库存服务,提供库存的查询、扣减、设置等RPC接口:

「DB」库存扣多了,到底怎么整|架构师之路

如上图所示,通过查询接口,得到库存是5。用户下单时,接着会对库存进行扣减:

如上图所示,购买3单位的商品,通过扣减接口,最终得到库存是2。希望设计往往有容错机制,例如“重试”,如果通过扣减接口来修改库存,在重试时,可能会得到错误的数据,导致重复扣减:

如上图所示,如果数据库层面有重试容错机制,可能导致一次扣减执行两次,最终得到一个负数的错误库存。重试导致错误的根本原因,是因为“扣减”操作是一个非幂等的操作,不能够重复执行,改成设置操作则不会有这个问题:

如上图所示,同样是购买3单位的商品,通过设置库存操作,即使有重试容错机制,也不会得到错误的库存,设置库存是一个幂等操作。在并发量很大的情况下,还会有其他的问题:

如上图所示,两个并发的操作,查询库存,都得到了库存是5。接下来用户发生了并发的购买动作(秒杀类业务特别容易出现):

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181002A13QZV00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券