设计一个支持百万级用户并发访问的秒杀系统，请从架构设计、技术选型、性能优化、容错机制等方面阐述。
新凯来软件开发工程师难度：困难
答案
1) 【一句话结论】
秒杀系统需通过“前端限流+中间件防刷+后端分布式锁+数据库优化+消息队列解耦”的分层架构，结合缓存预热、锁优化等手段，确保百万级并发下的性能与稳定性。
2) 【原理/概念讲解】
老师：“同学们，秒杀系统核心是解决‘高并发+低资源’的矛盾。首先得理解几个关键概念：
- 限流：控制请求速率，比如Nginx的IP限流（限制同一IP每秒请求次数），防止恶意请求淹没系统；
- 防刷：防止恶意用户刷单，比如通过IP+用户+设备+时间窗口的规则（如Redis记录用户最近1秒请求次数），避免刷单行为；
- 分布式锁：保证同一商品同一时间只能被一个用户抢购，比如Redis的
SETNX命令（原子性设置键值，若键不存在则设置成功），像抢购时只有拿到“唯一钥匙”的人能开柜子，防止超卖； - 数据库优化：读写分离（主库写、从库读）、分库分表（按商品ID分库，按时间分表）、索引优化（库存表用
id主键+id索引），提升读写性能； - 消息队列：解耦服务间依赖，比如库存扣减后通过Kafka通知其他服务，避免阻塞，支持异步处理。
（类比：分布式锁就像多人抢购时，只有一人能拿到“唯一钥匙”打开商品柜，其他人只能等待，防止超卖。）”
3) 【对比与适用场景】
| 策略 | 定义 | 特性 | 适用场景 | 注意点 |
|---|---|---|---|---|
| 固定窗口 | 固定时间窗口（如1秒）计数 | 简单易实现 | 低并发场景 | 易超卖（窗口末尾大量请求） |
| 滑动窗口 | 动态调整窗口大小，实时统计 | 更精准 | 中高并发 | 实现复杂，需精确计算 |
| 令牌桶 | 持续生成令牌（速率R），按需消费 | 流量平滑 | 高并发 | 需要精确控制令牌生成速率 |
| 漏桶 | 持续流入水桶，按固定速率流出 | 限制最大速率 | 需要严格限制速率 | 易堆积 |
（注：限流策略中，令牌桶和滑动窗口更适合高并发场景，能更精准控制请求速率。）
4) 【示例】
秒杀请求流程（伪代码）：
- 用户请求秒杀接口（如
/kill/123）； - 前端Nginx限流：检查IP/用户，若超过阈值（如每秒100次），返回“请求过多”；
- 中间件防刷：Redis记录用户请求时间（
hset user:ip:123 last_time 1670000000），若当前时间-last_time<1秒，返回“防刷”； - 后端服务（Spring Boot）获取商品id=123，尝试获取Redis分布式锁（
key=lock:123，value=当前时间戳）；- 若获取锁成功：
- 查询Redis缓存库存（
key=stock:123），若库存>0：- 扣减库存（
Redis decr stock:123），若库存<=0，返回“库存不足”； - 更新数据库库存（事务：
select stock from goods where id=123 for update; stock=stock-1; update goods set stock=? where id=?）； - 返回“抢购成功”；
- 扣减库存（
- 否则返回“库存不足”；
- 查询Redis缓存库存（
- 若获取锁失败：返回“抢购失败（锁被占用）”；
- 若获取锁成功：
- 若未获取锁：返回“抢购失败（锁被占用）”。
5) 【面试口播版答案】
各位面试官好，针对百万级用户并发访问的秒杀系统设计，我的核心思路是分层解耦+技术选型+性能优化+容错保障。首先，架构上分为前端限流、中间件防刷、后端分布式锁+数据库优化、消息队列解耦四层。前端用Nginx+Redis实现IP/用户限流，防止恶意请求；中间件用IP+用户+设备+时间窗口防刷，避免刷单；后端用Redis分布式锁保证同一商品同一时间只被一个用户抢购，数据库做读写分离+分库分表+索引优化，提升读写性能；消息队列（如Kafka）解耦库存扣减与通知服务，避免阻塞。性能优化上，缓存预热（秒杀前将热门商品库存预热到Redis），数据库加id索引，锁优化（设置锁超时避免死锁）。容错方面，熔断（如Hystrix）防止服务雪崩，降级（如库存不足时返回“库存不足”）保证可用性。这样整体能支撑百万级并发，同时保证系统稳定。
6) 【追问清单】
- 问题：如何处理缓存穿透/雪崩问题？
回答要点：缓存穿透用布隆过滤器+互斥锁防穿透，缓存雪崩用随机过期时间+热点数据预热。 - 问题：分布式锁的锁超时问题如何解决？
回答要点：设置合理的锁超时时间（如10秒），超时后自动释放锁，避免死锁。 - 问题：数据库分库分表后，秒杀库存如何同步？
回答要点：通过消息队列（如Kafka）异步同步库存，或使用分布式事务（如Seata）保证一致性。 - 问题：前端限流和后端限流的区别？
回答要点：前端限流在客户端/Nginx层，快速过滤无效请求；后端限流在服务层，处理请求后返回结果，适合控制服务压力。 - 问题：消息队列在秒杀场景的作用是什么？
回答要点：解耦库存扣减与通知服务，避免阻塞，支持异步处理，提升系统吞吐量。
7) 【常见坑/雷区】
- 忽略限流导致超卖：未在前端/中间件做限流，恶意用户刷单引发库存超卖；
- 分布式锁未设置超时：锁超时未释放，导致其他用户无法获取锁，系统卡死；
- 数据库未做读写分离：高并发下数据库读写压力过大，性能瓶颈；
- 缓存未预热：秒杀开始时，缓存未预热，大量请求直接访问数据库，引发雪崩；
- 消息队列未考虑顺序性：若秒杀结果需按顺序通知，未保证消息顺序，导致结果混乱。