在贸易系统中，订单创建和库存扣减需要分布式事务，如何用最终一致性方案（如TCC、Saga模式）解决？请举例说明TCC的Try/Confirm/Cancel三个阶段在库存扣减中的应用。

南光(集团)有限公司信息技术类难度：中等

答案

1) 【一句话结论】在订单创建与库存扣减的分布式场景中，采用TCC模式通过Try（预检查）、Confirm（确认扣减）、Cancel（回滚库存）三个阶段实现最终一致性，确保订单创建成功时库存被正确扣减，失败时库存恢复。

2) 【原理/概念讲解】老师讲解TCC和Saga：TCC（Try-Confirm-Cancel）是分布式事务的最终一致性方案，核心是通过业务方法封装三个阶段，由协调者控制执行顺序。Try阶段负责资源预检查（如库存是否足够），若检查失败则直接返回失败；若成功则标记资源锁定（如库存锁定），然后协调者调用Confirm阶段执行实际操作（如扣减库存），若Confirm失败则调用Cancel阶段回滚（如恢复库存）。Saga模式则是通过一系列本地事务和补偿事务组成事务链，每个本地事务完成后发布事件，后续事务根据事件执行补偿操作。类比：TCC像“先试后买”，先检查库存（Try）是否够，够的话锁定库存（标记），然后确认购买（Confirm）扣减，不够的话取消（Cancel）恢复；Saga像“先买后补”，先扣减库存（本地事务），然后发布“订单创建成功”事件，后续事务根据该事件补偿（如如果订单失败则补库存）。

3) 【对比与适用场景】

特性/模式	TCC	Saga
定义	通过业务方法封装Try/Confirm/Cancel三个阶段，协调者控制顺序	由本地事务和补偿事务组成的事务链，通过事件驱动补偿
特性	需要协调者控制流程，Try阶段不实际操作，依赖补偿	无协调者，依赖事件和补偿链，最终一致性
使用场景	需要强一致性保障的业务（如金融转账、库存扣减），业务逻辑简单	业务逻辑复杂，多个服务参与，难以用两阶段提交
注意点	Try阶段必须幂等，Confirm/Cancel需保证幂等性	补偿链设计复杂，需考虑幂等性和超时

4) 【示例】假设订单创建时需要扣减库存，TCC实现如下：

Try阶段（库存服务）：
```
{
  "method": "try",
  "params": {
    "orderId": "123",
    "quantity": 2
  }
}
```
库存服务返回：{"status": "ok", "version": 1}（表示库存足够，锁定版本1）。

Confirm阶段（库存服务）：

{
  "method": "confirm",
  "params": {
    "orderId": "123",
    "quantity": 2,
    "version": 1
  }
}

执行扣减库存操作，返回成功。

Cancel阶段（库存服务）：
```
{
  "method": "cancel",
  "params": {
    "orderId": "123",
    "quantity": 2,
    "version": 1
  }
}
```
回滚库存，恢复数量。
订单服务调用库存服务时，协调者控制流程：先调用Try，若成功则调用Confirm，若Confirm失败则调用Cancel。

5) 【面试口播版答案】面试官您好，关于贸易系统中订单创建和库存扣减的分布式事务，我建议采用TCC模式实现最终一致性。核心是通过Try（预检查）、Confirm（确认扣减）、Cancel（回滚库存）三个阶段控制流程。比如库存扣减时，Try阶段检查库存是否足够（比如当前库存100，订单需扣减2，检查通过则锁定库存版本），然后协调者调用Confirm阶段实际扣减库存，若Confirm失败（比如网络问题），则调用Cancel阶段恢复库存。这样即使分布式系统出现故障，也能保证最终库存一致性。具体来说，Try阶段不实际扣减，只是检查和锁定资源；Confirm确认操作；Cancel回滚。这种模式适用于需要强一致性保障的业务场景，比如库存扣减、订单创建等。

6) 【追问清单】

TCC模式中Try阶段如何保证幂等性？回答要点：Try阶段返回资源版本，后续调用时检查版本是否匹配，避免重复检查。
Saga模式与TCC相比，补偿链的设计难点是什么？回答要点：补偿链的顺序和依赖关系，以及如何处理超时和失败补偿。
分布式事务中，如何处理超时和失败的情况？回答要点：设置超时时间，协调者重试机制，以及幂等性保证。
如果订单创建和库存扣减涉及多个服务（如订单服务、库存服务、支付服务），TCC如何扩展？回答要点：每个服务封装自己的Try/Confirm/Cancel，协调者按顺序调用，确保全局一致性。
TCC模式对系统性能的影响？回答要点：Try阶段轻量，Confirm/Cancel可能增加延迟，但整体比Saga的补偿链更高效。

7) 【常见坑/雷区】

TCC的Try阶段不实际执行操作，容易忽略幂等性检查，导致重复检查或错误。
Confirm/Cancel阶段需保证幂等性，否则可能导致重复扣减或回滚，造成库存异常。
Saga模式的补偿链设计复杂，若补偿逻辑错误，可能导致死循环或数据不一致。
分布式事务中，超时处理不当会导致协调者无限重试，影响系统稳定性。
忽略业务场景的适用性，比如简单业务用Saga更合适，而复杂强一致性业务用TCC。