库存扣多了，到底怎么整

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

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

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

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

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

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

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

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