---
title: 分布式事务概览与模式分类
type: concept
domain: distributed-transaction
tags: [distributed-transaction, 2pc, tcc, saga, local-message-table, transactional-message, base, cap]
status: learning
created: 2026-09-23
last_reviewed: 2026-09-23
method: feynman
related_questions:
  - "什么是分布式事务？"
  - "什么是柔性事务？"
  - "常见的分布式事务有哪些？"
related_knowledge:
  - ./2pc-3pc.md
  - ./seata-at.md
  - ./tcc-pitfalls.md
  - ./local-message-table.md
  - ./cross-border-payment-design.md
  - ../mysql/mysql-transaction-core.md
anki_cards: 8
interview_rounds:
  - "2026-09-23-round-2-Q1"
  - "2026-09-23-round-2-Q3"
  - "2026-09-23-round-2-Q4"
---

# 分布式事务概览与模式分类

> 分布式事务是"跨资源边界的原子性"抽象。单机事务由数据库引擎保证，分布式事务没有单一协调者，只能靠协议/补偿/异步达成跨节点原子性。理解模式分类是选型的前提。

## TL;DR（30 秒扫完）

- **本质**：单机事务由数据库引擎保证 ACID；分布式事务靠**协议/补偿/异步**实现跨节点原子性
- **CAP 选择**：P 不可避免时，选 **CP**（强一致：2PC/XA）或 **AP**（最终一致：Saga/TCC/消息）
- **柔性事务 = 最终一致**，不是弱一致——BASE 理论是对 ACID 的哲学放宽
- **模式按一致性强度分三类**：强一致（2PC/3PC/XA/Seata AT）→ 准强一致（TCC）→ 最终一致（Saga/本地消息表/事务消息/最大努力通知）
- **选型原则**：核心账务→TCC/XA；订单主链路→Seata AT/TCC；通知/积分→消息（分层治理）

## 关键结论

- **结论 A**：分布式事务的本质是"用业务协议弥补存储引擎原子性边界之外的缺口"
- **结论 B**：柔性事务不是"技术降级"，而是"哲学选择"——用短暂不一致换高可用+高吞吐
- **结论 C**：没有银弹，核心金融往往是"自研 TCC + 消息 + 对账"的组合拳
- **结论 D**：选型不看技术先进性，看业务对一致性的容忍度

## 完整讲解（费曼四步）

### STEP 1 · 概念

**分布式事务**：跨多个独立资源（数据库、MQ、外部 API、缓存）的原子性操作，没有单一协调者能直接控制所有参与者，只能靠协议、补偿或异步消息达成"跨节点原子性"。

**柔性事务**：放宽 ACID 中的一致性（C）和隔离性（I），追求最终一致，允许中间存在短暂不一致状态，通过补偿/重试/对账收敛。

### STEP 2 · 大白话

**单机事务类比**：去银行柜台办业务，柜员说"我帮你办完"，你不用管中间步骤——引擎自己保证。

**分布式事务类比**：你同时要办"开户+转账+理财"三件事，分别找三个不同的柜员。没有一个人能帮你全部办完，只能：
- **强一致方案**：三个人都举手说"能办"再一起办，否则都不办（2PC）
- **最终一致方案**：先让你办完开户，然后异步通知转账柜员，最后通知理财柜员（消息驱动）

**柔性 vs 弱一致**：
- 弱一致：我尽量告诉你，但可能永远不告诉你（放弃一致）
- 最终一致：我晚点一定告诉你（承诺收敛）

### STEP 3 · 底层

#### 三大理论框架

| 理论 | 核心 | 与分布式事务的关系 |
|------|------|------------------|
| **ACID** | 原子性/一致性/隔离性/持久性 | 单机事务的基石 |
| **CAP** | 一致性/可用性/分区容错 | P 不可避免，选 C 或 A |
| **BASE** | 基本可用/软状态/最终一致 | 对 ACID 的哲学放宽，是柔性事务的理论根基 |

**CAP 在分布式事务中的映射**：
- **CP 选择** → 强一致：2PC、3PC、XA、Seata AT
- **AP 选择** → 最终一致：Saga、TCC、本地消息表、事务消息、最大努力通知

#### 模式完整清单（按一致性强度排序）

| 类别 | 模式 | 一致性 | 侵入性 | 性能 | 阻塞 | 典型场景 |
|------|------|--------|--------|------|------|---------|
| **强一致** | 2PC | 强 | 低 | 低 | **会阻塞** | 早期银行 |
| | 3PC | 强 | 低 | 低 | 可能阻塞 | 学术为主 |
| | XA | 强 | 低 | 低 | 会阻塞 | MySQL 跨库 |
| | Seata AT | 强 | 低 | 中 | 不阻塞 | 订单+库存 |
| **准强一致** | TCC | 强 | **高** | 中高 | 不阻塞 | 核心金融 |
| **最终一致** | Saga | 最终 | 中 | 高 | 不阻塞 | 长链路编排 |
| | 本地消息表 | 最终 | 中 | 高 | 不阻塞 | 上下游解耦 |
| | 事务消息（RocketMQ） | 最终 | 低 | 高 | 不阻塞 | 支付通知 |
| | 最大努力通知 | 最终（弱） | 低 | 高 | 不阻塞 | 第三方通知 |

#### Seata 的 4 种模式

- **AT 模式**：自动补偿，代理数据源，低侵入；基于 undo log 实现回滚
- **TCC 模式**：业务显式实现 Try/Confirm/Cancel 三方法
- **Saga 模式**：长链路状态机编排，适合多步业务流程
- **XA 模式**：兼容 JTA，本质是 2PC

#### TCC 三方法语义

- **Try**：冻结资源（如扣冻结余额，不实际扣款），预留资源
- **Confirm**：确认提交（如真的扣款），Try 成功后才执行
- **Cancel**：取消补偿（如释放冻结），Try 失败或下游 Cancel

#### 本地消息表机制

```
1. 本地事务：insert order + insert local_message  ← 同一本地事务
2. 主事务提交
3. 定时器扫描 local_message → 发 MQ → 更新状态为 SENT
4. 消费端：幂等消费，失败重试
```

#### 事务消息（RocketMQ）机制

```
1. 业务发 half message → MQ 暂存
2. 执行本地事务
3. 本地事务成功 → commit half message → 正常投递
4. 本地事务失败 → rollback half message → 不投递
5. 不确定 → 回查业务方
```

#### 业务选型决策树

```
业务场景需要事务保证？
│
├─ 否 → 无事务，业务兜底
│
└─ 是 → 链路是否在主流程？
    │
    ├─ 否（通知、积分、风控）
    │   └─ 用消息：本地消息表 或 RocketMQ 事务消息
    │
    └─ 是（订单、支付、扣款）
        │
        ├─ 是否跨多个独立资源（不同 DB / 外部 API）？
        │   │
        │   ├─ 否（单库内多表）→ 本地事务
        │   │
        │   └─ 是
        │       │
        │       ├─ 资源是否都是关系型 DB？
        │       │   ├─ 是 → Seata AT（低侵入，快速落地）
        │       │   └─ 否 → TCC（资源异构，业务可控）
        │       │
        │       └─ 是否有强审计 / 合规要求？
        │           ├─ 是 → TCC（每步可审计）
        │           └─ 否 → Seata AT / Saga（长链路）
```

### STEP 4 · 简化

> **一句话总结**：分布式事务 = 用协议/补偿/异步弥补"没有单一协调者"的缺口；选型看业务对一致性的容忍度，主链路强一致、副链路最终一致。

## 常见误区（从面试记录提炼）

- **误区 1**："柔性事务 = 弱一致" → 正确：柔性事务 = **最终一致**（承诺收敛），弱一致是完全放弃一致
- **误区 2**："分布式事务 = 2PC" → 正确：2PC 只是分布式事务的一种模式，还有 TCC/Saga/消息等多种
- **误区 3**："强一致一定比最终一致好" → 正确：强一致牺牲可用性（2PC 阻塞），业务实际可容忍秒级不一致
- **误区 4**："RPC 是实现分布式事务的方式" → 正确：RPC 是远程调用协议，分布式事务靠 2PC/TCC/消息等**协议或补偿机制**
- **误区 5**："Seata 叫 STAY" → 正确：**Seata**（Apache 项目，S-e-a-t-a），最主流的开源分布式事务框架

## 延伸追问（面试追问预演）

1. **"分布式事务中的'最终一致'和单机事务的'原子性'在工程上有什么本质区别？"**
   - 要点：原子性是同步的、事务边界清晰；最终一致是异步的、需要一个"收敛点"（回调/消息确认/对账）。验证靠**对账系统 + 状态机终态检查**

2. **"TCC、Seata AT、本地消息表，如果只能选一个用于订单+库存+支付+通知的业务，你会选哪个？"**
   - 要点：主链路同步 → Seata AT 或 TCC；通知异步 → 事务消息。核心原则：**主链路强一致用 TCC/AT，副链路最终一致用消息**

3. **"CAP 中 C 和 A 不可能同时满足，那 Seata AT 号称'强一致'，实际是 CP 还是 AP？"**
   - 要点：Seata AT 是"近似强一致"，实际是 **CP**（协调者宕机时事务阻塞或回滚），不是真正的"强一致+高可用"

4. **"最大努力通知为什么算柔性事务？它的一致性保证到底有多'弱'？"**
   - 要点：最大努力通知只保证"尽力通知 N 次"，不保证业务成功，是柔性事务中最弱的一类，适合"通知"类业务（如支付成功通知）

5. **"如果老板问'为什么我们不用 2PC 保证强一致，非要用柔性事务？'"**
   - 要点：2PC 阻塞严重，大促时协调者宕机=全站不可用；业务实际可容忍秒级不一致；柔性事务吞吐量比 2PC 高 10-100 倍

## 速查表（一页扫完）

| 维度 | 内容 |
|------|------|
| **本质** | 跨资源边界的"原子性"抽象，靠协议/补偿/异步实现 |
| **理论框架** | ACID（单机）→ CAP（选型）→ BASE（柔性事务根基） |
| **强一致** | 2PC / 3PC / XA / Seata AT |
| **准强一致** | TCC（Try/Confirm/Cancel） |
| **最终一致** | Saga / 本地消息表 / 事务消息 / 最大努力通知 |
| **Seata 4 模式** | AT / TCC / Saga / XA |
| **选型原则** | 核心账务→TCC/XA；订单主链路→Seata AT/TCC；通知/积分→消息 |
| **关键金句** | "主链路强一致、副链路最终一致"，"柔性事务是哲学选择不是技术降级" |

## 关联题目

- ⚠️ 《什么是分布式事务？》— 2026-09-23 Round 2 Q1, ⭐⭐⭐, 术语混淆（RPC→2PC、STAY→Seata）
- ⚠️ 《什么是柔性事务？》— 2026-09-23 Round 2 Q3, ⭐⭐⭐, 未提 BASE 理论根基
- ⚠️ 《常见的分布式事务有哪些？》— 2026-09-23 Round 2 Q4, ⭐⭐, medium 难度只列举 3 个模式

## 关联知识

- [2PC 与 3PC 协议深度解析](./2pc-3pc.md)
- [Seata AT 模式](./seata-at.md)
- [TCC 与三大坑](./tcc-pitfalls.md)
- [本地消息表](./local-message-table.md)
- [跨境支付方案设计](./cross-border-payment-design.md)
- [MySQL 事务核心](../mysql/mysql-transaction-core.md)

## Anki 候选卡片

**卡片 1**
- Q：分布式事务的本质是什么？
- A：跨资源边界的"原子性"抽象，靠协议/补偿/异步实现跨节点原子性（因为没有单一协调者能直接控制所有参与者）

**卡片 2**
- Q：柔性事务的"最终一致"和"弱一致"有什么区别？
- A：最终一致是"晚点一定到达"（承诺收敛），弱一致是"完全放弃一致"

**卡片 3**
- Q：CAP 中 P 不可避免时，选 C 或 A 对应哪些分布式事务模式？
- A：选 C → 强一致（2PC/3PC/XA/Seata AT）；选 A → 最终一致（Saga/TCC/消息）

**卡片 4**
- Q：BASE 理论的三个字母分别是什么？
- A：Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致）

**卡片 5**
- Q：分布式事务模式按一致性强度分三类，分别有哪些？
- A：强一致（2PC/3PC/XA/Seata AT）→ 准强一致（TCC）→ 最终一致（Saga/本地消息表/事务消息/最大努力通知）

**卡片 6**
- Q：业务选型原则是什么？
- A：核心账务→TCC/XA；订单主链路→Seata AT/TCC；通知/积分/风控→本地消息表或事务消息（主链路强一致、副链路最终一致）

**卡片 7**
- Q：为什么业务实践倾向于柔性事务而不是 2PC？
- A：2PC 阻塞严重（协调者宕机=全站不可用），柔性事务吞吐量高 10-100 倍，业务实际可容忍秒级不一致

**卡片 8**
- Q：Seata 的 4 种模式分别是什么？
- A：AT（自动补偿/undo log）、TCC（业务三方法）、Saga（状态机编排）、XA（内置 2PC/JTA）