概述：咱这次把面试必问的「秒杀系统」彻底讲明白！不用搞复杂术语，不管你是想知道大厂怎么扛住几十万人抢货的大方案，还是自己做小项目、毕设想快速上线秒杀功能，都能看懂。大厂的方案能扛百万并发，从前端到数据库层层防护；小项目的方案更实在，用 Java+Vue3，配合 Redis、MQ 这些工具，几行核心代码就能跑起来，还解决了超卖、重复下单这些关键问题，最后再把面试官常问的题整理好，直接背了就能用！
一、先搞懂：秒杀到底难在哪？
1、纯理论分析
秒杀本质就是：同一时间，几万甚至几十万人抢几百件商品。
核心痛点就两个：
- 流量洪峰：平时系统可能每秒几百请求，秒杀瞬间冲到几万、几十万，直接把服务器冲垮。
- 数据一致性：不能超卖（库存卖成负数）、不能重复下单、不能让同一个人抢到多件。
所以整个系统设计，就是围绕「把请求拦在半路上，只让真正有效的请求打到数据库」来做的。
2、分两种方式考虑（毕竟不是谁都能参与互联网项目的秒杀的，非常少，大部分也就是基于秒杀的思路，在自己的业务场景下模拟一部分实现而已）
- 大系统：核心是「分层限流 + 缓存预热 + 异步解耦」，从前端到数据库层层过滤，把流量降到最低。
- 小系统：核心是「Redis 扣库存 + MQ 异步下单 + 简单防刷」，用最少的代码实现秒杀功能，先跑起来再说优化。
3、技术点补充
- Redis 过期策略：用户抢购标记 Key（
seckill: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 级限流（Nginx+Lua） ：在 Nginx 层用 Lua 脚本直接做限流、防刷 —— 比如同一个 IP / 用户，1 秒最多发 10 次请求，超过直接返回「稍后再试」，根本不让请求进到后面的 Java 服务。
3. 服务层：缓存 + 异步 + 分布式锁，保证性能和安全
这是 Java 后端的主战场，核心就是「少查数据库，多走缓存，异步处理」：
-
数据预热：秒杀开始前，把商品库存、活动信息提前加载到 Redis 里，别等用户来了再查 DB。
-
库存扣减（Redis+Lua） ：
-
用 Redis 存库存，通过 Lua 脚本保证「判断库存 > 0 → 扣减库存」是原子操作，避免超卖；
-
库存扣完直接在 Redis 里标记「售罄」，后面的请求直接返回，不用再往下走。
-
防重复下单：
-
用用户 ID + 商品 ID 做 Redis Key，下单前先查有没有这个 Key，有就说明已经抢过了，直接拒绝；
-
或者用分布式锁（Redisson），同一个用户同一时间只能发起一次下单请求。
-
异步下单（MQ 解耦） ：
-
秒杀服务只做「校验 + 扣库存」，然后发一条 MQ 消息到消息队列（比如 RabbitMQ/Kafka），直接返回用户「排队中」；
-
下单服务慢慢消费 MQ 消息，真正去创建订单、扣减 DB 库存，用户后续查订单状态就行。
-
分布式锁：如果不用 Lua 脚本，就用 Redisson 的分布式锁，保证同一商品同一时间只有一个请求能扣库存，防止超卖。
