面试官: 秒杀系统典型面试题解析（答案深度解析）持续更新

秒杀系统典型面试题——高并发场景下的“压力测试场”面试官问秒杀从来不是想听你背概念而是想看你有没有在流量洪峰里“活下来”的实战思维。一、为什么秒杀是面试“照妖镜”秒杀本质是典型的“尖峰流量 弱一致性 强业务约束”场景10万用户抢100件商品 → QPS 瞬间冲到 5w日常可能才 200库存必须“不超卖、不少卖”但数据库扛不住高频UPDATE stock stock - 1用户疯狂刷 F5、用脚本、开代理 ——真实世界里的 DDoS 业务攻击混合体所以秒杀不是考“会不会写 SQL”而是考你如何用系统性设计把一道不可能题变成可落地的工程方案。二、核心考察点拆解附原理 误区✅ 1. 高并发处理别让数据库当“人肉沙包”原理数据库尤其是 MySQL的行锁在高并发下会排队、死锁、CPU 打满。SELECT ... FOR UPDATE在秒杀中≈自杀式写法。正确姿势预减库存Redis 原子操作// Lua 脚本保证原子性避免先 get 再 decr 的竞态Stringscriptif redis.call(exists, KEYS[1]) 1 then if tonumber(redis.call(get, KEYS[1])) 0 then return redis.call(decr, KEYS[1]) end end return -1;Longresult(Long)jedis.eval(script,Collections.singletonList(seckill:stock:1001),newArrayList());if(result0){// 库存扣减成功 → 进入下单队列异步化rabbitTemplate.convertAndSend(order.queue,orderId);}❌常见误区“我用了 Redis 缓存库存就高并发了”→ 错如果没用 Lua 或INCR/DECR原子指令多个线程同时GET DECR仍会超卖经典 ABA 问题。✅ 2. 缓存优化不是“加 Redis”就完事而是“缓存穿透/击穿/雪崩”全防御穿透查不存在的 id布隆过滤器前置拦截如bloom:seckill:ids击穿热点 key 过期瞬间大流量逻辑过期 双检锁SET key val EX 300 NX雪崩大量 key 同时过期过期时间加随机扰动EX 300 random(60)⚠️关键认知缓存是“减压阀”不是“保险丝”——它失效时后端必须能兜底降级开关、熔断策略。✅ 3. 接口安全防机器人比防黑客更急迫分层限流接入层Nginxlimit_req zoneseckill burst20 nodelay防 IP 刷网关层Spring Cloud Gateway基于用户 ID / 设备指纹限流Sentinel业务层答题验证简单数学题、滑块非强校验只为提高脚本成本❌致命误区“我加了验证码就安全了”→ 错图形验证码可被 OCR 破解真正有效的是行为分析如同一设备 1s 内请求 5 次 → 直接 403。✅ 4. 容量规划没有压测数据的设计都是纸上谈兵必须回答清楚三个数字峰值 QPS按历史活动 × 3~5 倍预留单机 Redis 承载库存 key 数建议 50w避免 RDB 阻塞消息队列堆积容忍量如 RabbitMQ 单队列 10w 条 → 触发告警并降级为“排队中”页面加分项提出“影子库”压测方案线上流量复制到隔离环境零风险验证扩容效果。✅ 5. 系统设计从“能跑通”到“可运维”的跃迁核心原则动静分离商品页静态化CDN秒杀按钮动态加载带 token读写分离Redis 扣库存写快MySQL 异步落库最终一致失败闭环扣减成功但下单失败 → 自动补偿任务每 5 分钟扫表重试灵魂一问面试官最爱“如果 Redis 宕机了秒杀还能继续吗”→ 正确答案不是“不能”而是“启动降级开关关闭秒杀入口 → 返回‘活动火爆请稍后再试’ → 同时触发告警 自动切换本地缓存Caffeine兜底 5 分钟”体现容灾意识而非理想化假设三、一句话总结面试收尾金句秒杀系统不是拼技术堆砌而是用分层防御、异步削峰、柔性降级在确定性业务规则和不确定性流量风暴之间找到那个可监控、可回滚、可演进的平衡点。—— 你设计的不是代码是“系统的生存策略”。字数986更多Java面试题整理JVM面试题MySQL面试题Redis面试题Spring面试题完整面试题库https://myquotego.com/html/questions?_fromcsdn_123_4