当 100 万用户争抢 1000 个 code 时，如何防止超卖？

Question

IT Interview Practice · Accepted Answer

把库存计数器放在**一个原子的地方**，并原子地递减它——用 Redis `DECR`（或 Lua 脚本）返回剩余值。如果结果 `< 0`，那个请求就失败了；数据库*绝不*作为并发关卡。其余一切都是关于如何以低成本甩掉另外 999,000 个请求。 ## 架构 ```text 1M clients ─▶ CDN/edge (waiting room, drop bots) ─▶ LB │ Stateless API pods │ Redis: DECR stock (Lua: check+dec+record) │hit>=0 │miss<0 ▼ ▼ enqueue order ─▶ DB reject "sold out" ``` ## 组件与流程 - 边缘处的**等候室 / 准入控制（admission control）**是第一道防线。你不会让 100 万个连接直接冲击 API；一个排队页面（Cloudflare Waiting Room 风格）以受控批次放行用户。这把尖峰（spike）变成了稳流（stream）。 - **Redis 原子递减**是库存的唯一真实来源（single source of truth）。`DECR stock:sale123` 是原子的——不会有两个请求都读到"还剩 1 个"。一个 **Lua 脚本**在一次往返中完成：检查剩余、递减、并记录 `SADD winners:{sale} {user}`，使一个用户不能中奖两次。Lua 在 Redis 上单线程运行，因此整个 check-and-set 是一个原子步骤。 - **订单队列 → DB**：中奖者（结果 `>= 0`）被推入队列；由 worker 异步地把订单写入 Postgres。DB 从不面对 100 万次并发写入——只有约 1000 次中奖写入。 - **拒绝路径**立即向落选者返回"售罄"。快速拒绝是一个特性：它释放连接并保护后端。 ## 面试视角面试官希望看到你准确指出这个**竞态条件（race condition）**：`SELECT stock` 然后 `UPDATE` 两条语句会让两个请求都读到 1000 并都完成售卖——经典的超卖。"好"是"使用事务 / `SELECT ... FOR UPDATE`"；"出色"是认识到行锁会把 100 万请求串行化到一个热点行（hot row）上并使 throughput 崩溃，于是你把争用转移到 Redis 中的单线程原子操作，只持久化中奖者。陷阱是相信没有原子性的应用层检查（`if (stock > 0)`）。 ## 权衡与故障 - **Redis 与 DB `FOR UPDATE`**：Redis 在一个热点键上能处理 10 万+ ops/s；Postgres 行锁会串行化，并在秒杀下崩溃。把 DB 留给持久的订单记录。 - **可用性与正确性**：如果 Redis 在售卖中途故障，你必须 **fail closed**（拒绝）——重新开放售卖有超卖风险。持久化已售数量，以便恢复真实的剩余量。 - **一致性（Consistency）**：售卖后将 Redis 中奖者与 DB 订单进行对账；对于 DB 写入失败的中奖者，必须退还一个名额或重新授予。加入按用户的 rate limit 和 bot 检测，否则脚本会在毫秒内抽干库存。

架构

组件与流程

面试视角

权衡与故障

相关问题