在电商平台的秒杀活动中，订单系统需要处理秒杀请求，请设计一个高并发、低延迟的订单处理流程，并说明如何保证订单-库存-支付的一致性（分布式事务）。
Tencent软件开发-测试开发方向难度：困难
答案
1) 【一句话结论】：秒杀订单处理需通过限流+异步解耦+分阶段提交（如TCC模式）实现高并发低延迟，核心是分阶段检查、确认、回滚，保证订单-库存-支付的一致性，避免全量阻塞。
2) 【原理/概念讲解】：秒杀场景下，订单系统需处理海量请求（如百万级），若直接同步处理会导致库存、订单、支付服务雪崩。分布式事务用于保证跨服务数据一致性，常见方案有2PC（强一致性但阻塞）、TCC（最终一致性，低延迟）、Saga（异步补偿）。以TCC为例，分三个阶段：
- Try（检查资源，预留）：检查库存是否足够，若足够则预留（锁定库存），返回成功；否则失败。
- Confirm（提交资源，完成业务）：创建订单并扣减预留库存，同时调用支付服务处理。
- Cancel（回滚资源，恢复原状）：若业务失败（如支付失败），则释放预留库存。
类比：餐厅点餐——Try是看座位（库存），Confirm是点餐扣座位，Cancel是取消放回座位。每个阶段需保证幂等性（避免重复操作），如通过订单ID或库存ID作为唯一标识。
3) 【对比与适用场景】：
| 方案 | 核心思想 | 适用场景 | 优缺点 |
|---|---|---|---|
| 2PC | 领导者-从者模式，两阶段提交（准备、提交） | 需强一致性，事务短（如数据库事务） | 强一致性，但阻塞，高并发下性能差 |
| TCC | 分阶段提交，每个阶段有Try/Confirm/Cancel | 高并发、低延迟场景（如秒杀、下单） | 低延迟，异步解耦，但需幂等性 |
| Saga | 链式异步操作，失败时补偿 | 长事务（如订单-物流-支付） | 最终一致性，但补偿复杂 |
4) 【示例】：伪代码示例（用户请求秒杀商品ID为1001，数量1）：
用户请求秒杀商品（1001）
1. 限流（令牌桶，每秒1000请求）
2. 调用库存服务：Try(1001, 1)
- 库存服务检查库存，若足够则预留（锁定库存），返回true
- 否则返回false
3. 若Try成功：
- 订单服务：Confirm(1001, 1)
- 创建订单，扣减预留库存
- 调用支付服务：支付(1001, 1)
- 若支付失败：
- 调用库存服务：Cancel(1001, 1)
- 释放预留库存
4. 若Try失败或支付失败：
- 调用库存服务：Cancel(1001, 1)
- 释放预留库存（若已预留）
5) 【面试口播版答案】：
面试官您好，秒杀订单处理的核心是解决高并发下的低延迟和一致性。我设计流程是：首先通过限流（如令牌桶）控制请求量，避免系统雪崩。然后采用TCC模式分阶段处理：Try阶段检查库存并预留资源，Confirm阶段创建订单并扣库存，支付处理；若失败则Cancel阶段回滚。这样即使部分步骤失败，也能保证库存和订单的一致性。具体来说，用户请求秒杀时，系统先调用库存服务Try，库存服务检查库存并锁定（预留），若成功则订单服务调用Confirm创建订单并扣库存，支付服务处理；若库存不足或支付失败，则调用Cancel释放库存。通过异步解耦和补偿机制，实现高并发下的低延迟和最终一致性。
6) 【追问清单】：
- 问题1：库存服务宕机时如何处理？<回答>：采用熔断降级，或预加载库存，或通过消息队列缓冲请求，避免请求直接失败。
- 问题2：如何保证TCC的幂等性？<回答>：通过唯一标识（如订单ID、库存ID）和状态检查，避免重复执行。
- 问题3：最终一致性如何保障？<回答>：通过定时补偿机制，检查失败订单并重新执行Cancel或Confirm。
- 问题4：限流的具体策略？<回答>：令牌桶算法，每秒允许固定数量请求，防止流量过大。
- 问题5：超时处理？<回答>：设置超时时间，若阶段超时则自动回滚，避免阻塞。
7) 【常见坑/雷区】：
- 坑1：直接使用2PC，导致高并发下系统阻塞，性能急剧下降。
- 坑2：忽略幂等性设计，导致重复扣库存或支付，造成资源浪费。
- 坑3：未考虑补偿机制，失败订单无法回滚，库存和订单不一致。
- 坑4：限流策略不合理，部分用户请求被拒绝，影响用户体验。
- 坑5：库存和订单的锁粒度过大，影响并发性能，导致系统吞吐量低。