在电商或游戏大促场景中，秒杀系统需要支持百万级请求并发，并保证交易一致性（订单-库存-支付），请设计该系统的架构，并说明关键技术点。
Tencent软件开发-后台开发方向难度：困难
答案
1) 【一句话结论】秒杀系统需通过“限流防雪崩+分布式锁防超卖+消息队列解耦+幂等+最终一致性”架构，结合分库分表提升性能，核心是“限流+锁+异步+幂等”的协同设计，最终保证订单-库存-支付最终一致性。
2) 【原理/概念讲解】
秒杀场景的核心矛盾是百万并发下的库存一致性，需采用最终一致性（而非强一致性，因强一致性在高并发下成本极高，允许少量超卖但最终通过补偿机制恢复一致性，如超卖商品后续退款或补货）。关键技术点如下：
- 分布式锁：选择Redis分布式锁（
SETNX原子操作），锁整个商品库存（锁粒度选择依据：提升并发度，避免锁太细导致资源浪费，同时设置超时时间（如10秒）防死锁，超卖后通过补偿机制处理）。 - 消息队列解耦：将“库存扣减”与“订单生成”拆分为异步步骤（如Kafka），库存服务先扣减库存，订单服务消费消息后生成订单，避免高并发压力集中在单点。
- 限流策略：用令牌桶（每秒1万令牌）限制请求速率，防止系统雪崩，平滑流量波动。
- 幂等处理：通过唯一标识（订单号、请求参数）保证重试不重复，避免超卖或重复下单。
3) 【对比与适用场景】
| 方式 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Redis分布式锁 | 利用SETNX原子性，加超时时间 | 原子性，支持超时自动释放，分布式 | 秒杀库存锁定、订单生成 | 需Redis集群，锁粒度需合理（锁整个商品库存），超时时间需设置合理 |
| Zookeeper | 利用临时节点监听变化 | 顺序性，支持复杂协调 | 需高可用Zookeeper，复杂锁管理 | 配置复杂，节点故障锁失效 |
| 数据库锁 | 直接用数据库行锁 | 依赖数据库，简单 | 库存表小、并发低 | 性能差，会导致系统阻塞 |
4) 【示例】
用户请求示例（JSON）：
{
"user_id": 123,
"goods_id": 1001,
"quantity": 1
}
服务端流程：
- 限流检查：通过令牌桶，若超限则返回“请求过多”。
- 分布式锁：调用Redis
SETNX "lock:goods:1001" "user:123" ex 10 nx，成功则获取锁。 - 扣库存：库存服务（按商品ID模100分库，如
goods_id % 100到db1）执行UPDATE stock SET count = count - 1 WHERE goods_id = 1001 AND count >= 1，返回成功。 - 发送消息：将请求推入Kafka（topic:order），包含用户ID、商品ID等。
- 订单服务（按用户ID分表，如
user_id % 100到order_db1）消费消息，生成订单（INSERT orders (user_id, goods_id, quantity, status) VALUES (123, 1001, 1, 'pending')），并调用支付服务（异步）。
5) 【面试口播版答案】
面试官您好，秒杀系统要解决百万并发下的库存一致性问题，核心架构是“限流防雪崩+分布式锁防超卖+消息队列解耦+幂等+最终一致性”。首先，用令牌桶限流（每秒1万令牌），超过则返回错误；然后，库存扣减时用Redis分布式锁（SETNX加超时10秒），成功后扣库存；接着，订单生成与库存扣减异步处理（Kafka），解耦高并发压力；最后，所有操作做幂等处理（如订单号唯一），避免重复下单。同时，按商品ID模100分库，订单表按用户ID分表，提升读写性能。这样既能保证订单-库存-支付最终一致性，又能应对百万并发。
6) 【追问清单】
- 问题1：分布式锁的线程安全问题？
回答：RedisSETNX是原子操作，但需注意锁超时时间（如10秒）防死锁，同时锁粒度选择（锁整个商品库存），避免资源浪费。 - 问题2：库存扣减的幂等性如何保证？
回答：用库存ID+请求ID做唯一键（如goods_id+request_id），扣库存时检查当前库存是否足够，若足够则扣减，否则返回失败，重试不会重复扣减。 - 问题3：分库分表如何设计？
回答：商品表按商品ID模100分库（如goods_id % 100），订单表按用户ID模100分表（如user_id % 100），提升读写性能。
7) 【常见坑/雷区】
- 坑1：直接用数据库锁处理秒杀，导致性能瓶颈（行级锁高并发下阻塞严重）。
- 坑2：限流策略设置不当（如固定窗口限流，窗口末尾流量集中导致系统崩溃）。
- 坑3：消息队列积压，库存扣减失败导致Kafka消息堆积，订单服务无法消费。
- 坑4：一致性模型选择错误（如强一致性，高并发下成本高，秒杀场景更适合最终一致性）。
- 坑5：分库分表设计不合理（如分片键选择不当导致热点，如按时间分表，导致单表压力过大）。