分布式事务速查卡

概念

1. 本地事务四特性 ACID：
   • 原子性（全做或全不做）
   • 一致性（约束不被破坏）
   • 隔离性（并发互不干扰，防脏读/幻读）
   • 持久性（提交即持久化）
2. 分布式事务：跨 JVM 进程/跨数据源的事务机制，目标仍是保证数据一致性。
3. 产生场景三类（概括 = 跨库、跨服务、混合式）：
   • 跨服务：微服务远程调用，如订单服务+库存服务
   • 单体访问多个数据库实例
   • 多服务访问同一数据库（连接不同仍跨进程）

坐标系：刚性 vs 柔性

阵营	理论	一致性	代表方案
刚性事务	ACID	强一致（锁资源、同步等待）	2PC/XA、3PC
柔性事务	BASE	最终一致（补偿/重试/对账兜底）	TCC、本地消息表、事务消息、Saga、最大努力通知

方案全景对比

方案	一致性	性能	复杂度	适用场景
2PC（XA）	强一致	低（同步阻塞锁资源）	低（数据库层）	单应用跨多库、低并发
3PC	强一致（仍有不一致风险）	较低	中	理论改进，工程少用
TCC	最终一致（准强一致）	较高	高（Try/Confirm/Cancel 三接口）	资金/支付等核心高并发场景
本地消息表	最终一致	中	中	中小系统异步解耦
事务消息（RocketMQ）	最终一致	高	中	高并发异步，国内主流
Saga	最终一致	高（无锁）	中高（正向+补偿服务）	长流程、多参与方、含第三方系统
最大努力通知	弱（不保证送达）	高	低	支付结果通知商户等

速记：一致性强度 2PC ≈ 3PC > TCC > 消息类 ≈ Saga > 最大努力通知。复杂度转移——刚性事务复杂度在数据库/中间件，柔性事务复杂度在业务代码（补偿、幂等）。

各方案一句话原理

1. 2PC：协调者两阶段——先问所有参与者能否提交（写 Undo/Redo 不提交，答 Yes/No）。再统一下发 Commit/Rollback。缺点：同步阻塞、协调者单点、Commit 部分送达时不一致。
2. 3PC：CanCommit（不锁资源）→ PreCommit（写日志）→ DoCommit；双方引入超时，参与者超时默认提交。缓解阻塞但网络异常时仍可能不一致，工程少用。
3. TCC：业务层实现 Try（冻结/预留资源）、Confirm（真正执行，幂等）、Cancel（释放预留，幂等）。三大坑：空回滚（Cancel 先到）、幂等（重试多次）、悬挂（Cancel 后迟到 Try 又冻结资源）。
4. 本地消息表（eBay）：业务与消息记录同一本地事务写入 → 发 MQ。下游消费后回写状态 → 定时扫表重投未确认消息。缺点：消息表与业务同库，高并发瓶颈。
5. 事务消息（RocketMQ）：先发 half 消息 → 执行本地事务 → 提交确认/回滚 → MQ 投递给下游。MQ 回查未确认的 half 消息兜底。消费方需幂等。
6. Saga：长事务拆成 T1..Tn 一串本地事务直接提交。Tk 失败则反向执行补偿 Ck-1..C1。编排（中央协调）与协同（事件驱动）两种实现。不保证隔离性，中间态可见。
7. 最大努力通知：本地事务后发通知，按衰减间隔重试 N 次。仍失败则放弃，辅以查询接口对账 + 人工兜底。

理论基础速记

1. CAP：分布式系统一致性 C、可用性 A、分区容错 P 三者不可兼得。网络分区必然存在，实际是在 CP 与 AP 之间取舍。强一致选 CP（牺牲可用），最终一致选 AP。
2. BASE：Basically Available（基本可用）、Soft state（软状态/中间态）、Eventually consistent（最终一致）。是 AP 的工程化延伸，柔性事务的理论依据。
3. 术语：全局事务（分布式事务整体）、分支事务（各参与者的本地事务）。XA 由 X/Open DTP 模型定义，TM（事务管理器/协调者）+ RM（资源管理器/参与者）。
4. 相关细节见同目录单篇：2PC、3PC、CAP、BASE。

选型话术（面试）

1. 高并发互联网场景不碰 XA，主用柔性事务保最终一致。
2. 资金/交易强一致 + 高并发：TCC。
3. 一般异步场景（下单异步扣库存）：事务消息（RocketMQ）。
4. 长流程、含第三方/遗留系统：Saga。
5. 纯通知类：最大努力通知。
6. 共同前提：幂等、重试、对账、人工兜底是标配；可提 Seata（AT/TCC/Saga 多模式）。

原链接已失效，2026-10 依据主题重写（参考本库 分布式事务解决方案总纲）。