快手电商业务在双11大促期间，秒杀活动会导致订单系统瞬间高并发，请设计一个秒杀系统的架构，解决高并发、分布式事务和库存一致性等问题。

快手工程类难度：困难

答案

1) 【一句话结论】
秒杀系统需通过“前端限流+分布式锁控制并发+异步解耦订单与库存+最终一致性保障”的架构设计，结合微服务拆分与消息队列，解决高并发、分布式事务与库存一致性难题。

2) 【原理/概念讲解】
老师会解释高并发秒杀的核心挑战——请求量瞬间激增（如百万级/秒），需快速响应但避免资源耗尽。首先讲限流：用漏桶/令牌桶算法限制请求速率，防止系统过载，比如漏桶像“水桶装水，每秒只能加一定量，超过就溢出”，令牌桶则是“每秒生成固定令牌，请求消耗令牌，无令牌则拒绝。分布式锁：秒杀时需保证同一商品同一时间仅一人能抢到，用Redis的SETNX（SET if Not Exists）实现，但需考虑高并发下的“抢锁”问题，比如加锁失败后重试，避免死锁。异步解耦：订单创建与库存扣减是强依赖，但高并发下同步处理会导致库存扣减阻塞订单创建，因此采用“先扣库存（异步）再创建订单”或“先创建订单（异步）再扣库存”的异步流程，用消息队列（如Kafka）传递库存扣减指令，保证两者不阻塞。最终一致性：由于异步处理，库存扣减和订单创建可能有延迟，需通过定时任务或消息确认机制（如库存扣减成功后发送确认消息，订单创建失败后重试）保证一致性，比如“库存扣减成功后，发送‘库存扣减成功’消息到订单服务，订单服务收到后创建订单，若超时未收到则重试”。

3) 【对比与适用场景】

方案	定义	特性	使用场景	注意点
最终一致性	通过异步消息传递和补偿机制，允许短暂不一致，最终通过重试或定时任务恢复一致性	适合高并发场景，降低系统耦合	秒杀、抢购等业务	需要设计补偿逻辑，避免数据不一致累积
TCC	三阶段（Try-Confirm-Cancel）事务，每个服务提供三个接口	强一致性，但实现复杂，需保证每个阶段原子性	需要强一致性且业务复杂	开发成本高，维护困难
Saga	长事务，通过多个短事务（每个事务包含Try/Confirm/Compensate）组成，失败时补偿	适合长事务，但补偿逻辑复杂	需要长事务且业务逻辑复杂	补偿逻辑易出错

4) 【示例】
用伪代码描述秒杀流程：

前端请求秒杀接口（/seckill/{skuId}）：
```
{
  "skuId": "12345",
  "userId": "user_001"
}
```
前端限流：限流服务检查请求速率，若超过阈值则返回“限流中”。
分布式锁：调用Redis的SETNX lock:skuId, userId, 10s（10秒锁超时），若返回1则获取锁，否则重试。
库存扣减（异步）：若库存足够，则发送消息到库存服务（如Kafka主题“stock-reduce”）：
```
{
  "skuId": "12345",
  "userId": "user_001",
  "quantity": 1
}
```
库存服务消费消息后，扣减库存（如更新数据库库存数量）。
订单服务消费库存扣减成功的消息后，创建订单（如发送消息到订单服务主题“order-create”）：
```
{
  "userId": "user_001",
  "skuId": "12345",
  "quantity": 1,
  "price": 99.9
}
```
订单服务创建订单后，返回秒杀成功结果给前端。

5) 【面试口播版答案】
“面试官您好，针对快手电商双11秒杀的高并发场景，我的设计核心是通过前端限流+分布式锁控制并发+异步解耦订单与库存+最终一致性保障的架构，具体来说：首先，前端接入层用令牌桶限流，防止请求瞬间暴增；然后，秒杀请求先通过Redis分布式锁（SETNX）保证同一商品同一时间仅一人抢到，锁超时自动释放；接着，库存扣减采用异步方式，通过消息队列（Kafka）传递指令，避免阻塞订单创建；最后，通过消息确认机制（库存扣减成功后发送确认，订单创建失败后重试）保证最终一致性。这样既能应对高并发，又能解决分布式事务和库存一致性问题。”

6) 【追问清单】

问题1：分布式锁如何处理高并发下的“抢锁”问题？
回答要点：用Redis的SETNX结合重试机制，比如锁失败后等待1ms再重试，避免死锁。
问题2：库存扣减和订单创建的顺序如何保证？
回答要点：采用“先扣库存（异步）再创建订单”的流程，通过消息队列解耦，保证两者不阻塞。
问题3：如何保证最终一致性？
回答要点：通过消息确认和定时任务，比如库存扣减成功后发送确认消息，订单服务收到后创建订单，若超时未收到则重试。
问题4：系统监控如何设计？
回答要点：监控限流阈值、分布式锁获取成功率、消息队列延迟、库存扣减成功率等指标，及时发现瓶颈。

7) 【常见坑/雷区】

坑1：直接用数据库事务处理高并发，导致性能瓶颈。
坑2：分布式锁选错（如用简单setnx，高并发下死锁）。
坑3：库存扣减顺序错误（先扣订单再扣库存）。
坑4：忽略限流和熔断。
坑5：未考虑最终一致性的补偿逻辑。