高并发秒杀系统设计全解：从需求拆解到Redis库存实战
- [Bilibili 同步视频](#Bilibili 同步视频)
- [一、需求拆解：把 "大问题" 拆成 "小任务"🎯](#一、需求拆解：把 “大问题” 拆成 “小任务”🎯)
-
- [🔹 商家侧核心动作](#🔹 商家侧核心动作)
- [🔹 用户侧核心流程](#🔹 用户侧核心流程)
- [二、架构选型：单体 vs 微服务，该怎么选？⚖️](#二、架构选型：单体 vs 微服务，该怎么选？⚖️)
-
- [1. 单体架构：小流量场景的 "简洁方案"](#1. 单体架构：小流量场景的 “简洁方案”)
- [❌ 核心缺陷](#❌ 核心缺陷)
- [2. 微服务架构：高并发秒杀的 "标准答案"](#2. 微服务架构：高并发秒杀的 “标准答案”)
- [✅ 核心优势](#✅ 核心优势)
- [架构对比 Mermaid 图](#架构对比 Mermaid 图)
- [三、存储设计：表结构 + 数据流 + 索引优化📊](#三、存储设计：表结构 + 数据流 + 索引优化📊)
-
- [1. 核心数据库表设计](#1. 核心数据库表设计)
- [2. 索引优化：提速 10 倍 +](#2. 索引优化：提速 10 倍 +)
- [3. 秒杀全流程数据流](#3. 秒杀全流程数据流)
- [四、库存扣减：解决 "超卖" 核心难题💥](#四、库存扣减：解决 “超卖” 核心难题💥)
-
- [1. 错误示范：先查后扣，必超卖](#1. 错误示范：先查后扣，必超卖)
- [2. 方案一：事务 + 行锁（不推荐）](#2. 方案一：事务 + 行锁（不推荐）)
- [3. 方案二：原子 UPDATE（推荐）](#3. 方案二：原子 UPDATE（推荐）)
- [五、Redis 库存预热：扛住 10W+ QPS🚀](#五、Redis 库存预热：扛住 10W+ QPS🚀)
-
- [1. 什么是库存预热？](#1. 什么是库存预热？)
- [2. Redis 核心优势](#2. Redis 核心优势)
- [3. 库存预热实战代码](#3. 库存预热实战代码)
- 六、总结：秒杀系统设计核心要点📌
Bilibili 同步视频
在高并发电商场景下，秒杀系统堪称后端架构的 "试金石"------ 瞬间涌入的流量、严苛的一致性要求、极致的性能挑战，每一项都在考验架构设计能力。本文将从需求拆解、架构选型、存储设计、库存扣减、Redis 库存预热五大维度，从零搭建一套稳定、高效的秒杀系统。
一、需求拆解：把 "大问题" 拆成 "小任务"🎯
秒杀系统看似是一个整体功能，实则可从商家侧 与用户侧双向拆解，让复杂问题清晰化：
🔹 商家侧核心动作
-
新建秒杀活动：创建活动基础信息
-
配置秒杀活动：绑定商品、设置价格、限定库存
🔹 用户侧核心流程
-
访问秒杀页面：高并发下页面承载能力
-
商品浏览：快速查询商品与活动信息
-
下单付款：库存扣减 + 订单生成 + 支付完成
一句话总结：秒杀的本质，是对有限库存的高并发抢夺。
二、架构选型：单体 vs 微服务，该怎么选？⚖️
面对高并发，架构直接决定系统生死。我们先对比单体架构 与微服务架构的核心差异。
1. 单体架构：小流量场景的 "简洁方案"
单体架构把秒杀、商品、订单、支付全部打包在一个工程、一个数据库中，适合内部 OA、低访问系统。
❌ 核心缺陷
-
前后端 / 功能模块严重耦合
-
单模块升级需全量发布
-
无法单独扩容，流量集中压垮整机
-
代码冲突多，团队协作困难
-
级联故障：一个模块 Bug 导致全站宕机
-
数据库单点：秒杀流量打崩 DB，所有业务不可用
2. 微服务架构：高并发秒杀的 "标准答案"
微服务将大系统拆分为独立小服务，服务间解耦、数据库独立，是互联网大厂秒杀系统的标配。
✅ 核心优势
-
单一职责：一个服务只做一件事
-
灵活扩缩容：秒杀服务可单独从 10 台扩到 100 台
-
故障隔离：秒杀挂了不影响商品 / 订单 / 支付
-
技术栈自由：秒杀用 Java、订单用 Python 均可
-
数据库隔离：秒杀 DB 压力不扩散
架构对比 Mermaid 图
微服务架构
秒杀服务
秒杀DB
商品服务
商品DB
订单服务
订单DB
支付服务
支付DB
单体架构
秒杀模块
单体数据库
商品/库存模块
订单模块
支付模块
用户请求
网关
图表说明：
-
单体架构：所有模块共用一套数据库，流量集中、耦合度极高
-
微服务架构：服务与数据库一一拆分，支持独立扩容、故障隔离
三、存储设计：表结构 + 数据流 + 索引优化📊
秒杀系统的存储设计，直接影响查询速度与数据一致性。
1. 核心数据库表设计
| 表名 | 关键字段 | 作用 |
|---|---|---|
| 商品信息表 | product_id、name、price、desc | 存储商品基础信息 |
| 秒杀活动表 | seckill_id、product_id、price、count | 绑定活动与商品 |
| 库存信息表 | stock_id、product_id、seckill_id、stock、locked | 记录可售与锁定库存 |
| 订单信息表 | order_id、user_id、product_id、seckill_id、pay_status | 记录订单与支付状态 |
2. 索引优化：提速 10 倍 +
高并发查询必须加索引，否则 DB 直接被打垮：
-
商品表：
product_id主键索引 -
秒杀表：
seckill_id、product_id联合索引 -
库存表：
product_id + seckill_id唯一索引 -
订单表：
order_id、user_id索引
3. 秒杀全流程数据流
订单表 用户 库存表 秒杀表 商品表 商家 订单表 用户 库存表 秒杀表 商品表 商家 选择商品 创建秒杀活动 初始化秒杀库存 查询活动信息 查询商品详情 查询可售库存 创建订单 扣减库存
图表说明：
-
商家侧：先选商品 → 创活动 → 初始化库存
-
用户侧：查活动 → 查商品 → 查库存 → 下单 → 扣库存
四、库存扣减：解决 "超卖" 核心难题💥
库存扣减是秒杀最容易翻车的环节，并发超卖是头号敌人。
1. 错误示范：先查后扣，必超卖
伪代码逻辑：
java
// 错误：查询与扣减分离，并发下失效
int stock = select stock from stock_table where product_id = ? and seckill_id = ?;
if (stock > 0) {
update stock_table set stock = stock - 1;
}❌ 问题：最后 1 件库存，同时 2 个请求都查到 stock=1，都执行扣减，库存变为 -1，出现超卖。
2. 方案一：事务 + 行锁（不推荐）
sql
-- 加行锁，阻塞其他请求
BEGIN;
SELECT stock FROM stock_table WHERE product_id = ? AND seckill_id = ? FOR UPDATE;
IF stock > 0 THEN
UPDATE stock_table SET stock = stock - 1;
END IF;
COMMIT;❌ 缺点：事务耗时、锁竞争激烈，高并发下 DB 直接卡死，不适合秒杀。
3. 方案二：原子 UPDATE（推荐）
sql
-- 扣减时自带库存判断，原子操作
UPDATE stock_table
SET stock = stock - 1
WHERE product_id = ? AND seckill_id = ? AND stock > 0;✅ 优点：数据库原子性保证，无超卖，性能远高于事务。
五、Redis 库存预热：扛住 10W+ QPS🚀
数据库抗不住高并发：MySQL 单机≈1000 QPS，Redis 单机≈100000 QPS，相差 100 倍！
1. 什么是库存预热？
秒杀开始前，把库存数据提前加载到 Redis，所有查询、扣减先走 Redis，最后异步同步到 DB。
2. Redis 核心优势
-
内存型 NoSQL，读写速度极快
-
指令原子性，天然防超卖
-
支持 Lua 脚本，批量操作原子化
-
主备容灾，不丢数据
3. 库存预热实战代码
java
// 秒杀前：把库存写入 Redis
stringRedisTemplate.opsForValue().set("seckill:stock:" + seckillId, totalStock);
// 秒杀扣减：Redis 原子递减
Long stock = stringRedisTemplate.opsForValue().decrement("seckill:stock:" + seckillId);
if (stock < 0) {
// 库存不足，恢复计数
stringRedisTemplate.opsForValue().increment("seckill:stock:" + seckillId);
return "库存不足";
}
// 异步同步到数据库
asyncUpdateStockToDB(seckillId, productId);六、总结：秒杀系统设计核心要点📌
-
需求拆解：商家建活动 + 用户抢库存，分而治之
-
架构选择 ：高并发必用微服务，独立扩容、故障隔离
-
存储设计：四张核心表 + 精准索引，提速查询
-
库存扣减：用原子 UPDATE 防超卖，抛弃事务锁
-
流量削峰 ：Redis 库存预热，扛住 10W+ QPS，保护数据库
一套优秀的秒杀系统，本质是架构解耦 + 缓存提速 + 原子保证的结合体。掌握这套思路，足以应对绝大多数高并发库存场景。