🚀 秒杀系统中如何解决超卖问题（架构级深度解析）

📌 一、问题背景

秒杀系统是典型的高并发场景，在短时间内会有大量请求同时访问库存资源，例如抢购手机、票务、限量商品等。 在这种场景下，最核心的问题就是：如何保证库存不会被超卖。

所谓超卖，指的是库存已经为 0，但系统仍然允许多个请求成功扣减库存，导致库存变为负数或订单超过实际库存。

在单体系统中，这个问题可能通过数据库事务即可解决，但在分布式高并发场景下，问题会被无限放大。

例如：

• 1000 件商品
• 10 万用户同时抢购
• 瞬时 QPS 达到 5W+

如果没有合理的控制策略，数据库极易被击穿，同时库存数据会严重不一致。

🎯 二、核心原理

超卖问题的本质是并发条件下的资源竞争，多个请求同时读取库存并修改库存，导致数据不一致。

核心解决思路可以归纳为三类：

• 控制并发（锁机制）
• 削峰填谷（异步化）
• 最终一致性（缓存 + DB 双写控制）

从架构层面来看，秒杀系统通常采用： “前端限流 + Redis 原子扣减 + MQ 异步落库 + DB 最终一致” 的组合方案。

📊 三、数据结构分析

秒杀库存通常存储在以下几种结构中：

• MySQL（最终数据源）
• Redis（高并发库存缓存）
• 本地缓存（极限优化场景）

Redis 常用结构：

方案1：String类型库存

stock:1000

方案2：Hash结构（扩展字段）

HSET seckill:itemId stock 1000 sold 0

其中最常见的是 String + Lua 脚本方式进行原子扣减。

⚙️ 四、算法分析

秒杀核心算法并不是复杂计算，而是原子性控制 + 并发安全。

关键算法包括：

• CAS（Compare And Set）
• Redis Lua 原子脚本
• 数据库乐观锁
• 分段锁 / 分片库存

其中 Redis Lua 脚本是最常用方案，因为它保证执行过程不可中断。

Lua 原子扣减逻辑（示意）

if stock > 0 then
  stock = stock - 1
  return 1
else
  return 0
end

通过 Lua 脚本可以保证检查库存与扣减库存是一个原子操作。

🔄 五、执行流程

典型秒杀请求流程如下：

用户请求
→ Nginx限流
→ Redis库存预扣减
→ 成功则进入MQ队列
→ 消费者创建订单
→ 写入MySQL
→ 返回结果

如果 Redis 扣减失败，则直接返回“库存不足”，避免数据库压力。

📦 六、实际案例

假设某电商平台进行 iPhone 秒杀：

• 库存：1000 台
• 并发请求：50 万

如果直接访问数据库，会导致：

• 数据库连接池耗尽
• 行锁竞争严重
• 事务阻塞

优化后流程：

请求 → Redis扣减 → MQ排队 → 异步写库

最终结果：

• 库存不会超卖
• 系统稳定
• 请求削峰明显

⚖️ 七、优缺点分析

❓ 八、面试常见问题

1. 秒杀系统如何避免超卖？

通过 Redis 原子扣减 + MQ 异步落库 + 数据库最终一致性保证。

2. 为什么不用数据库直接扣减库存？

因为高并发下会产生行锁竞争，严重影响性能。

3. Redis 如何保证原子性？

通过 Lua 脚本执行，实现单线程原子操作。

4. MQ 在秒杀中的作用是什么？

用于削峰填谷，将高并发请求异步化处理。

🔥 九、总结

秒杀系统的核心不是“快”，而是正确性 + 一致性 + 高并发控制能力。

解决超卖问题的本质是构建一套完整的分层架构：

• 前端限流（减少请求）
• Redis 原子扣减（快速过滤）
• MQ 异步削峰（流量缓冲）
• 数据库最终一致（数据落地）

最终形成一条完整的高并发处理链路，使系统在极端流量下依然稳定运行。