秒杀场景的核心挑战是短时间海量用户争抢极少量库存，需在扛住数百倍流量洪峰的同时确保库存不超卖、订单不重复、体验不卡顿。
秒杀场景的核心挑战是什么
秒杀不是简单的高并发请求处理，而是短时间海量用户争抢极少量库存的极端场景。典型表现为：瞬间流量是日常的数百倍，数据库写压力集中爆发，缓存击穿频繁，超卖、重复下单、接口被刷等问题极易出现。关键不在于“快”，而在于“稳”和“准”——既要扛住流量洪峰，又要保证库存不超卖、订单不重复、用户体验不卡顿。
常见架构瓶颈及对应解决思路
1. 流量直接打到数据库，连接池打满、SQL执行慢
秒杀请求若未做分层过滤，大量请求穿透到DB，MySQL在高并发update库存时会出现行锁竞争、主从延迟、连接耗尽等问题。
- 前置多级限流：接入层（Nginx）按IP/Token限流，网关层（Spring Cloud Gateway）做QPS+用户维度限流
- 库存预扣逻辑下沉到Redis：用Lua脚本原子性执行“判断库存→扣减→写入秒杀凭证”，避免网络往返和竞态
- DB只承担最终落库职责：秒杀成功后异步写入订单表，用消息队列（如RocketMQ）削峰填谷
2. 缓存雪崩/击穿导致DB被压垮
热门商品秒杀链接被爬虫或脚本高频访问，若缓存失效后大量请求直击DB，极易引发雪崩。
- 热点Key永不过期 + 主动更新机制：后台定时刷新库存缓存，避免自然过期
- 互斥锁（Mutex Lock）兜底：Redis中setnx抢锁，未拿到锁的请求短暂休眠后重试，而非全部打DB
- 空值缓存防穿透：对查询不到的商品ID也缓存null（带短过期），防止恶意ID攻击
3. 下单接口被刷、用户重复提交、超卖
前端没做防重、没验资格、没控频次，导致一个用户多次中奖或机器人批量占坑。
- 请求合法性四重校验：① 用户登录态（JWT鉴权）→ ② 秒杀资格（是否在白名单/完成实名）→ ③ 请求幂等性（前端生成唯一requestId，服务端Redis记录已处理）→ ④ 库存原子扣减（Lua or Redisson分布式锁）
- 下单接口与库存扣减分离：先发“秒杀成功”信号（含加密token），再由独立服务凭token生成订单，防止页面重复提交触发多次下单
Java代码层面的关键实践
不依赖框架黑盒，核心逻辑要可控。例如Redis库存扣减推荐用以下方式：
// Lua脚本保证原子性（推荐）String script = "if redis.call('exists', KEYS[1]) == 0 then return -1 end;" +
"local stock = tonumber(redis.call('get', KEYS[1]));" +
"if stock
"redis.call('decr', KEYS[1]); return 1;";
Object result = redisTemplate.execute(new DefaultRedisScript(script, Long.class),
Collections.singletonList("seckill:stock:" + itemId));
Java服务中避免使用synchronized或数据库悲观锁应对秒杀，优先选择Redis原子操作 + 异步化 + 最终一致性。库存扣减成功后，立即返回轻量响应（如“排队中”），后续通过WebSocket或轮询通知结果，降低接口RT。
补充建议：压测与降级必须前置
上线前务必用JMeter或阿里JVM Profiler模拟真实秒杀流量，重点观测Redis CPU、MQ堆积、DB慢SQL、线程池拒绝率。同时配置全链路降级开关：
立即学习“Java免费学习笔记（深入）”；
- 秒杀入口可一键关闭（返回活动暂未开始）
- 库存服务不可用时自动切换至本地内存兜底（有损但保可用）
- 订单写入失败时，先记日志+发告警，允许人工补单，不阻塞主流程
基本上就这些。秒杀没有银弹，本质是用空间换时间、用异步换同步、用取舍换稳定。
