Redis Lua 扣库存实战：原子校验库存和订单幂等，避免超卖

高并发扣库存最怕两个问题：多个请求同时看到库存充足，最后扣成负数；同一个订单因为重试进来多次，导致库存被重复扣减。单独用 GET、DECR、SADD 拼在业务代码里，网络往返多，中间状态也容易被并发请求打断。

Redis Lua 适合处理这类短小的原子逻辑：把库存检查、重复订单判断、扣减库存、记录订单放进同一个脚本，让 Redis 在单线程命令队列中一次处理完成。本文用秒杀扣库存举例，给出一套可复用的写法。

适合人群

适合做秒杀、抢券、预约名额、库存扣减、订单幂等的后端开发者。你需要熟悉 Redis 字符串、集合、基础 Lua 语法，以及库存扣减的业务约束。

目录

• 为什么普通扣减容易超卖
• 库存 Key 和订单集合怎么设计
• Lua 脚本里如何做原子判断
• 返回码如何映射到业务结果
• 常见坑位和上线建议

为什么普通扣减容易超卖

一个常见但危险的流程是：先读库存，再判断库存是否充足，最后扣减库存。低并发时看起来没问题，高并发时多个请求可能同时读到同一个库存值。

例如库存只剩 1 件，两个请求几乎同时进来，都读到库存为 1，然后都认为可以扣减。最后业务侧可能出现超卖、重复订单、补偿流程复杂等问题。

下面这张图展示推荐链路：请求进入 Redis 脚本，先查订单是否已处理，再查库存是否足够，通过后扣减库存并记录订单，整个过程保持原子。

库存 Key 和订单集合怎么设计

先把数据结构设计清楚。一个商品可以使用两个 Key：

• stock:sku:1001：字符串，保存当前可售库存。
• order:sku:1001：集合，保存已经扣减成功的订单号。

订单集合用于幂等判断。请求重试时，如果订单号已经在集合里，说明之前处理过，可以直接返回“重复请求”，不要再次扣库存。

初始化库存可以这样写：

SET stock:sku:1001 100
DEL order:sku:1001

线上环境要注意 Key 命名规范，最好包含业务名、商品 ID 或活动 ID，避免不同活动互相覆盖。

Lua 脚本里如何做原子判断

下面是一个简化版脚本，入参包括库存 Key、订单集合 Key、订单号和扣减数量：

local stock_key = KEYS[1]
local order_key = KEYS[2]
local order_id = ARGV[1]
local count = tonumber(ARGV[2])

if redis.call("SISMEMBER", order_key, order_id) == 1 then
    return 2
end

local stock = tonumber(redis.call("GET", stock_key) or "0")
if stock 

这个脚本的核心是顺序固定：先判断订单是否处理过，再判断库存是否足够，最后才扣库存和记录订单。只要这几个动作在 Redis 内部一次完成，业务侧就不用担心中间被其他请求插队。

返回码如何映射到业务结果

脚本返回码建议保持简单，业务代码只负责映射：

• 1：扣减成功，可以继续创建订单。
• 2：订单已处理，属于重复请求。
• 0：库存不足，直接返回无库存提示。

下面这张图展示返回码分支：成功继续建单，重复请求直接返回已有结果，库存不足走无库存提示。这样业务代码不会把三种状态混在一起。

常见坑位和上线建议

第一，脚本保持短小。 Lua 里只放必要的原子判断，不要放远程接口、复杂报表、长循环。

第二，订单集合要设置生命周期。 秒杀活动结束后，订单幂等集合不需要永久保存，可以按活动周期设置过期时间，避免长期占内存。

第三，库存扣减成功后还要有数据库落单。 Redis 适合挡住高并发扣减，但最终订单状态仍要落到数据库，并设计失败补偿。

第四，返回码要写日志。 记录订单号、商品 ID、返回码和库存 Key，后续排查重复请求或售罄问题会更直接。

第五，灰度压测再上线。 先用小流量验证扣减成功率、重复请求比例和 Redis 延迟，再逐步放大流量。

总结

Redis Lua 扣库存的价值在于把“查订单、查库存、扣库存、记订单”这几个动作合并为一次原子处理。它能减少高并发下的超卖和重复扣减风险，让业务代码只关注返回码和后续建单。

落地时重点控制三件事：Key 设计清楚、脚本逻辑短小、返回码语义稳定。再配合数据库最终落单和补偿机制，库存链路会更稳。