万级并发！电商库存扣减如何设计，如何做到不超卖？( 三 ) _电商库存扣减

palm_tree: 基于分库分表的扣减方案上面提到的数据库方式是基于单库单表玩法，虽然借助 ACID 特性能保证数据的一致性，但是单台mysql的并发能力有限，如何提升性能？
除了纯缓存化方案外，我们还可以考虑将库存表进行水平拆分，分摊洪峰压力。

文章插图

假如库存表的QPS要求是1.6万，经过拆分成16张表后，如果数据分布均匀，每个物理表预计处理 1000 QPS，完全处于mysql单实例的承载范围之内。
另外拆分后，单表的数据量也会相应减少很多，假如分表前有一个亿数据，分表后每张表不到1千万，索引查询性能也会快很多。
注意：
同一次扣减业务，库存扣减和插入流水要放在同一个分库中，通过事务保证一致性，满足同时成功或同时失败。如果数据分布和业务请求足够均匀，理论上经过分库分表设计后，整个系统的吞吐量将会是线性的增长，主要取决于分表实例的数量。
palm_tree: 其他扣减方案还有其他的一些解决方案，这里只是提供一些思路，方案细节就不展开了
1、如果某个sku_id的库存扣减过热，单台实例支撑不了（ mysql官方测评：一般单行更新的QPS在500以内），可以考虑将一个sku的大库存拆分成N份，放在不同的库中（也就是说所有子库的库存数总和才是一件sku的真实库存），由于前台的访问流量非常大，按照均分原则，每个子库分到的流量应该差不多。上层路由时只需要在 sku_id 后面拼接一个范围内的随机数，即可找到对应的子库，有效减轻系统压力。
2、单条sku库存记录更新过热，也可以采用批量提交方式，将多次扣减累计计数，集中成一次扣减，从而实现了将串行处理变成了批处理，也可以大大减轻数据库压力。
3、引入 RocketMQ 消息队列，经过前置校验后，如果有剩余库存，则把创建订单的操作封装成消息发送给MQ，订单系统从RocketMQ中以特定的频率消费，创建订单，该方案有一定的延迟性。