库存扣多了，到底怎么整？

发布时间：2025-11-05 01:05:16 来源：云智核 作者：系统运维

业务复杂、库存扣多数据量大、到底并发量大的库存扣多业务场景下，典型的到底互联网架构，一般会分为这么几层：

对于库存业务，一般有个库存服务，到底提供库存的库存扣多查询、扣减、到底设置等RPC接口：

用户下单前，一般会对库存进行查询，有足够的香港云服务器存量才允许扣减：

如上图所示，通过查询接口，得到库存是5。

用户下单时，接着会对库存进行扣减：

如上图所示，购买3单位的商品，通过扣减接口，最终得到库存是2。

希望设计往往有容错机制，例如“重试”，如果通过扣减接口来修改库存，在重试时，可能会得到错误的数据，导致重复扣减：

如上图所示，如果数据库层面有重试容错机制，可能导致一次扣减执行两次，最终得到一个负数的错误库存。

重试导致错误的根本原因，是因为“扣减”操作是一个非幂等的操作，不能够重复执行，改成设置操作则不会有这个问题：

如上图所示，同样是购买3单位的商品，源码库通过设置库存操作，即使有重试容错机制，也不会得到错误的库存，设置库存是一个幂等操作。

在并发量很大的情况下，还会有其他的问题：

如上图所示，两个并发的操作，查询库存，都得到了库存是5。

接下来用户发生了并发的购买动作(秒杀类业务特别容易出现)：

如上图所示：

其根本原因是，设置操作发生的时候，没有检查库存与查询出来的库存有没有变化，理论上：

实际执行的时候：

升级修改很容易，将库存设置接口，stock-service上执行的：

升级为：

这正是大家常说的“Compare And Set”(CAS)，是一种常见的降低读写锁冲突，保证数据一致性的方法。

总结

在业务复杂，数据量大，并发量大的情况下，库存扣减容易引发数据的不一致，常见的优化方案有两个：

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

相关文章