分布式事务深度：TCC空回滚、悬挂与Saga补偿风暴的根因与解法

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

分布式事务有一个诡异的定律：测试环境跑一百遍都没事，上线第一分钟就翻车。

TCC的代码在测试环境跑了几百遍，Try、Confirm、Cancel三个接口都写得漂漂亮亮。上线之后，账对不上了。查了半天日志才发现------Cancel执行了，但Try根本没执行过。

这就是空回滚。今天把TCC和Saga的三个核心陷阱彻底拆开讲清楚。

先搞懂几个词：

TCC（Try-Confirm-Cancel） ：分布式事务的一种实现模式。Try做资源预留，Confirm确认提交，Cancel取消回滚。相比2PC的同步阻塞，TCC不长时间持有锁，性能更好。

空回滚：Cancel执行了，但Try根本没执行过。

悬挂：Try在Cancel之后才到达，资源被冻结但没有对应的Confirm或Cancel来处理。

事务记录表：TCC解决空回滚和悬挂的核心工具。Try执行前先插入一条记录，Cancel执行前先查这条记录是否存在。

补偿风暴：Saga模式下，补偿操作级联触发，导致系统被补偿请求淹没。

一、TCC空回滚：Cancel执行了，但Try从没来过

时序成因

空回滚的触发链路是这样的：

调用方发起Try请求
Try请求在网络中拥塞，超时了
调用方认为Try失败，触发Cancel
Cancel执行，但Try根本没有执行过
Try请求最终到达了------但Cancel已经执行完了

为什么会出问题？

Cancel的逻辑是"释放Try阶段预留的资源"。但如果Try根本没有执行，就没有资源被预留。Cancel执行时，会尝试"解冻"一笔不存在的冻结金额------如果代码写得不严谨，可能直接把账户余额给改了，造成数据不一致。

解决方案：事务记录表

核心思路是：Try执行前先记录，Cancel执行前先检查。

bash 复制代码

CREATE TABLE tcc_transaction (
    tx_id VARCHAR(64) PRIMARY KEY COMMENT '事务ID',
    status VARCHAR(16) NOT NULL COMMENT 'INIT/TRIED/CONFIRMED/CANCELLED',
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

bash 复制代码

// Try：先标记，再冻结
public void try(String txId) {
    insert(txId, "INIT");
    freezeAmount(100);
    updateStatus(txId, "TRIED");
}

// Cancel：先检查Try是否执行过
public void cancel(String txId) {
    String status = queryStatus(txId);
    if (status == null) {
        // 空回滚：Try从未执行过，记录并返回成功
        insert(txId, "CANCELLED");
        return;
    }
    if ("CANCELLED".equals(status)) {
        // 幂等：已经回滚过了
        return;
    }
    unfreezeAmount(100);
    updateStatus(txId, "CANCELLED");
}

关键点：Cancel识别到空回滚后，不能直接返回成功------必须先记录一条CANCELLED记录。否则悬挂问题会紧随其后。

二、TCC悬挂：Cancel已经执行完了，Try才姗姗来迟

时序成因

悬挂的触发链路：

Try请求在网络中拥塞，超时了
调用方触发Cancel，Cancel执行成功
Try请求最终到达，开始执行业务操作
资源被冻结了，但事务管理器认为这个事务已经结束，不会再发Confirm或Cancel
冻结的资源永远无法释放

空回滚和悬挂是一对孪生问题。 空回滚是"Cancel先到了"，悬挂是"Try后到了"。两者都源于网络延迟导致的乱序。

解决方案

在Cancel空回滚返回成功之前，先记录该事务已回滚。Try接口在执行前检查这条记录：

bash 复制代码

// Try：检查是否已经被Cancel过
public void try(String txId) {
    String status = queryStatus(txId);
    if ("CANCELLED".equals(status)) {
        // 悬挂：Cancel已经执行过了，拒绝执行Try
        throw new RuntimeException("事务已被取消，拒绝执行Try");
    }
    insert(txId, "INIT");
    freezeAmount(100);
    updateStatus(txId, "TRIED");
}

空回滚和悬挂的完整防御需要三个检查：

场景	检查时机	检查内容	处理方式
空回滚	Cancel执行前	Try是否执行过	未执行过 → 记录CANCELLED，返回成功
悬挂	Try执行前	是否已被Cancel	已被Cancel → 拒绝执行Try
幂等	Confirm/Cancel执行前	是否已执行过	已执行过 → 直接返回成功

三、幂等：Confirm和Cancel可能被重复调用

TCC的三个接口（Try/Confirm/Cancel）都可能被重复调用。原因有两个：网络重试机制、事务管理器故障恢复后的重试。

解决方案：Confirm和Cancel执行前先查询事务状态。如果状态已经是CONFIRMED或CANCELLED，直接返回成功。

bash 复制代码

public void confirm(String txId) {
    String status = queryStatus(txId);
    if ("CONFIRMED".equals(status)) {
        return; // 幂等
    }
    commitAmount(100);
    updateStatus(txId, "CONFIRMED");
}

四、Saga补偿风暴：补偿链越长，风险越大

Saga模式和TCC不同。TCC是"预留+确认"，Saga是"直接执行+反向补偿"。每个本地事务执行后立即提交，失败时按反向顺序执行补偿操作。

补偿风暴的触发链路

Saga流程是：LT1 → LT2 → LT3 → ... → LTn。如果LTn失败，需要按反向顺序执行：CTn → CTn-1 → ... → CT2 → CT1。

补偿风暴发生在补偿操作本身也失败时。如果CTn-1补偿失败，事务管理器会重试。如果重试多次仍然失败，可能需要人工介入。更严重的是，如果补偿操作触发了新的Saga流程（比如补偿操作本身是一个跨服务调用），补偿链会级联扩散。

一个真实的场景：电商订单流程涉及下单、扣库存、扣积分、发优惠券、通知物流。如果第5步失败，需要依次补偿前4步。但如果"退优惠券"这个补偿操作本身也失败了（比如优惠券服务不可用），补偿链就卡住了。此时如果第5步的补偿触发了一个新的Saga流程，整个系统可能被补偿请求淹没。

解决方案

方案一：补偿操作加限流。 给补偿操作设置独立的线程池和限流阈值，避免补偿请求挤占正常业务资源。

方案二：补偿操作加退避。 补偿失败后不立即重试，而是等待一段时间后再试。重试间隔逐次递增。

方案三：补偿操作独立幂等。 补偿操作必须幂等------重复执行结果一致。这样即使重试多次，也不会造成数据错误。

方案四：设置补偿超时和人工介入阈值。 补偿操作超过一定次数后，转为人工处理，避免系统被无限重试拖垮。

五、小结

TCC的空回滚、悬挂、幂等三个问题有一个共同的根因：网络延迟导致的时序乱序 。空回滚是Cancel先到了，悬挂是Try后到了，幂等是重复请求。解决方案的核心是事务记录表------Try执行前记录，Cancel执行前检查，Confirm/Cancel执行前查询状态。Saga的补偿风暴则源于补偿链的级联效应，需要通过限流、退避、独立幂等和人工介入阈值来控制。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽......我们下次见~