假设腾讯推出电商业务，需要设计一个秒杀系统，支持百万级用户同时参与秒杀活动。请设计系统的架构，包括请求分发、库存管理、订单生成等环节，并说明如何保证库存一致性和用户体验。
Tencent技术运营难度：中等
答案
1) 【一句话结论】秒杀系统核心是“请求限流+分布式锁控制库存+异步订单生成”，通过Nginx分发请求、Redis实现分布式锁与库存预减，订单异步处理保证用户体验，同时保证库存一致性。
2) 【原理/概念讲解】老师讲解：
秒杀系统需解决高并发下的库存一致性与用户体验问题，核心环节包括请求分发、库存管理、订单生成。
- 请求分发：用Nginx做负载均衡，结合令牌桶/漏桶算法限流，防止流量冲击（类比：超市入口的检票口，控制进店人数，避免拥挤）。
- 库存管理：秒杀时库存变化快，用Redis的
SETNX（分布式锁）+事务（MULTI/EXEC）保证原子性，避免超卖（类比：超市货架上的商品，先抢“货架锁”再拿商品，防止多人同时拿走）。 - 订单生成：秒杀成功后，通过消息队列（如Kafka）异步写入订单表，避免阻塞秒杀请求处理（类比：顾客买完东西后，店员在后台处理订单，不影响顾客继续逛超市）。
3) 【对比与适用场景】
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 分布式锁（悲观锁） | 用Redis SETNX加锁，库存操作在锁内执行 | 严格保证一致性，但可能存在死锁 | 秒杀、抢票等高并发、强一致性场景 | 锁粒度大可能影响并发，需优化锁粒度 |
| 乐观锁（版本号） | 库存表加version字段，更新时检查版本 | 最终一致性，适合读多写少 | 日常购买（非秒杀） | 可能出现超卖，需补偿机制 |
| 最终一致性（消息队列+异步） | 秒杀成功后异步写入订单 | 高吞吐，弱一致性 | 秒杀等高并发场景 | 需保证消息不丢失，订单不重复 |
4) 【示例】
请求流程示例：
用户请求：GET /seckill?skuId=123&userId=1001
- Nginx限流（令牌桶，每秒1000请求）：若通过，转发到后端服务。
- 后端处理：
- 检查分布式锁：
Redis SETNX lock:123 1 (过期时间1秒) - 若锁获取成功，检查库存：
Redis GET stock:123 - 若库存≥1，执行Redis事务：
MULTI, DECR stock:123, EXEC - 事务成功，发送消息到订单队列（Kafka），消息体含
skuId, userId, quantity - 返回响应：秒杀成功，跳转支付页；若库存不足或锁获取失败，返回失败。
- 检查分布式锁：
5) 【面试口播版答案】
面试官您好，秒杀系统核心是解决高并发下的库存一致性和用户体验。首先请求分发用Nginx结合限流（令牌桶），防止流量过大。库存管理用Redis的分布式锁+事务，保证原子性，避免超卖。订单生成异步处理，通过消息队列写入订单表，不阻塞秒杀请求。具体来说，用户请求先被Nginx限流，然后后端尝试获取分布式锁，锁内检查库存，库存够则扣减并异步下单，返回成功；否则返回失败。这样既保证了库存一致性，又提升了系统吞吐量，用户体验更好。
6) 【追问清单】
- 问：如何保证库存一致性？答：用分布式锁（
SETNX）+ Redis事务（MULTI/EXEC），原子性操作，防止超卖。 - 问：高并发下如何处理超卖？答：超卖后通过补偿机制（如定时任务检查订单表，将超卖订单退款或补货）。
- 问：限流策略如何设计？答：令牌桶算法，控制每秒请求量，避免系统崩溃。
- 问：订单生成异步处理如何保证不丢失？答：消息队列持久化，结合事务确认机制（如Kafka的
acks=all）。 - 问：锁的粒度如何选择？答：按SKU或商品分类分锁，避免锁粒度过大影响并发，过小导致锁竞争。
7) 【常见坑/雷区】
- 直接用数据库事务扣库存：性能低，阻塞高并发请求。
- 锁粒度太大：比如锁整个商品，导致并发低。
- 订单生成同步阻塞：秒杀请求处理时间过长，用户体验差。
- 限流策略不合理：比如限流太松导致系统崩溃，太紧影响真实用户购买。
- 忽略超卖处理：秒杀后库存不足但订单已生成，需后续补偿。