设计一个支持百万级用户请求的秒杀系统，需要考虑哪些核心组件和技术？请详细说明系统架构、数据一致性处理以及高并发下的性能优化措施。
答案
1) 【一句话结论】
秒杀系统核心是高并发资源抢占与数据一致性保障，需通过限流层、分布式锁、缓存+数据库双写、消息队列等组件，结合分层架构与异步解耦，实现百万级请求的秒杀体验。
2) 【原理/概念讲解】
老师口吻解释核心概念：
“秒杀系统设计需围绕‘高并发资源抢占’与‘数据一致性’展开。系统架构通常分层：接入层（Nginx+限流）防流量冲击；业务逻辑层（处理请求、校验、调用锁）是核心；存储层（缓存+数据库）保障数据持久性；监控层（指标监控）辅助优化。数据一致性方面，秒杀场景对实时性要求高，采用最终一致性（允许短暂不一致），通过分布式锁（如Redis SETNX）保证同一商品同一时间仅一人抢购，避免超卖。高并发优化上，缓存预热（提前加载热门商品库存到Redis）、数据库分库分表（按商品ID分库，减少单库压力）、读写分离（缓存读，数据库写）、消息队列（异步处理订单，解耦业务）是关键。”
3) 【对比与适用场景】
| 对比项 | 限流算法（滑动窗口 vs 令牌桶） | 分布式锁（Redis SETNX vs Zookeeper） |
|---|---|---|
| 滑动窗口 | 定义：动态调整窗口大小，计数防超限；特性：更精准，适合高频请求；使用场景：秒杀等高频场景；注意点：实现复杂，需防超限瞬间流量。 | 定义：Redis SETNX原子操作，分布式锁；特性：简单易用，适合秒杀场景；使用场景：单机/分布式资源抢占；注意点：不可重入，超时需处理。 |
| 令牌桶 | 定义：持续生成令牌，请求消耗；特性：流量平滑，防峰值；使用场景：需要流量平滑的场景；注意点：令牌生成速率固定。 | 定义：Zookeeper事务性，可重入；特性：强事务性，适合强一致性需求；使用场景：需要强事务的场景；注意点：依赖ZK集群，部署复杂。 |
4) 【示例】
秒杀请求流程（伪代码）：
用户请求秒杀商品ID=1001：
- 接入层Nginx（滑动窗口限流，每秒1000请求）；
- 业务层：
a. 从Redis缓存获取商品库存（若缓存无，从数据库查并缓存）；
b. 调用Redis分布式锁（key=lock:1001，value=当前时间戳）；
c. 若锁获取成功：
i. 检查库存是否足够（缓存/数据库）；
ii. 若足够，扣减库存（缓存SET stock:1001 旧值-1，数据库UPDATE SET stock=...）；
iii. 提交订单（数据库事务）；
iv. 释放锁（Redis DEL lock:1001）；
d. 若锁获取失败或库存不足，返回失败。
5) 【面试口播版答案】
“面试官您好，秒杀系统设计核心是应对百万级并发下的资源抢占与数据一致性，我总结几个关键点：首先系统架构分层，接入层用Nginx+滑动窗口限流防流量冲击；业务层用Redis分布式锁保证同一商品同一时间仅一人抢购，避免超卖；存储层采用缓存+数据库双写，缓存预热热门商品库存，数据库按商品ID分库分表分散压力；高并发下还用消息队列异步处理订单，解耦业务。数据一致性方面，秒杀场景允许最终一致性，通过分布式锁保证抢购时的互斥，同时缓存与数据库双写保证一致性。性能优化上，除了限流、缓存，还有数据库读写分离、分库分表、消息队列异步处理等。这样整体能支撑百万级请求的秒杀。”
6) 【追问清单】
- 问题：分布式锁选型（Redis vs Zookeeper vs etcd）？
回答要点：Redis SETNX简单易用，适合秒杀场景；Zookeeper事务性强，适合强一致性需求；etcd高可用，适合微服务。 - 问题：缓存雪崩怎么办？
回答要点：设置缓存过期时间（如5分钟）+互斥锁，或者预加载缓存（预热）。 - 问题：分库分表的策略是什么？
回答要点：按商品ID哈希分库，每个库按时间分表，减少单库压力。 - 问题：监控指标有哪些？
回答要点：请求成功率、限流次数、锁获取成功率、缓存命中率、数据库QPS、消息队列积压。 - 问题：容错处理怎么做？
回答要点：分布式锁超时重试、库存扣减失败回滚、订单失败重试。
7) 【常见坑/雷区】
- 直接用数据库锁导致秒杀性能极低（数据库单机QPS有限）；
- 限流策略选择不当（如固定窗口在秒杀开始瞬间流量大时易超限）；
- 数据一致性过度追求强一致性（如用数据库事务保证库存和订单同时更新，导致性能下降）；
- 缓存穿透问题（空库存时缓存未命中，导致数据库压力剧增）；
- 消息队列积压（订单处理慢，导致队列积压，影响用户体验）。