04 分布式事务：TCC 与 Saga 模式在订单系统的补偿设计

🧭订单补偿设计中的核心陷阱：TCC 与 Saga 的空回滚问题

在分布式事务的面试中，“空回滚”是区分候选人是否具备实战经验的关键考点。当使用 Seata 实现 TCC（Try-Confirm-Cancel）或 Saga 模式时，若第二阶段（Cancel/补偿）执行时第一阶段（Try/正向）并未成功完成，系统必须能识别并安全跳过，否则会导致数据凭空扣减或状态错乱。本节聚焦于“答辩面试高频问题（Interview High-Frequency Questions）与参考回答（Reference Answers）”中关于空回滚的工程实现，重点说明 Seata 框架下的处理链路与容易出错的步骤

核心判断：空回滚不是 Bug，而是分布式事务框架必须内置的容错机制。面试官常通过“TCC 空回滚（TCC Empty Rollback）”和“Saga 空回滚（Saga Empty Rollback）”来考察候选人对事务边界与幂等设计的理解。下面以订单系统的库存扣减为例，拆解 Seata 的实现路径

⭐Seata TCC 模式下的空回滚与悬挂控制

Seata 的 TCC 模式通过 @TwoPhaseBusinessAction 注解定义 Try、Confirm、Cancel 三个阶段。空回滚的防御逻辑通常写在 Cancel 方法中，通过检查本地事务日志（如一张 tcc_log 表）来判断 Try 阶段是否真正执行过

实现路径：基于事务日志的状态判断

在订单系统的库存服务中，Try 阶段会插入一条状态为 0（已预留）的日志记录；Cancel 阶段执行时，若发现该记录不存在，则直接返回成功（空回滚）。Seata 客户端还提供了 BusinessActionContext 上下文，可从中获取 actionName 和 branchId 来辅助判断

// TCC 接口定义
@TwoPhaseBusinessAction(name = "inventoryTcc", commitMethod = "confirm", rollbackMethod = "cancel")
public boolean tryDecrease(BusinessActionContext context,
                           @BusinessActionContextParameter(paramName = "orderId") String orderId,
                           @BusinessActionContextParameter(paramName = "productId") Long productId,
                           @BusinessActionContextParameter(paramName = "count") Integer count);
// Cancel 方法中的空回滚处理
public boolean cancel(BusinessActionContext context) {
    String orderId = context.getActionContext("orderId").toString();
    // 检查本地事务日志：若 Try 阶段未写入记录，则直接返回 true
    TccLog log = tccLogMapper.selectByOrderId(orderId);
    if (log == null) {
        // 空回滚：记录一条空回滚日志，避免重复处理
        tccLogMapper.insert(new TccLog(orderId, "EMPTY_ROLLBACK"));
        return true;
    }
    // 正常回滚：恢复库存并更新日志状态
    inventoryMapper.revertStock(log.getProductId(), log.getCount());
    tccLogMapper.updateStatus(orderId, "CANCELED");
    return true;
}

阅读这段代码时，重点看分布式事务的伪代码，以及它如何用稳定性与可观测性证明结果可复测。

上述代码的关键在于：tccLogMapper.selectByOrderId(orderId) 返回 null 时，Cancel 方法必须返回 true 而非抛出异常。如果返回 false 或抛出异常，Seata 会不断重试 Cancel，导致空回滚日志重复写入，形成“悬挂事务”

⭐Saga 模式下的逆向补偿与空回滚防御

Saga 模式通过编排正向服务与逆向补偿服务来实现长事务。在 Seata 的 Saga 实现中，状态机引擎会记录每个节点的执行状态。当正向服务因超时未响应时，引擎会直接调用该节点的补偿服务——此时若正向服务实际并未执行，补偿服务就面临空回滚问题

基于状态机上下文的空回滚检查

Seata Saga 的状态机上下文（StateMachineContext）中包含了每个节点的 status 字段。补偿服务可以通过读取该字段来判断正向节点是否真正完成。以下是一个基于 JSON 配置的 Saga 状态机片段：

{
  "name": "orderSaga",
  "states": [
    {
      "name": "deductInventory",
      "type": "ServiceTask",
      "serviceName": "inventoryService",
      "serviceMethod": "deduct",
      "compensateState": "compensateDeduct"
    },
    {
      "name": "compensateDeduct",
      "type": "ServiceTask",
      "serviceName": "inventoryService",
      "serviceMethod": "compensateDeduct",
      "input": [
        {"from": "context", "expression": "#root.deductInventory.status"}
      ]
    }
  ]
}

阅读这段代码时，重点看分布式事务的伪代码，以及它如何用稳定性与可观测性证明结果可复测。

在补偿方法 compensateDeduct 中，通过 deductInventory.status 判断：若状态为 SU（成功），则执行真正的库存回滚；若状态为 FA（失败）或 UN（未知），则直接返回成功，实现空回滚。Seata 的 Saga 引擎在调用补偿服务前，会自动将上下文中的状态注入到服务方法的参数中

⭐异常信号与处理边界：如何验证空回滚逻辑的正确性

面试中，面试官常会追问：“你怎么验证你的空回滚逻辑是安全的？” 以下是一份判断标准表，用于自检或评审代码

在“答辩面试高频问题与参考回答（Interview High-Frequency Questions and Reference Answers）”中，关于“review_summary 空回滚（Review Summary Empty Rollback）”和“考回答空回滚（Exam Answer Empty Rollback）”的讨论，本质上都是考察候选人是否理解：空回滚不是异常，而是分布式事务框架必须支持的正常流程。面试时，建议从“幂等性”“悬挂控制”“事务日志设计”三个层面展开回答，并结合 Seata 的具体 API 说明实现细节