秒杀系统整体架构怎么设计？一次讲清限流、削峰、库存、幂等与高并发链路

秒杀系统整体架构怎么设计？一次讲清限流、削峰、库存、幂等与高并发链路

大家好，我是一名有 4 年工作经验的 Java 后端开发。
秒杀几乎是高并发系统里最经典的话题之一。
但很多文章只讲某一个点，比如 Redis 扣库存，真正完整的秒杀系统链路反而没有讲透。
这篇文章我想从整体架构视角，把秒杀系统到底应该怎么设计系统性地聊一遍。

🦅个人主页
🐼

一、秒杀系统到底难在哪

秒杀不是普通下单放大，而是：

• 瞬时流量极高
• 库存极少
• 热点极集中
• 并发冲突极强
• 用户体验要求高

真正难的点通常包括：

• 入口限流
• 热点拦截
• 库存预扣减
• 消息削峰
• 订单异步化
• 幂等与补偿

所以秒杀系统不是一个“下单接口优化”问题，而是一整条链路设计问题。

二、推荐的整体链路

我更推荐把秒杀拆成这些阶段：

1. 活动预热
2. 网关限流
3. 资格校验
4. Redis 预扣减
5. MQ 削峰
6. 异步创建订单
7. 支付与回补
8. 对账与补偿

这才是完整的秒杀链路。

三、为什么不能让所有请求直接打数据库

因为秒杀最典型的特点就是：

• 热点商品
• 热点库存
• 热点用户请求

如果所有请求都直接打 MySQL，就很容易：

• 热点行竞争严重
• 数据库直接成为瓶颈
• 接口 RT 飙升

所以秒杀链路一定要尽量把流量挡在数据库前面。

四、每一层分别解决什么问题

4.1 网关限流

先挡住超量请求。

4.2 资格校验

比如：

• 是否登录
• 是否实名
• 是否是目标活动用户

把无效请求提前拦掉。

4.3 Redis 预扣减

快速原子判断库存是否还有。

4.4 MQ 削峰

把同步下单改成异步下单，降低数据库峰值压力。

4.5 幂等和补偿

防止重复下单、消息重复消费、库存账不一致。

五、最核心的几个技术点

5.1 Redis 预扣减不是最终账本

它只是流量闸门。
真正的最终业务账本仍然应该在数据库。

5.2 MQ 异步下单必须做幂等

因为消息可能重复投递。

5.3 库存回补要配套设计

用户抢到了不支付，库存不能一直锁着。

5.4 热 Key 治理不能少

秒杀库存、活动配置、资格校验这些都是热点。

六、秒杀系统的典型架构图

可以把它理解成这样：

用户请求 -> 网关限流 -> 活动资格校验 -> Redis 预扣减库存 -> MQ 投递秒杀单消息 -> 异步创建订单 -> 支付成功/失败 -> 回补或转正式库存

这条链路里每一步都在解决不同问题。

七、最容易踩的坑

7.1 只做 Redis 扣库存，不做数据库落账

最后库存对不上。

7.2 只做异步化，不做幂等

重复下单和重复扣库存一定会出问题。

7.3 只做限流，不做热 Key 治理

Redis 还是可能被热点打爆。

7.4 只关注抢成功，不关注支付后流程

真正线上问题很多都在回补、关单、补偿这里。

八、面试中怎么回答

如果面试官问你：

秒杀系统整体架构一般怎么设计？

你可以这样回答：

第一，秒杀系统的核心不是优化一个下单接口，而是把整条链路拆开，分别解决入口超量流量、热点库存冲突、数据库削峰和最终一致性问题。

第二，我通常会在网关层做限流，在业务层做活动资格校验，然后通过 Redis 预扣减库存把大部分请求挡在数据库外，再用 MQ 异步创建订单实现削峰填谷。

第三，Redis 只负责高并发入口控制，数据库才是最终业务账本，所以异步下单时还要在数据库里做最终库存扣减和订单落库。

第四，整个链路还必须配合幂等、超时关单、库存回补、补偿对账和热点 Key 治理，否则系统只解决了“抢”这一瞬间，后面一样会出问题。

九、总结

秒杀系统真正难的不是“抢”，而是如何在：

• 超高并发
• 超低库存
• 强热点
• 多链路异步

这些约束下，把整条链路真正稳住。

如果只记一句结论，我觉得可以记住这句：

秒杀系统最稳的思路通常不是单点优化，而是“限流 + 热点治理 + Redis 预扣减 + MQ 削峰 + 幂等补偿”的组合设计。

十、结尾

如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注。
后面我会继续整理一些更偏实战的 Java 后端和电商系统设计文章。