如何设计一个高并发的秒杀系统？
后端开发第 5 / 13 题答题框架
参考思路：流量漏斗(CDN/网关限流)→库存预热与扣减(Redis/Lua)→异步下单(队列削峰)→兜底降级。展示分层思维与取舍。
五个经典回答示范
回答一 · 校招应届版
我按流量漏斗讲：入口层静态化页面和答题验证削峰、CDN 挡掉大部分读；网关层按用户和 IP 限流；服务层库存预热进 Redis，用 Lua 脚本原子判断扣减，扣成功才发消息队列；异步消费落库创建订单，超时未支付回补库存；失败请求快速返回售罄，保护下游。
回答二 · 1-3年经验版
我参与过一次限量发售活动。关键设计：库存分片到多个 key 降低热点、Lua 保证判断加扣减原子性、消息队列把下单落库异步化，数据库只承接削峰后的平稳写。踩的坑是超卖排查：测试环境发现扣减与创建订单间机器崩溃，靠消息事务最终一致和库存对账兜住。上线 QPS 峰值 8 万，零超卖。
回答三 · 资深版
秒杀的本质是在每一层把无效流量尽早拒绝。我会分层讲预算：静态层消化九成、限流层再做筛选、真正到库存层的请求不到百分之一。难点不是扣减而是一致性窗口——Redis 扣减成功到订单落库之间的故障恢复，靠消息重投、幂等消费与库存对账三件套。另外要设计黄牛防线：设备指纹、答题、名单。
回答四 · 追问应对
追问『Redis 扣减原子性怎么做』：Lua 脚本内先判断后扣减，或用 DECR 配合非负判断；『为什么不用 DB 行锁』：热点行锁排队，吞吐被锁竞争压死，DB 只做最终落库；『库存不准了怎么发现』：对账任务周期核对 Redis 与订单成功数，差异告警并冻结相关活动。
回答五 · 反面示范
『秒杀就是数据库加个 where stock>0 的 update，再加个事务，事务保证不会超卖，性能不够就多加几台机器。』——点评：热点单行锁是性能天花板，加机器不解决锁竞争；把一致性完全交给事务说明没理解异步化后的故障窗口。方案停留在单体思维。
怎么练这道题
- 打开 模拟练习，选择「后端开发」方向，限时 3 分钟作答本题。
- 对照上方答题框架，逐点检查：哪些要素没覆盖、哪里表达啰嗦。
- 用自己项目的真实经历替换框架中的占位内容，重讲一遍并录音回听。
这类题在真实面试中常被追问细节，
建议进入限时模式练一遍。