万级并发电商库存扣减设计.docxVIP

? ? 万级并发电商库存扣减如何设计，如何做到不超卖 ? ? ? 前言： 随着中国消费认知的不断升级，网购走近千家万户，越来越被人们所接受。淘宝、唯品会、考拉、京东、拼多多等逐渐成为我们生活的重要组成部分。 除了常规的购物下单外，这些电商平台还经常搞一些双十一活动，秒杀、大促、限时购，各种营销玩法，层出不穷！?今天就来跟大家聊一聊电商技术里的库存扣减。 ? 当有很多人同时在买一件商品时（假设库存充足），每个人几乎同时下单成功，给人一种并行的感觉。但真实情况， 库存只是一个数值，无论是存在mysql数据库还是redis缓存，减值时都要控制顺序，只能串行来扣减，当然为了保证安全性，会设计一些锁控制操作。 palm_tree: 库存扣减关键技术点 同一个SKU，库存数量是共享 剩余库存要大于等于本次扣减的数量，否则会出现?超卖?现象，引发资损 对同一个数量多用户并发扣减时，要注意并发安全，保证数据的一致性 类似于秒杀这样高QPS的扣减场景，要保证性能与高可用 对于购物车下单场景，多个商品库存批量扣减，要保证事务 如果有?交易退款?，保证库存扣减可以返还 返还的数据总量不能大于扣减的总量 返还要保证幂等 可以分多次返还 palm_tree: 数据库扣减方案 主要是依赖数据库特性来保证扣减的一致性，逻辑简单，开发部署成本很低。 依赖的数据库特性： 依赖数据库的乐观锁（比如：版本号或者库存数量）保证数据并发扣减的强一致性 借助事务特性，针对购物车下单批量扣减时，部分扣减失败，数据回滚 ? 最上面会查询当前的剩余库存（可能不准确，但没关系，这里只是第一步粗略校验），前置校验，如果已经没有库存，前置拦截生效，减少对数据库的写操作。毕竟读操作不涉及加锁，并发性能高。数据库包含两张表：库存表、流水表。 1、库存表 字段 说明 sku_id 商品规格id leaved_amount 剩余可购买数量 当用户进行取消订单、申请退货退款，需要把数量加回来 如果商家补过库存，需要在此基础上额外加上增量库存 2、 流水表 字段 说明 id 主键id sku_id 商品规格id order_detail_id 订单明细id quantity_trade 本次购买扣减的数量 用于查看明细、对账、盘货、排查问题等 在扣减后，某些场景下需要返还也依赖流水 单条商品的扣减SQL大致如下： update inventory set leaved_amount = leaved_amount - #{count} where sku_id=123 and leaved_amount = #{count} 此 SQL 采用 类似乐观锁的方式实现了原子性，在 where 条件里判断此次购买的数量小于等于剩余的数量。在扣减服务的代码里，判断此 SQL 的返回值，如果值为 1 ，表示扣减成功。否则，返回 0 ，表示库存不足，需要回滚。 扣减成功后，需要记录扣减流水，并与订单明细记录做关联。 当用户归还数量时，需要带回此编号，用来标识此次返还属于历史上的具体哪次扣减。 进行幂等性控制。当用户调用扣减接口出现超时时，因为用户不知道是否成功，用此编号进行重试或反查。在重试时，使用此编号进行标识防重。 palm_tree: 【数据库扣减方案】第一次升级 举个极端的例子：最新款iPhone秒杀，库存只有5件，活动期间峰值QPS预估在10W，活动结束后，上面的流水表最终只会插入5条记录，但是查询的QPS却接近?10W QPS?，读的压力非常大。 所以，数据库扣减方案第一次升级主要是针对?库存前置校验?模块的优化，作为前置拦截器，承载的流量很大，如果将流量全部压到主库上，很容易把数据压垮。我们考虑把数据库架构升级。 ? 采用了?读写分离?方式，新增加了一套从库，借助mysql自带的数据同步能力。?库存校验时读取从数据库。 当然，数据同步有一定的时间延迟，从库的数据新鲜度有一定的滞后性，所以这个?库存校验?结果并不一定准确，但却能拦截大部分的?无效流量?。最终能不能成功购买，由主库的?乐观扣减SQL来控制，并不会影响最终扣减的准确性。大大减轻主库的查询压力。 palm_tree: 【数据库扣减方案】第二次升级 引入了从库，确实能分摊主库很大一部分压力，但是面对秒杀这种万级QPS流量，mysql的?千级TPS?根本支撑不了，需要进一步升级读取的性能。 ? 此时引入缓存中间件（如Redis），将mysql的数据定时同步到缓存中 库存校验?模块，从redis中查询剩余的库存数据。由于缓存基于内存操作，性能比数据库高出几个数量级，单台redis实例可以达到10W QPS的读性能 该方案升级后，基本上解决了在前置?库存校验?环节及?获取库存数量接口?的性能问题，提高了系统整体性能，提供较好的