分布式事务：TCC / 2PC / Seata / Saga 详细讲解与高频面试题梳理

适用对象：Java 后端工程师、架构学习者、面试准备者
示例基线：Java + Spring Boot
资料原则：优先官方 Seata / Apache 文档，正文以原创整理为主

目录

• 一、先看结论
• 二、为什么需要分布式事务
• 三、2PC：经典两阶段提交
• 四、TCC：把事务下沉到业务层
• 五、Seata：把多种分布式事务模式串起来
• 六、Saga：长事务与补偿式设计
• 七、四种方案怎么选
• 八、高频面试题
• 九、参考资料

一、先看结论

分布式事务不是“把数据库事务搬到服务之间”这么简单，而是在跨服务、跨资源、跨网络的前提下，尽量维持业务一致性。

先给一个最短结论：

1. 2PC / XA：追求强一致，代价是阻塞、锁持有时间长、可用性差，适合对一致性极敏感且资源方支持 XA 的场景。
2. TCC：把一致性控制前移到业务层，性能和可控性更好，但侵入性高，必须认真处理幂等、空回滚、悬挂。
3. Seata AT：对关系型数据库最友好，业务侵入较低，适合大多数 CRUD 型分布式事务。
4. Saga：适合长事务、流程型业务、最终一致场景，核心不是“回滚”，而是“补偿”。

如果面试官问“哪个最好”，标准答案不是拍脑袋选一个，而是：

• 要强一致且可以接受阻塞，优先看 XA / 2PC
• 要业务可控、能接受改代码，优先看 TCC
• 要低侵入、主要是关系型数据库，优先看 Seata AT
• 要长流程、跨系统、跨组织，优先看 Saga

一句话记忆：

• 2PC 是协议
• TCC 是业务级两阶段提交
• Seata 是分布式事务框架
• Saga 是长事务补偿模式

二、为什么需要分布式事务

2.1 先看一个经典业务链路

假设用户下单时要同时处理：

• 订单服务：创建订单
• 库存服务：扣减库存
• 账户服务：扣减余额

如果这三个动作都在一个数据库里，本地事务就能解决。
但现实里它们通常是三个服务、三个数据库，甚至三个中间件。

这时就出现了问题：

• 订单创建成功，库存扣减失败
• 库存扣减成功，账户扣款失败
• 网络超时导致“到底成功没成功”无法立即确认

分布式事务要解决的，本质就是：一部分成功、一部分失败时，系统怎么保持业务结果正确。

2.2 CAP 和 BASE 怎么理解

CAP 不是分布式事务的专属名词，但它是理解“为什么没有完美方案”的底层背景。

CAP 的现实约束是：发生网络分区时，C 和 A 很难同时满足。

BASE 是工程上的妥协思路：

• Basically Available：基本可用
• Soft State：允许中间状态
• Eventually Consistent：最终一致

所以分布式事务不是在追求“永不失败”，而是在不同一致性等级之间做权衡。

2.3 一致性等级不要混淆

常见误区是把“事务一致性”理解成非黑即白。

实际上工程里更像一个梯度：

1. 强一致：提交后所有人立刻看到同样结果
2. 读写一致 / 会话一致：同一个用户或会话尽量看到自己的写入
3. 最终一致：短时间内可能不一致，但最终会收敛

2PC / XA 偏强一致，TCC / Seata AT 介于强一致和最终一致之间，Saga 更偏最终一致。

2.4 什么时候真的需要分布式事务

适合使用的场景：

• 订单、库存、账户这种强业务关联链路
• 金额、资产、配额、积分、券包这类不能乱账的场景
• 单次请求里必须同时成功或同时失败的核心动作

不适合硬上分布式事务的场景：

• 异步通知、埋点、日志、推荐、统计
• 允许迟到和补偿的业务
• 能拆成“先落主结果，再异步修正”的流程

2.5 贯穿全文的例子

本文后面统一用这个例子讲：

用户下单 100 元商品，系统需要同时：

• 创建订单
• 扣减库存 1 件
• 扣减账户余额 100 元

后面 2PC、TCC、Seata、Saga 都围绕这个链路展开。

三、2PC：经典两阶段提交

3.1 2PC 是什么

2PC（Two-Phase Commit，两阶段提交）是一种分布式事务提交协议。

它把提交过程拆成两步：

1. Prepare 阶段：各参与者先确认“我能不能提交”
2. Commit / Rollback 阶段：协调者根据投票结果决定统一提交还是回滚

它的核心目标是：所有参与者要么一起提交，要么一起回滚。

3.2 角色

这里常见一个面试追问：

• 2PC 不是只有数据库吗？

不是。2PC 是协议，数据库 XA 只是最典型的实现方式之一。

3.3 典型流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

sequenceDiagram
    participant C as Coordinator
    participant O as Order RM
    participant I as Inventory RM
    participant A as Account RM

    C->>O: Prepare
    C->>I: Prepare
    C->>A: Prepare
    O-->>C: Ready
    I-->>C: Ready
    A-->>C: Ready

    alt All ready
        C->>O: Commit
        C->>I: Commit
        C->>A: Commit
    else Any failure
        C->>O: Rollback
        C->>I: Rollback
        C->>A: Rollback
    end

3.4 为什么 2PC 会阻塞

2PC 最大的问题不是“难理解”，而是太依赖协调者和网络状态。

典型阻塞点：

1. 参与者在 prepare 后要持有资源锁，不能轻易释放
2. 如果协调者在 prepare 完成后宕机，参与者不知道该提交还是回滚
3. 如果网络分区，参与者会长时间等待决策

这意味着：

• 事务时间越长，锁持有越久
• 资源越多，阻塞面越大
• 故障恢复越复杂，系统可用性越差

3.5 2PC 的优缺点

3.6 2PC 和 XA 是什么关系

很多人会把 2PC 和 XA 画等号，这不严谨。

更准确地说：

• 2PC 是提交协议
• XA 是分布式事务接口规范
• 很多数据库的 XA 实现会采用 2PC 作为底层提交方式

所以在面试里可以这样答：

XA 可以理解成数据库资源管理器支持分布式事务的一套标准接口，而 2PC 是它常用的提交协议。两者有关联，但不完全等价。

3.7 2PC 适合什么场景

适合：

• 强一致要求极高
• 参与资源支持 XA
• 可以接受阻塞和较低吞吐

不适合：

• 高并发互联网核心链路
• 事务特别长的场景
• 需要高可用优先的系统

四、TCC：把事务下沉到业务层

4.1 TCC 是什么

TCC（Try-Confirm-Cancel）是一种业务层两阶段提交。

它不是让数据库帮你做全局协调，而是把一致性逻辑写进业务代码里：

1. Try：预留资源，检查并冻结
2. Confirm：确认提交，真正生效
3. Cancel：释放资源，撤销预留

可以把它理解成：

• Try = 占坑
• Confirm = 转正
• Cancel = 退坑

4.2 用订单场景理解 TCC

还是订单、库存、账户这条链路。

Try 阶段：

• 订单服务：创建“待确认”订单
• 库存服务：冻结 1 件库存
• 账户服务：冻结 100 元余额

Confirm 阶段：

• 订单状态改为“已确认”
• 冻结库存正式扣减
• 冻结余额正式扣减

Cancel 阶段：

• 订单取消
• 释放冻结库存
• 释放冻结余额

4.3 TCC 的核心不是“回滚 SQL”，而是“补偿业务”

这点非常关键。

TCC 的 Cancel 不是简单执行 try 的逆 SQL，而是根据业务状态做补偿动作。

例如：

• 不是“删掉订单”，而是“把订单从待确认改成已取消”
• 不是“把余额直接加回去”，而是“释放冻结余额”

这就是为什么 TCC 比 2PC 更灵活，也更费设计。

4.4 TCC 时序图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

sequenceDiagram
    participant TM as Transaction Manager
    participant O as Order Service
    participant I as Inventory Service
    participant A as Account Service

    TM->>O: Try
    TM->>I: Try
    TM->>A: Try
    O-->>TM: OK
    I-->>TM: OK
    A-->>TM: OK

    alt all try succeed
        TM->>O: Confirm
        TM->>I: Confirm
        TM->>A: Confirm
    else any try fail
        TM->>O: Cancel
        TM->>I: Cancel
        TM->>A: Cancel
    end

4.5 TCC 代码骨架

下面是一个简化版写法，重点看结构，不纠结实现细节。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

@Service
public class AccountTccService {

    @TwoPhaseBusinessAction(
            name = "accountTccAction",
            commitMethod = "commit",
            rollbackMethod = "cancel"
    )
    public boolean tryFreeze(BusinessActionContext context,
                             @BusinessActionContextParameter(paramName = "userId") Long userId,
                             @BusinessActionContextParameter(paramName = "amount") BigDecimal amount) {
        // 1. 校验余额是否足够
        // 2. 将可用余额转为冻结余额
        // 3. 记录 try 状态
        return true;
    }

    public boolean commit(BusinessActionContext context) {
        // 1. 幂等确认
        // 2. 将冻结余额正式扣减
        return true;
    }

    public boolean cancel(BusinessActionContext context) {
        // 1. 幂等回滚
        // 2. 释放冻结余额
        return true;
    }
}

全局发起方通常这样写：

1
2
3
4
5
6
7
8
9
10

@Service
public class OrderAppService {

    @GlobalTransactional(rollbackFor = Exception.class)
    public void placeOrder(Long userId, Long skuId, Integer count, BigDecimal amount) {
        orderService.createOrder(userId, skuId, count, amount);
        inventoryTccService.tryDeduct(skuId, count);
        accountTccService.tryFreeze(userId, amount);
    }
}

4.6 TCC 三个高频问题

1）幂等

Confirm 和 Cancel 都可能被重试，所以必须保证重复调用结果一致。

常见做法：

• 状态机表
• 业务唯一键
• fence log
• 乐观状态更新

2）空回滚

空回滚是指：Cancel 被调用了，但 Try 其实没执行成功或者根本没到达。

如果没有识别机制，Cancel 可能把本来不存在的预留资源“回滚”出一个错误状态。

解决思路：

• 记录 Try 是否真正执行过
• Cancel 时先查状态
• 用 fence 机制做状态校验

3）悬挂

悬挂是指：先执行了 Cancel，后续延迟到达的 Try 又把资源“占住”了。

这通常来自网络重试、超时和乱序消息。

解决思路：

• Try 前校验是否已经进入终态
• 拒绝晚到的 Try
• 同样依赖 fence / 状态表

4.7 Seata 的 TCC Fence 思路

Seata 的 TCC 体系里，一个常见思路是通过 fence 记录事务轨迹，帮助解决：

• 幂等
• 空回滚
• 悬挂

你可以把它理解成一个“事务护栏”：

• 先写状态
• 再做业务
• 再根据状态判断能不能重复执行

这样比单纯依靠业务方自己写 if else 更稳。

4.8 TCC 的优缺点

4.9 TCC 适合什么场景

适合：

• 金额冻结、库存预留、券码占用
• 有明确资源预留概念的业务
• 可以接受开发成本，但希望性能优于 XA

不适合：

• 业务逻辑特别简单，但不想改代码
• 无法清晰设计 Try/Confirm/Cancel 的场景
• 长流程且补偿逻辑太复杂的场景

五、Seata：把多种分布式事务模式串起来

5.1 Seata 是什么

Seata 是一个分布式事务解决方案。

它不是单一事务模型，而是一个平台，把常见模式串成了统一体系：

• AT
• TCC
• Saga
• XA

它最常见的三个角色是：

5.2 Seata 的整体架构

1
2
3
4
5
6
7
8
9

flowchart LR
    TM[TM\n事务发起者] --> TC[TC\n全局协调者]
    RM1[RM\n订单服务] --> TC
    RM2[RM\n库存服务] --> TC
    RM3[RM\n账户服务] --> TC
    TM --> APP[Spring Boot 应用]
    RM1 --> DB1[(订单库)]
    RM2 --> DB2[(库存库)]
    RM3 --> DB3[(账户库)]

5.3 Seata AT：最常见的模式

AT 模式最像“数据库级自动补偿”。

它的前提是：

• 使用关系型数据库
• 通过 JDBC 访问
• 业务大多是标准 CRUD

5.3.1 AT 的核心思想

AT 模式会在一阶段记录：

• before image：更新前的数据快照
• after image：更新后的数据快照
• undo log：回滚需要的补偿信息

二阶段提交时：

• 提交：删除 undo log 或做异步清理
• 回滚：根据 undo log 还原数据

5.3.2 AT 的执行过程

1. 业务 SQL 进入代理数据源
2. Seata 解析 SQL，拿到数据前镜像
3. 执行本地事务，生成 after image 和 undo log
4. 向 TC 注册全局事务和分支事务
5. 如果全局提交，异步清理 undo log
6. 如果全局回滚，根据 undo log 还原

5.3.3 直观理解

你可以把 AT 想成：

“先正常执行本地事务，但把后悔药准备好；如果全局失败，就按后悔药恢复。”

5.4 AT 里的锁与隔离

AT 不是“完全无锁”。

它在写场景下会引入全局锁来控制并发更新，避免多个分支同时改同一行导致脏写。

但读隔离不是所有情况都天然完美。

面试里常见的说法是：

• 写一致性靠全局锁和 undo log
• 读一致性需要结合业务要求额外设计

如果要更接近读已提交的体验，通常会在关键读写链路上额外处理。

5.5 AT 模式示例

1
2
3
4
5
6
7
8
9
10

@Service
public class OrderAppService {

    @GlobalTransactional(rollbackFor = Exception.class)
    public void createOrder(Long userId, Long skuId, Integer count, BigDecimal amount) {
        orderLocalService.createPendingOrder(userId, skuId, count, amount);
        inventoryLocalService.deduct(skuId, count);
        accountLocalService.deduct(userId, amount);
    }
}

注意这里：

• @GlobalTransactional 是全局事务入口
• 每个本地服务方法仍然是普通本地事务
• Seata 在底层帮你完成分支注册、回滚和补偿

5.6 Seata 的 TCC 模式

Seata 的 TCC 不是另起炉灶，而是把 TCC 的三阶段动作纳入统一事务协调。

关键词：

• @TwoPhaseBusinessAction
• BusinessActionContext
• 业务参数透传
• 幂等和 fence 机制

和 AT 的区别：

• AT 主要靠数据库自动补偿
• TCC 主要靠业务显式实现 Try / Confirm / Cancel

5.7 Seata 的 Saga 模式

Seata Saga 适合流程型长事务。

核心不是“提交后回滚数据库”，而是：

• 每个步骤先完成本地提交
• 如果中途失败，就调用补偿动作

Seata Saga 一般和状态机配合使用，更像是一个事务编排器。

5.8 Seata 的 XA 模式

XA 模式本质上就是把经典分布式事务规范接进 Seata 体系里。

特点：

• 资源方要支持 XA
• 强一致能力强
• 提交时可能阻塞较久
• 性能和并发通常不如 AT / TCC

它的价值更多在于：

• 旧系统迁移
• 资源方本来就支持 XA
• 需要标准化两阶段事务能力

5.9 Seata 适合什么场景

Seata 的价值在于：

• 统一协调多种模式
• 降低分布式事务门槛
• 让 Java / Spring Boot 场景更容易落地

一般建议：

• 标准 CRUD：优先 AT
• 强业务控制：选 TCC
• 长流程：选 Saga
• 既有 XA 资源：考虑 XA

六、Saga：长事务与补偿式设计

6.1 Saga 是什么

Saga 是一种长事务设计模式。

它的基本思路是：

1. 每个业务步骤先执行本地事务并提交
2. 如果后续步骤失败，就按相反方向执行补偿动作

Saga 更关注的是业务流程最终收敛，而不是一次性全局锁住所有资源。

6.2 Saga 和 TCC 的区别

两者都强调补偿，但思路不同：

6.3 Saga 的两种风格

1）编排式

由一个中心流程引擎决定下一步做什么、失败后怎么补偿。

优点：

• 可视化
• 流程清晰
• 适合复杂审批链路

2）协同式

各服务根据事件自己推进状态，彼此通过消息协作。

优点：

• 去中心化
• 松耦合

缺点：

• 排查复杂
• 状态理解成本高

Seata Saga 更偏编排式。

6.4 Saga 时序图

1
2
3
4
5
6
7
8

flowchart TD
    A[创建订单] --> B[扣减库存]
    B --> C[扣减账户余额]
    C --> D{是否成功}
    D -- 是 --> E[流程结束]
    D -- 否 --> F[补偿账户]
    F --> G[补偿库存]
    G --> H[取消订单]

6.5 Saga 的补偿不是“原样回滚”

这点是 Saga 的灵魂。

补偿动作不是 SQL 级别的反操作，而是业务语义上的逆动作。

例如：

• 创建订单的补偿不是删表，而是取消订单
• 扣库存的补偿不是简单加回，而是恢复可售库存
• 扣余额的补偿不是直接回写，而是发起退款或释放冻结额

因此补偿逻辑必须提前设计，而不是失败后临时拍脑袋补。

6.6 Saga 的优缺点

6.7 Saga 适合什么场景

适合：

• 订单审批、物流、报销、工单
• 跨系统、跨组织、跨时区流程
• 允许中间状态存在且最终收敛的业务

不适合：

• 必须一步到位的资金扣减
• 不能接受中间状态暴露的核心资产场景

七、四种方案怎么选

7.1 一张表看差异

7.2 选型口诀

可以直接背这一版：

1. 标准数据库 CRUD，先看 AT
2. 有明确预留语义，优先 TCC
3. 流程长、步骤多、允许最终一致，选 Saga
4. 资源方天然支持 XA 且强一致要求很高，再考虑 XA / 2PC

7.3 面试官常问的选型题

问：为什么不用 2PC 统一解决？

答：

• 2PC 阻塞长、可用性差
• 大规模互联网场景很容易拖垮吞吐
• 工程上更常用 TCC / AT / Saga 去做权衡

问：为什么不用 Saga 替代所有事务？

答：

• Saga 依赖补偿，不能天然保证强一致
• 资金、库存等高敏感业务通常更希望先预留再确认

问：为什么 TCC 还要做幂等、空回滚、悬挂？

答：

• 因为分布式网络天然有超时、重试、乱序
• 不把异常流设计好，业务一致性会被偶发重试打穿

八、高频面试题

8.1 基础概念类

1. 什么是分布式事务？
指跨多个服务、数据库或资源的一组操作，要么整体成功，要么整体失败，或者在失败后通过补偿最终收敛到一致状态。

2. 为什么本地事务解决不了跨服务一致性？
本地事务只能覆盖单个资源管理器。跨服务后，网络、超时、重试和独立提交会导致“部分成功、部分失败”。

3. CAP 怎么和分布式事务联系起来？
CAP 说明在网络分区时，一致性和可用性很难兼得。分布式事务本质上就是在 C、A、P 之间做工程权衡。

4. BASE 和强一致有什么区别？
BASE 接受短时间不一致，强调最终收敛；强一致则要求提交后所有节点立即看到统一结果。

5. 分布式事务和分布式锁是一回事吗？
不是。分布式锁解决并发互斥，分布式事务解决跨资源一致性。两者常配合，但目标不同。

6. 什么时候不该用分布式事务？
当业务能异步化、能最终一致、能拆成补偿流程时，就不一定需要分布式事务。能不用长事务就尽量不用。

8.2 2PC / XA 类

7. 2PC 的两个阶段分别是什么？
Prepare 阶段用于各参与者表态“我是否能提交”；Commit / Rollback 阶段由协调者根据投票结果统一决策。

8. 2PC 为什么会阻塞？
因为参与者在 prepare 后往往持有锁并等待最终决策。如果协调者宕机或网络分区，参与者就无法自行判断最终状态。

9. 2PC 的核心缺点是什么？
阻塞、锁持有时间长、协调器依赖强、恢复复杂、吞吐一般不高。

10. XA 和 2PC 是什么关系？
XA 是分布式事务的接口规范，2PC 是常见的提交协议。很多数据库 XA 实现会采用 2PC，但两者不完全等价。

8.3 TCC 类

11. TCC 是什么？
TCC 是 Try、Confirm、Cancel 三阶段业务级事务模式。Try 负责预留资源，Confirm 负责正式提交，Cancel 负责释放资源。

12. TCC 为什么比 2PC 更适合业务系统？
因为它把一致性控制交给业务代码，能表达“冻结、占坑、释放”这类真实业务语义，不完全依赖数据库底层协议。

13. TCC 的关键难点是什么？
幂等、空回滚、悬挂，以及 Try / Confirm / Cancel 的状态设计。

14. 什么是幂等？
同一请求重复执行多次，结果应该和执行一次一样。TCC 的 Confirm 和 Cancel 都必须幂等。

15. 什么是空回滚？
Cancel 到达时，Try 其实没成功执行或根本没到达。此时必须识别并安全处理，不能把不存在的预留资源“回滚坏”。

16. 什么是悬挂？
Cancel 先执行了，但 Try 因重试或乱序晚到。晚到的 Try 不能再把资源占住，否则会破坏一致性。

8.4 Seata 类

17. Seata 里的 TC、TM、RM 分别做什么？
TM 发起和结束全局事务；TC 负责协调和记录全局状态；RM 管理各分支事务，执行本地资源操作并向 TC 汇报。

18. Seata AT 的核心原理是什么？
通过代理数据源拦截 SQL，记录 before image / after image 和 undo log；提交时清理补偿数据，回滚时按 undo log 恢复。

19. Seata AT 为什么适合大多数 CRUD 业务？
因为它对业务侵入较低，尤其适合关系型数据库和标准增删改场景，开发成本远低于手写 TCC。

20. Seata AT 的局限是什么？
强依赖 RDBMS 和 JDBC，复杂 SQL、非关系型资源、特别长事务、强个性化业务逻辑都不是它的强项。

21. Seata 的 TCC 和 AT 有什么区别？
AT 更偏数据库自动补偿；TCC 更偏业务显式预留和确认。AT 低侵入，TCC 高可控。

22. Seata 的 XA 模式有什么特点？
XA 模式更接近数据库原生分布式事务，强一致能力强，但通常阻塞较重、吞吐一般不如 AT 或 TCC。

8.5 Saga / 选型类

23. Saga 和 TCC 最大区别是什么？
TCC 先预留再确认，Saga 先执行再补偿。TCC 更适合资源冻结类业务，Saga 更适合长流程和最终一致场景。

24. 为什么 Saga 不能随便用“删数据”当补偿？
因为补偿不是简单逆操作，而是业务语义逆动作。很多场景里删除不等于撤销，反而会破坏审计、状态和幂等。

25. 你会怎么选分布式事务方案？
先看业务是否真需要强一致；若需要且资源支持 XA，可考虑 XA / 2PC；若是冻结扣减类，优先 TCC；若是标准 RDBMS CRUD，优先 AT；若是长流程，优先 Saga。

26. 分布式事务能不能做到绝对完美？
不能。网络故障、节点宕机、超时重试、消息乱序都客观存在。工程上能做的是明确一致性边界、降低故障面、设计好补偿和兜底。

8.6 答题模板

如果面试官让你“详细讲讲”，建议按这个结构答：

1. 定义：先说它是什么
2. 原理：讲流程图或核心状态机
3. 优缺点：说清楚为什么选它、为什么不用它
4. 场景：结合订单 / 库存 / 账户举例
5. 风险点：幂等、补偿、阻塞、回滚、隔离
6. 对比：和其他方案做一轮横向比较

这个模板几乎适用于 2PC、TCC、Seata、Saga 四类问题。

九、参考资料

以下资料用于核对官方术语和模式边界，正文内容已做原创整理：

1. Seata 官方文档总览
   https://seata.apache.org/zh-cn/docs/overview/what-is-seata

2. Seata 官方文档 - AT 模式
   https://seata.apache.org/zh-cn/docs/user/mode/at/

3. Seata 官方文档 - TCC 模式
   https://seata.apache.org/zh-cn/docs/user/mode/tcc

4. Seata 官方文档 - Saga 模式
   https://seata.apache.org/zh-cn/docs/user/mode/saga/

5. Seata 官方文档 - XA 模式
   https://seata.apache.org/zh-cn/docs/user/mode/xa/

6. Seata TCC Fence 机制说明
   https://seata.apache.org/zh-cn/blog/seata-tcc-fence/

7. Seata 官方仓库与源码
   https://github.com/apache/incubator-seata

__END__