---
id: backend.redis.scenario.stock-reservation
title: 抢购库存预扣：Lua 原子扣减、防重复下单、异步落库
type: scenario
domain: backend
stack: [redis, mq, mysql]
tags: [秒杀, 库存, Lua, 防超卖, 削峰]
level: advanced
prerequisites: [backend.redis.lock-ratelimit]
est_hours: 3
related: [backend.redis.lock-ratelimit, backend.mq.reliability, backend.redis.interview]
week: [14]
---

# 抢购库存预扣：Lua 原子扣减、防重复下单、异步落库

## 业务背景与问题

电商的限时抢购活动：100 件商品，开抢瞬间几万个请求。之前直接在数据库里 `UPDATE stock SET num = num - 1 WHERE num > 0`，结果数据库行锁排队、连接池被占满，连带其他业务一起变慢；还出现过同一个用户买了多件。

## 约束

- 绝对不能超卖；每人限购 1 件。
- 抢购接口要快速返回结果（成功进入下单 / 已抢光）。
- 数据库是最终的数据来源，Redis 可能丢数据。
- 不能影响其他业务。

## 方案设计

```mermaid
flowchart LR
  U[用户] --> N[Nginx / 网关限流] --> A[抢购接口]
  A -->|Lua 原子预扣| R[(Redis 库存 + 已购用户)]
  A -->|预扣成功：发消息| Q[[消息队列]]
  Q --> C[下单消费者] -->|事务：建订单 + 扣数据库库存| D[(MySQL)]
  C -->|失败：回补 Redis 库存| R
```

1. **层层削峰**：前端按钮防重复点击、网关按用户 / IP 限流、活动未开始直接拒绝。
2. **Redis 预扣**：活动开始前把库存加载到 Redis；Lua 脚本原子执行“是否已购买 → 库存是否大于 0 → 扣减 → 记录用户”。
3. **异步下单**：预扣成功后发消息到 MQ，接口立即返回“抢购成功，订单生成中”；消费者按数据库能承受的速度建订单，用数据库唯一约束 `(活动ID, 用户ID)` 兜底防重复。
4. **对账和回补**：下单失败或超时未支付时回补 Redis 库存；定时对账 Redis 和数据库的库存。

## 关键代码

完整代码和并发测试见 [examples/stock-lock-ratelimit](../examples/stock-lock-ratelimit/)（`stock.go`）：

```lua
-- KEYS[1] = 库存，KEYS[2] = 已购用户集合，ARGV[1] = 用户 ID
if redis.call("SISMEMBER", KEYS[2], ARGV[1]) == 1 then
  return -2                     -- 已经买过
end
local left = tonumber(redis.call("GET", KEYS[1]) or "0")
if left <= 0 then
  return -1                     -- 售罄
end
redis.call("DECR", KEYS[1])
redis.call("SADD", KEYS[2], ARGV[1])
return left - 1
```

测试：100 个用户各点两次、共 200 个并发请求抢 10 件，结果固定是成功 10 次、剩余库存 0、购买人数 10。

## 取舍

| 方案 | 优点 | 缺点 |
| --- | --- | --- |
| 数据库条件更新 | 简单、强一致 | 高并发下行锁排队，拖垮数据库 |
| **Redis Lua 预扣 + MQ 异步下单** | 扛高并发、保护数据库 | 链路长，要处理 Redis 与数据库不一致、消息丢失 |
| Redis `DECR` 后判断负数再 `INCR` 回去 | 不用 Lua | 不好同时做限购；有短暂负数 |
| 分布式锁包住“查 + 扣” | 好理解 | 所有请求串行抢锁，吞吐很低 |

## 易错点

- 先 `GET` 判断再 `DECR`（不是原子的）→ 超卖。
- 预扣成功但消息发送失败 → 库存少了但没有订单。处理：发送失败时回补库存，或者使用可靠消息（见[消息可靠性](../../mq/03-reliability.md)）。
- 消费者重复消费 → 重复建单。用唯一约束和幂等处理。
- 用户抢到后不支付 → 超时取消订单并回补库存（延迟消息，见 MQ 专题）。
- Redis Cluster 下 Lua 脚本涉及的多个 key 必须在同一个槽：key 用相同的哈希标签，如 `stock:{sku1}` 和 `stock:{sku1}:buyers`。

## 面试怎么讲

> “抢购的核心是不超卖和保护数据库。我在 Redis 用 Lua 脚本把‘限购检查、库存检查、扣减、记录用户’做成一个原子操作，预扣成功再发 MQ 异步建订单，数据库用唯一约束兜底防重复；下单失败或超时未支付时回补库存，定时对账。我写了并发测试：200 个请求抢 10 件，成功数固定是 10。”

追问准备：Redis 宕机怎么办（主从 + 对账，极端情况下暂停活动）？为什么不用分布式锁？消息丢了怎么办？