关于数据库商品库存的架构设计问题

• 資深大佬 : sujin190

  想复杂了吧，一般来说就算是大型网站的每日订单量惊人，但是单个商品的瞬时购买量并不会很高，否则那叫秒杀，秒杀系统有专门流程结构，也不需要在统一商品信息里考虑这个啊，所以单个商品单机也就行了，横向扩展还是考虑多个商品就行

  再换句话说，就算你能卖那么多，那么线下发货也会有很大麻烦，这种时候线下发货极有可能是事先就分大区放好存货，然后再分地区发货的，既然如此库存也是分地区的啊，基于收货地址分地区显示库存，横向扩展不自然而然了么

  别太过度设计考虑的太复杂了，基于现实按场景解决就好了，像秒杀了就按秒杀流程去设计，别想着在一个流程中解决所有问题，否则分分钟被坑死

• 資深大佬 : qq316107934

  node 只处理请求逻辑，并不会分布库存，库存这种事情可以交给 cache 或者 db，瞬时量过大的话前面套一层 mq，cache 的主从同步就是另一回事了。以及要注意防止超卖。

• 主 資深大佬 : rocky114

  我本地机器测试 1 秒大概可以 600 次更新操作，那要是单个商品的平时下单量就很高怎么办呢？这里不考虑抢购的方案

• 資深大佬 : YouLMAO

  都是预扣库存的, prepare+submit

• 主 資深大佬 : rocky114

  预扣是指把库存放到缓存里，可以容忍超卖是吗？这样就不会有单个数据实例的性能问题？

• 資深大佬 : Chenamy2017

  @rocky114 首先平时的下单量能不能达到 600 次，不要想当然，
  其次一秒 600 次，能够持续多长时间，不是抢购就排队处理。

• 資深大佬 : westoy

  这不是技术问题， 这是业务问题

  JD 的库存系统是允许存在超卖误差的
  正常销售超卖订单会进入调货流程， 库存调度频率高的商品这个时间差甚至没有感知
  秒杀订单超卖的订单会直接取消
  所以你这个问题对他们来说不存在

• 主 資深大佬 : rocky114

  @Chenamy2017 我只是好奇像京东这样的公司，在商品库存也是做的单节点方案嘛

• 主 資深大佬 : rocky114

  网上有很多高并发的介绍，比如水平分表，垂直分表之类的；商品的库存也可以根据商品分类，分到不同的表里；

• 資深大佬 : YouLMAO

  @rocky114 TCC, 基本交易额在一个亿的电商都是使用 try confirm or cancel