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

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 · 简化

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

常见误区

"柔性事务 = 弱一致"

柔性事务 = 最终一致（承诺收敛），弱一致是完全放弃一致

"分布式事务 = 2PC"

2PC 只是分布式事务的一种模式，还有 TCC/Saga/消息等多种

"强一致一定比最终一致好"

强一致牺牲可用性（2PC 阻塞），业务实际可容忍秒级不一致

"RPC 是实现分布式事务的方式"

RPC 是远程调用协议，分布式事务靠 2PC/TCC/消息等协议或补偿机制

"Seata 叫 STAY"

Seata（Apache 项目，S-e-a-t-a），最主流的开源分布式事务框架

延伸追问

"分布式事务中的'最终一致'和单机事务的'原子性'在工程上有什么本质区别？"

要点：原子性是同步的、事务边界清晰；最终一致是异步的、需要一个"收敛点"（回调/消息确认/对账）。验证靠对账系统 + 状态机终态检查

"TCC、Seata AT、本地消息表，如果只能选一个用于订单+库存+支付+通知的业务，你会选哪个？"

要点：主链路同步 → Seata AT 或 TCC；通知异步 → 事务消息。核心原则：主链路强一致用 TCC/AT，副链路最终一致用消息

"CAP 中 C 和 A 不可能同时满足，那 Seata AT 号称'强一致'，实际是 CP 还是 AP？"

要点：Seata AT 是"近似强一致"，实际是 CP（协调者宕机时事务阻塞或回滚），不是真正的"强一致+高可用"

"最大努力通知为什么算柔性事务？它的一致性保证到底有多'弱'？"

要点：最大努力通知只保证"尽力通知 N 次"，不保证业务成功，是柔性事务中最弱的一类，适合"通知"类业务（如支付成功通知）

"如果老板问'为什么我们不用 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 个模式

关联知识

用协议/补偿/异步弥补没有单一协调者的缺口

同时办开户+转账+理财，没有一个人能全办，只能强一致（都举手再办）或最终一致（异步通知）

✦ 记忆口诀 ✦

主链路强一致、副链路最终一致 / 选型看一致性容忍度

关键可视化

CAP 与 BASE 理论框架

flowchart TB
  A[分布式事务] --> CAP[CAP 选择]
  CAP --> CP[CP 强一致]
  CAP --> AP[AP 最终一致]
  CP --> P1[2PC]
  CP --> P2[3PC]
  CP --> P3[XA]
  CP --> P4[Seata AT]
  AP --> P5[Saga]
  AP --> P6[TCC]
  AP --> P7[本地消息表]
  AP --> P8[事务消息]
  BASE[BASE 理论] --> AP
  BASE --> B1[基本可用]
  BASE --> B2[软状态]
  BASE --> B3[最终一致]

分布式事务模式三分类

flowchart TB
  A[分布式事务模式] --> S[强一致]
  A --> M[准强一致]
  A --> E[最终一致]
  S --> S1[2PC 会阻塞]
  S --> S2[3PC 可能阻塞]
  S --> S3[XA 会阻塞]
  S --> S4[Seata AT 不阻塞]
  M --> M1[TCC 业务补偿]
  E --> E1[Saga 长链路]
  E --> E2[本地消息表]
  E --> E3[事务消息 RocketMQ]
  E --> E4[最大努力通知]

业务选型决策树

flowchart TB
  A[需要事务保证] --> Q1[链路是否在主流程]
  Q1 -->|否| F[用消息 本地消息表 或 RocketMQ]
  Q1 -->|是| Q2[是否跨多个独立资源]
  Q2 -->|否 单库多表| L[本地事务]
  Q2 -->|是| Q3[资源是否都是关系型 DB]
  Q3 -->|是| AT[Seata AT]
  Q3 -->|否| TCC[TCC]
  Q3 --> Q4[是否有强审计合规要求]
  Q4 -->|是| TCC2[TCC]
  Q4 -->|否| SAGA[Saga 或 Seata AT]

TCC 三方法语义

flowchart LR
  A[转账场景] --> T[Try 冻结资源]
  A --> C[Confirm 确认提交]
  A --> X[Cancel 取消补偿]
  T --> T1[冻结 A 账户 100 元]
  C --> C1[真实扣款 100 元]
  X --> X1[释放冻结 100 元]

本地消息表流程

flowchart LR
  A[本地事务] --> B[业务 SQL + 写消息表]
  B --> C[定时扫表]
  C --> D[投递 MQ]
  D --> E[消费端处理]
  E --> F[更新状态]
  F --> G[INIT 到 SENT 到 DELIVERED 到 ACKED]

知识关系

⬆️ 前置（Prerequisite）

暂无

🔄 延伸（Extends）

2pc-3pc seata-at tcc-pitfalls local-message-table

⚡ 对比（Contrast）

单机事务— 单机事务由数据库引擎保证 ACID；分布式事务靠协议/补偿/异步

🎯 概念 📏 规则 ⚠️ 误区 🔍 追问 ✨ 口诀共 0 张卡，点击翻面