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

分布式事务有一个诡异的定律：

测试环境跑一百遍都没事，上线第一分钟就翻车。

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

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

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

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

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

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

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

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

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

Try执行前先记录，Cancel执行前先检查。

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
);


// 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才姗姗来迟

空回滚和悬挂是一对孪生问题。

 空回滚是“Cancel先到了”，悬挂是“Try后到了”。两者都源于网络延迟导致的乱序。

。Try接口在执行前检查这条记录：

// 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");
}


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

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

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

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


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

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

。如果LTn失败，需要按反向顺序执行：

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

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

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

 补偿失败后不立即重试，而是等待一段时间后再试。重试间隔逐次递增。

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

方案四：设置补偿超时和人工介入阈值。

 补偿操作超过一定次数后，转为人工处理，避免系统被无限重试拖垮。

TCC的空回滚、悬挂、幂等三个问题有一个共同的根因：

。空回滚是Cancel先到了，悬挂是Try后到了，幂等是重复请求。解决方案的核心是

——Try执行前记录，Cancel执行前检查，Confirm/Cancel执行前查询状态。Saga的补偿风暴则源于补偿链的级联效应，需要通过限流、退避、独立幂等和人工介入阈值来控制。

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

Saga补偿风暴的触发链路与限流策略——分布式事务从2PC到Saga的选型实践

TCC的Cancel执行了但Try根本没执行过——这是空回滚。Try在Cancel之后才到达——这是悬挂。Saga的补偿操作级联触发导致系统被补偿请求淹没——这是补偿风暴。三个问题有一个共同特征：代码在测试环境跑得好好的，一到生产就出问题，而且出问题时往往账已经对不上了。本文拆解TCC空回滚、悬挂、幂等三大坑的时序成因，给出事务记录表的解决方案，分析Saga补偿风暴的触发链路和限流策略。

编程语言

TCC分布式事务三大陷阱：空回滚、悬挂、幂等，核心解法靠事务记录表。Try前记录、Cancel前检查、Confirm/Cancel幂等判断。Saga补偿风暴需限流、退避、独立幂等与人工介入阈值控制，避免系统被级联补偿淹没。

网络延迟

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

Saga补偿风暴的触发链路与限流策略——分布式事务从2PC到Saga的选型实践

Saga补偿风暴的触发链路与限流策略——分布式事务从2PC到Saga的选型实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐