概述咱这次把面试必问的「秒杀系统」彻底讲明白不用搞复杂术语不管你是想知道大厂怎么扛住几十万人抢货的大方案还是自己做小项目、毕设想快速上线秒杀功能都能看懂。大厂的方案能扛百万并发从前端到数据库层层防护小项目的方案更实在用 JavaVue3配合 Redis、MQ 这些工具几行核心代码就能跑起来还解决了超卖、重复下单这些关键问题最后再把面试官常问的题整理好直接背了就能用一、先搞懂秒杀到底难在哪1、纯理论分析秒杀本质就是同一时间几万甚至几十万人抢几百件商品。核心痛点就两个流量洪峰平时系统可能每秒几百请求秒杀瞬间冲到几万、几十万直接把服务器冲垮。数据一致性不能超卖库存卖成负数、不能重复下单、不能让同一个人抢到多件。所以整个系统设计就是围绕「把请求拦在半路上只让真正有效的请求打到数据库」来做的。2、分两种方式考虑毕竟不是谁都能参与互联网项目的秒杀的非常少大部分也就是基于秒杀的思路在自己的业务场景下模拟一部分实现而已大系统核心是「分层限流 缓存预热 异步解耦」从前端到数据库层层过滤把流量降到最低。小系统核心是「Redis 扣库存 MQ 异步下单 简单防刷」用最少的代码实现秒杀功能先跑起来再说优化。3、技术点补充Redis 过期策略用户抢购标记 Keyseckill:user:{userId}:{productId}可设置过期时间如活动结束后 1 小时避免 Redis 内存膨胀Lua 脚本优化可将「防重复下单」逻辑完全移入 Lua前置hasKey可省进一步减少 Redis 交互库存回滚若 MQ 消费失败如 DB 异常需回滚 Redis 库存避免 Redis 与 DB 库存不一致分布式锁若多实例部署可配合 Redisson 分布式锁增强并发控制本方案 Lua 已保证原子性可省略。二、大厂版高并发秒杀系统全链路设计 【这个提一下即可重点是小项目版本】1. 前端层先把大部分请求拦在用户浏览器里用户打开秒杀页面第一步就开始「限流」静态页面放 CDN把商品图片、页面结构、样式这些不变的东西全扔到 CDN 上。用户不用请求你的服务器直接从就近节点加载页面减轻主服务器压力。秒杀按钮控制活动开始前按钮直接灰掉不让点点了一次之后立刻禁用按钮防止用户疯狂刷新、重复点击加个滑动验证码 / 人机验证把脚本、羊毛党挡在门外实在扛不住就做个「排队中」页面让用户知道系统在处理别乱刷新。2. 接入层多级负载均衡 限流把流量削峰这一层就是给服务器「减负」不让洪峰直接冲进来1 级负载均衡硬件级用 F5/LVS 这种硬件负载均衡器做集群高可用Keepalived 保证挂了一台还有备用的把请求分到不同的 Nginx 节点。2 级负载均衡Nginx 集群Nginx 再把请求轮询 / 随机分到不同的网关服务。3 级限流NginxLua在 Nginx 层用 Lua 脚本直接做限流、防刷 —— 比如同一个 IP / 用户1 秒最多发 10 次请求超过直接返回「稍后再试」根本不让请求进到后面的 Java 服务。3. 服务层缓存 异步 分布式锁保证性能和安全这是 Java 后端的主战场核心就是「少查数据库多走缓存异步处理」数据预热秒杀开始前把商品库存、活动信息提前加载到 Redis 里别等用户来了再查 DB。库存扣减RedisLua用 Redis 存库存通过 Lua 脚本保证「判断库存 0 → 扣减库存」是原子操作避免超卖库存扣完直接在 Redis 里标记「售罄」后面的请求直接返回不用再往下走。防重复下单用用户 ID 商品 ID 做 Redis Key下单前先查有没有这个 Key有就说明已经抢过了直接拒绝或者用分布式锁Redisson同一个用户同一时间只能发起一次下单请求。异步下单MQ 解耦秒杀服务只做「校验 扣库存」然后发一条 MQ 消息到消息队列比如 RabbitMQ/Kafka直接返回用户「排队中」下单服务慢慢消费 MQ 消息真正去创建订单、扣减 DB 库存用户后续查订单状态就行。分布式锁如果不用 Lua 脚本就用 Redisson 的分布式锁保证同一商品同一时间只有一个请求能扣库存防止超卖。