Redis高并发库存超卖解决方案

Redis高并发场景下库存超卖的根本原因在于“读-判-写”操作的非原子性——即使DECR本身是原子命令，但先GET判断库存再DECR扣减的两步分离逻辑，在高并发时会导致多个客户端同时读到临界库存值（如1）并全部扣减，最终库存变负；真正可靠的解决方案是用Lua脚本将库存校验与扣减封装为服务端一次性、原子执行的逻辑，确保整个业务判断闭环在Redis内部完成，同时需规避KEYS/ARGV使用错误、脚本阻塞过长、集群跨slot等常见陷阱，并严格依据脚本返回值驱动后续业务流程，而非依赖网络响应成败——原子性的关键不在于是否用了Lua，而在于业务规则是否完整、严谨地收敛于一次不可分割的执行单元中。

为什么单靠 DECR 会超卖

因为 DECR 虽然是原子命令，但库存校验（比如“是否 > 0”）和扣减是两步操作。高并发下多个客户端可能同时读到库存=1，然后都执行 DECR，结果变成 -1。

• 典型错误现象：GET stock:1001 返回 1，但最终查到 GET stock:1001 是 -2
• 本质是“读-判-写”没锁住，Redis 的单命令原子 ≠ 多命令事务原子
• 用 WATCH + MULTI 也能做，但失败重试成本高、客户端逻辑复杂，不推荐用于秒杀类场景

用 Lua 脚本实现“判断+扣减”原子执行

Lua 脚本在 Redis 服务端一次性运行，整个脚本就是原子的。关键不是“用了 Lua”，而是把校验和修改写进同一段脚本里。

• 常见错误：脚本里用 redis.call("GET", KEYS[1]) 再手动 if 判断——这没问题，但必须确保后续扣减也发生在同一脚本内
• 正确姿势：用 redis.call("DECRBY", KEYS[1], ARGV[1]) 后立刻检查返回值，或先 GET 再 DECR 并判断结果
• 示例脚本（安全扣减 1 件）：

  if redis.call("GET", KEYS[1]) >= tonumber(ARGV[1]) then
    return redis.call("DECRBY", KEYS[1], ARGV[1])
  else
    return -1
  end

• 调用方式：EVAL "脚本内容" 1 stock:1001 1；生产环境建议先 SCRIPT LOAD 再 EVALSHA，减少网络传输

注意 Lua 脚本的参数和作用域限制

KEYS 和 ARGV 是唯一能从客户端传进 Lua 的变量，且必须显式声明个数。脚本里不能访问外部变量，也不能调用非 Redis 命令。

• 容易踩的坑：KEYS[1] 写成 KEYS[0]（Lua 数组从 1 开始）、ARGV[1] 类型是 string，要 tonumber() 才能比较大小
• 性能影响：脚本执行期间会阻塞其他命令（Redis 单线程），所以脚本必须短小，别做循环、sleep 或 HTTP 请求
• 兼容性：Redis 2.6+ 支持，但集群模式下所有 key 必须落在同一个 slot，否则报 CROSSSLOT 错误——解决方法是用 {} 包裹 key 名强制哈希到同 slot，比如 stock:{1001}

扣减成功后，怎么通知业务层真正下单

脚本返回值是唯一可靠信号。不要依赖“脚本没报错就成功”，必须检查返回值是否 ≥ 0（或按你约定的业务码）。

• 典型错误：脚本返回 -1，但客户端没判断，直接走后续创建订单逻辑，导致订单无库存
• 建议返回值语义清晰：比如 1 表示扣减成功，0 表示库存不足，-1 表示 key 不存在
• 如果需要记录日志或发消息，不要在 Lua 里做，而是在客户端根据返回值决定是否触发后续动作
• 极端情况：脚本执行成功，但客户端网络超时收不到响应——这时得靠幂等设计，比如用订单号做去重，而不是反复重试扣减

Redis 的原子性只保到命令或脚本粒度，库存控制的边界在脚本里怎么写，比用不用 Lua 更关键。很多人写了脚本却还在外面做 if 判断，等于白搭。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis高并发库存超卖解决方案》文章吧，也可关注golang学习网公众号了解相关技术文章。