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

[rocky114]

比如像京东这样的网站，商品 A 的库存是 10000 件
问题 1：单机架构会有性能瓶颈，不能支持大量用户同时购买
问题 2：分布式架构 node1, node2 每个都是 5000 件，前端应该展示库存为多少？ node1 库存变为 0，node2 库存还有 3000 件，这个时候需要用 rpc 请求减少 node2 的库存吗？

[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