一、库存扣减逻辑
1）依赖缓存不依赖数据库，因为缓存能抗更高的tps。纯redis实现可能带来的问题：
a、如果redis实际扣减成功了，但是redis client接口返回失败。可能导致库存的浪费。怎么解决？可以加入库存数据库，每次更新完redis后也更新数据库。然后写一个对账程序，通过对比redis和数据库库存是否一致，很可能出现的case是redis扣减多，数据库扣减少，可以把数据库比redis多的库存加回到redis中。
b、如果redis更新成功，db更新失败了(出现的可能性较小)。可以用日志记录下，把数据库少扣减的部分进行手动扣减。
2）为了避免redis热key，会用到分桶，分桶带来的问题，某些分桶有数据，某些分桶无数据，可能在其他分桶有数据的情况下出现无库存的情况。解决：用户hash到指定的分桶，允许不同用户看到不同的库存余量，所路由到的分桶没有库存时直接展示无库存。
二、下单和扣减库存的顺序问题
1）下单的时候扣减库存，缺点：恶意买家大量下单，将库存用完，但是不付款，真正想买的人买不到。
2）付款的时候扣减库存，下单时前台页面显示最新的库存，下单时不会立即减库存，而是等到买家支付成功时才会减库存。缺点：下单页面显示的库存数可能不是最新的库存数，可能下单的时候有库存，支付的时候可能提示库存不足。
3）预扣库存，下单页面显示最新的库存，买家下单后先预扣库存一段时间(比如30分钟)，等到超过保留时间后自动取消订单或者手动取消订单，将释放库存。预扣库存总数量不能超过总库存数，若达到最大限制后，买家是不能再下单的，为了防止超卖风险
通常来说预扣库存是较通用的方式
标签：场景,扣减,分桶,数据库,redis,库存,下单,设计 From： https://www.cnblogs.com/MarkLeeBYR/p/17416069.html