Java教程

电商技术里的库存扣减

本文主要是介绍电商技术里的库存扣减,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

库存扣减

当有很多人同时在买一件商品时(假设库存充足),每个人几乎同时下单成功,给人一种并行的感觉。

但真实情况,库存只是一个数值,无论是存在 MySQL 数据库还是 Redis 缓存,减值时都要控制顺序,只能串行来扣减,当然为了保证安全性,会设计一些锁控制操作。

image


库存扣减关键技术点

  • 同一个商品,库存数量是共享
  • 剩余库存要大于等于本次扣减的数量,否则会出现超卖现象,引发资损
  • 对同一个数量多用户并发扣减时,要注意并发安全,保证数据的一致性
  • 类似于秒杀这样高 QPS 的扣减场景,要保证性能与高可用
  • 对于购物车下单场景,多个商品库存批量扣减,要保证事务
  • 如果有交易退款,保证库存扣减可以返还:返还的数据总量不能大于扣减的总量;返还要保证幂等;可以分多次返还

数据库扣减方案

主要是依赖数据库特性来保证扣减的一致性,逻辑简单,开发部署成本很低。

依赖的数据库特性:

  • 依赖数据库的乐观锁(比如:版本号或者库存数量)保证数据并发扣减的强一致性
  • 借助事务特性,针对购物车下单批量扣减时,部分扣减失败,数据回滚

image

首先会查询当前商品的剩余库存(可能不准确,但没关系,这里只是第一步粗略校验),前置校验,如果已经没有库存,前置拦截生效,减少对数据库的写操作。

毕竟读操作不涉及加锁,并发性能高。


数据库包含两张表:库存表、流水表。

库存表:

字段 说明
sku_id 商品id
leaved_amount 剩余可购买数量

当用户进行取消订单、申请退货退款,需要把数量加回来。如果商家补过库存,需要在此基础上额外加上增量库存。

流水表:

字段 说明
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 ,表示库存不足,需要回滚。

扣减成功后,需要记录扣减流水,并与订单明细记录做关联:

  • 当用户归还数量时,需要带回此编号,用来标识此次返还属于历史上的具体哪次扣减。
  • 进行幂等性控制。当用户调用扣减接口出现超时时,因为用户不知道是否成功,用此编号进行重试或反查。在重试时,使用此编号进行标识防重。

数据库扣减方案【第一次优化】

数据库扣减方案第一次升级主要是针对库存前置校验模块的优化,作为前置拦截器,承载的流量很大,如果将流量全部压到主库上,很容易把数据压垮。我们考虑把数据库架构升级。

image

  • 采用了读写分离方式,新增加了一套从库,借助 MySQL 自带的数据同步能力。库存校验时读取从数据库。
  • 当然,数据同步有一定的时间延迟,从库的数据新鲜度有一定的滞后性,所以这个库存校验结果并不一定准确,但却能拦截大部分的无效流量。
  • 最终能不能成功购买,由主库的乐观扣减 SQL 来控制,并不会影响最终扣减的准确性。大大减轻主库的查询压力。

数据库扣减方案【第二次优化】

引入了从库,确实能分摊主库很大一部分压力,但是面对秒杀这种万级 QPS 流量,MySQL 的千级 TPS 根本支撑不了,需要进一步升级读取的性能。

image

  • 此时引入缓存中间件(如 Redis),将 MySQL 的数据定时同步到缓存中,库存校验模块,从 Redis 中查询剩余的库存数据。由于缓存基于内存操作,性能比数据库高出几个数量级,单台 Redis 实例可以达到 10W QPS 的读性能。
  • 该方案升级后,基本上解决了在前置库存校验环节及获取库存数量接口的性能问题,提高了系统整体性能,提供较好的用户体验。
  • 补充说明:如果并发量还是很高的话,可以考虑引入缓存集群,将不同的秒杀商品 SKU 尽量均匀分布在多个 Redis 节点中,从而分摊掉整体的峰值 QPS 压力。(参考缓存热点的解决方案)。

数据库方案分析

优点:

  • 借助数据库的 ACID 特性,业务上不会出现超卖、少买现象
  • 实现简单,如果项目工期紧张,或者开发资源不足情况下非常适用

不足:

  • 如果参与秒杀的 SKU 非常多,最后的写操作都是基于库存主库,性能压力会比较大。

纯缓存扣减方案

Redis 采用单线程的事件模型,具有原子性的特性。当有多个客户端给 Redis 发送命令时,Redis 会按照接收到的顺序串行化执行。对于还未被调度的命令,则放在队列里排队等待。

库存扣减为了保证数据并发安全,要求原子性,而 Redis 正好满足扣减类的特殊性要求,是个不错的技术选型。

image

首先,设计Redis的数据模型

剩余库存(k-v结构):
key:sku_leaved_amount_{sku_id}
value:剩余的库存数值

流水(hash结构):
key:inventory_flow_{sku_id}
hash—key:订单明细id(不同业务场景的全局性id,用来做幂等控制)
hash—value:本次购买的数量

  • 对于购物车下单,多个商品批量扣减,我们需要按单个商品循环发起 Redis 调用。但是多个 Redis 命令无法保证原子性。
  • 我们可以采用 Lua 脚本形式,将这些命令打包到一个脚本中,作为一个命令发送给 Redis 执行,从而保证了原子性。
  • Lua 是一个类似 JavaScript、Shell 等的解释性语言,它可以完成 Redis 已有命令不支持的功能。用户在编写完 Lua 脚本之后,将此脚本上传至 Redis 服务端,服务端会返回一个标识码代表此脚本。
  • 在实际执行具体请求时,将数据和此标识码发送至 Redis 即可。Redis 会和执行普通命令一样,采用单线程执行此 Lua 脚本和对应数据。

Lua 脚本执行流程:

  • 首先根据订单明细 id 查询扣减流水,是否已经操作过,做幂等性校验
  • 然后查询商品的剩余库存,并根据下单购买数做校验,只要有一个商品数量不足,则返回失败
  • 修改所有商品的缓存中的剩余库存数
  • 缓存中插入扣减流水记录

当 Redis 扣减成功后,应用程序再将此次扣减异步化保存到数据库中,持久化存储,毕竟 Redis 只是临时性存储,有宕机风险,会丢失数据。


缓存方案分析

  • Redis 缓存方案,借助了缓存的高性能,承载更高的并发。但是没有数据库的 ACID 特性,极端情况下,可能出现少卖情况。
  • 为了避免少卖情况发生,纯缓存方案需要做大量的对账、异常处理的设计,系统复杂度增加很多。
  • 纯缓存方案适合一些高并发、大流量场景,但对数据准确度要求不是特别苛刻的业务场景。

风险:上述 Lua 脚本把多条命令打包在一起,虽然保证了原子性,但不具备事务回滚特性。

比如,库存扣减成功了,此时 Redis 宕机,扣减流水并没有插入成功,应用程序认为本次 Redis 调用是失败的,前台给用户反馈错误提示,但是已经扣减的数量不会回滚。

当 Redis 故障修复后,再次启动,此时恢复的数据已经存在不一致了。需要结合 Redis 和数据库做数据核对 check,并结合扣减服务的日志,做数据的增量修复。


基于分库分表的扣减方案

除了纯缓存化方案外,我们还可以考虑将库存表进行水平拆分,分摊洪峰压力。

image

假如库存表的 QPS 要求是 1.6 万,经过拆分成 16 张表后,如果数据分布均匀,每个物理表预计处理 1000 QPS,完全处于 MySQL 单实例的承载范围之内。

另外拆分后,单表的数据量也会相应减少很多,假如分表前有一个亿数据,分表后每张表不到 1 千万,索引查询性能也会快很多。

注意:同一次扣减业务,库存扣减和插入流水要放在同一个分库中,通过事务保证一致性,满足同时成功或同时失败。

如果数据分布和业务请求足够均匀,理论上经过分库分表设计后,整个系统的吞吐量将会是线性的增长,主要取决于分表实例的数量。


其他扣减方案

  1. 如果某个 sku_id 的库存扣减过热,单台实例支撑不了(MySQL 官方测评:一般单行更新的 QPS 在 500 以内),可以考虑将一个商品的大库存拆分成 N 份,放在不同的库中(也就是说所有子库的库存数总和才是一件商品的真实库存),由于前台的访问流量非常大,按照均分原则,每个子库分到的流量应该差不多。

    上层路由时只需要在 sku_id 后面拼接一个范围内的随机数,即可找到对应的子库,有效减轻系统压力。

  2. 单条商品库存记录更新过热,也可以采用批量提交方式,将多次扣减累计计数,集中成一次扣减,从而实现了将串行处理变成了批处理,也可以大大减轻数据库压力。

  3. 引入 RocketMQ 消息队列,经过前置校验后,如果有剩余库存,则把创建订单的操作封装成消息发送给 MQ,订单系统从 RocketMQ 中以特定的频率消费,创建订单,该方案有一定的延迟性。

这篇关于电商技术里的库存扣减的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!