秒杀系统整体架构怎么设计一次讲清限流、削峰、库存、幂等与高并发链路大家好我是一名有 4 年工作经验的 Java 后端开发。秒杀几乎是高并发系统里最经典的话题之一。但很多文章只讲某一个点比如 Redis 扣库存真正完整的秒杀系统链路反而没有讲透。这篇文章我想从整体架构视角把秒杀系统到底应该怎么设计系统性地聊一遍。个人主页文章目录秒杀系统整体架构怎么设计一次讲清限流、削峰、库存、幂等与高并发链路一、秒杀系统到底难在哪二、推荐的整体链路三、为什么不能让所有请求直接打数据库四、每一层分别解决什么问题4.1 网关限流4.2 资格校验4.3 Redis 预扣减4.4 MQ 削峰4.5 幂等和补偿五、最核心的几个技术点5.1 Redis 预扣减不是最终账本5.2 MQ 异步下单必须做幂等5.3 库存回补要配套设计5.4 热 Key 治理不能少六、秒杀系统的典型架构图七、最容易踩的坑7.1 只做 Redis 扣库存不做数据库落账7.2 只做异步化不做幂等7.3 只做限流不做热 Key 治理7.4 只关注抢成功不关注支付后流程八、面试中怎么回答九、总结十、结尾一、秒杀系统到底难在哪秒杀不是普通下单放大而是瞬时流量极高库存极少热点极集中并发冲突极强用户体验要求高真正难的点通常包括入口限流热点拦截库存预扣减消息削峰订单异步化幂等与补偿所以秒杀系统不是一个“下单接口优化”问题而是一整条链路设计问题。二、推荐的整体链路我更推荐把秒杀拆成这些阶段活动预热网关限流资格校验Redis 预扣减MQ 削峰异步创建订单支付与回补对账与补偿这才是完整的秒杀链路。三、为什么不能让所有请求直接打数据库因为秒杀最典型的特点就是热点商品热点库存热点用户请求如果所有请求都直接打 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 后端和电商系统设计文章。