秒杀库存扣减策略 —— 面试官真正想听的深度解析⚠️ 注意面试官问“秒杀库存扣减”绝不是想听你背概念而是考察你是否真正踩过坑、权衡过取舍、理解系统本质。下面我用真实项目视角带你一层层拆解。一、为什么库存扣减是秒杀的“生死线”想象 10 万人同时抢 100 件商品若用select stock from item where id1→if(stock0) update item set stockstock-1必然超卖经典“读-改-写”竞态。数据库行锁InnoDB虽能保一致性但高并发下大量请求排队阻塞TPS 断崖下跌秒杀就变成“秒等”。所以核心目标只有两个字又快又准——既要扛住 5 万 QPS又要确保库存不超卖、不少卖、不重复扣。二、主流策略原理与实战对比重点✅ 1. Redis Lua 原子操作推荐首选-- lua脚本原子执行localstockredis.call(GET,item:1:stock)iftonumber(stock)0thenredis.call(DECR,item:1:stock)return1-- 扣减成功elsereturn0-- 库存不足end原理Redis 单线程模型 Lua 脚本保证整个判断扣减不可分割。✅ 优势毫秒级响应、天然防超卖、无数据库压力⚠️ 误区❌ “用INCR/DECR就够了” → 错必须先校验库存是否 0否则可能扣成负数DECR不检查下限❌ “Lua 脚本太重影响性能” → 实测单机 Redis 可支撑 8~10 万次/秒原子扣减远超 MySQL。✅ 2. 数据库乐观锁兜底/最终一致性UPDATEitemSETstockstock-1WHEREid1ANDstock0;-- 条件中带 stock 0 是关键Java 层判断affectedRows 1决定是否下单成功。✅ 优势强一致性、可审计、适合对账场景⚠️ 误区❌ “加 version 字段就行” → 秒杀场景 version 争抢更激烈失败率远高于 stock 条件更新❌ “失败就重试” → 高并发下重试雪崩必须配合降级如返回“稍后重试”。⚠️ 3. 悲观锁慎用SELECTstockFROMitemWHEREid1FORUPDATE;-- 行锁-- 再 update...问题致命锁住的是整行但秒杀中大量请求会卡在FOR UPDATE等待MySQL 连接池迅速耗尽服务直接雪崩。 面试官听到你说“用悲观锁”基本就判定你没经历过真实大流量。✅ 4. 消息队列异步扣减削峰填谷流程用户请求 → Redis 预减成功 → 发 MQ 消息 → 消费端异步落库 校验 → 失败则补偿发短信/站内信通知用户“订单失效”✅ 优势彻底解耦、抗峰值、支持复杂业务逻辑如风控、优惠券核销⚠️ 误区❌ “MQ 一定能保证不丢消息” → 必须实现生产者 confirm 消费端幂等 死信队列监控❌ “异步不一致” → 通过「预占库存 最终校验」可做到业务上强一致用户看到“下单成功”时库存已锁定。三、高阶组合策略大厂真实方案层级技术作用示例第一道闸门Nginx 限流 前端按钮置灰拦截无效流量限制单 IP 5 次/秒第二道闸门Redis 原子预减快速过滤 95% 请求EVAL ...脚本第三道闸门分布式锁Redisson防止同一用户重复提交RLock lock redisson.getLock(user:123:order)最终落地DB 乐观锁 对账任务保证数据绝对准确每小时比对 Redis 库存 vs DB 库存 关键认知没有银弹只有分层防御。面试时如果说“我只用一种方案”反而暴露经验浅薄。四、必问延伸点提前准备QRedis 宕机怎么办→ 预热时双写 DB Redis宕机时切到 DB 乐观锁降级并启动缓存重建任务。Q超卖了怎么补救→ 立即冻结超卖订单 → 调用支付渠道退款 → 后台人工补偿送优惠券→ 日志告警触发复盘。Q如何防止黄牛刷单→ 设备指纹 行为分析如点击间隔 100ms 直接拦截 手机号实名认证 每人限购。总结一句话秒杀库存的本质是用空间换时间、用冗余换确定性、用分层换稳定性——技术选型永远服务于业务SLA而不是教科书答案。如果你能把这个逻辑讲清楚再配上自己踩过的坑比如“某次没加 stock 0 导致扣成 -127”或者“MQ 消费端没做幂等导致发了 3 张优惠券”面试官一定会眼前一亮。更多Java面试题整理JVM面试题MySQL面试题Redis面试题Spring面试题完整面试题库https://myquotego.com/html/questions?_fromcsdn_123_4