分布式事务核心概念
分布式事务是微服务与分布式系统中最具挑战的领域之一。本章从理论基石出发，逐步深入到主流实现模式，帮助你在架构选型时做出理性决策。
3.1 CAP 定理：分布式系统的“不可能三角”
CAP 定理由 Eric Brewer 于 2000 年提出，是分布式系统设计的根本约束。它指出一个分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 全称 | 说明 |
|---|---|---|
| C | Consistency（一致性） | 所有节点在同一时刻看到相同的数据 |
| A | Availability（可用性） | 每个请求都能获得非错误的响应 |
| P | Partition Tolerance（分区容错性） | 系统在网络分区时仍能正常运行 |
关键认知：在分布式系统中，网络分区是必然发生的，因此 P 是必选项。实际决策是在 CP 与 AP 之间做权衡。
3.2 BASE 理论：对 CAP 的务实妥协
BASE 理论由 eBay 架构师 Dan Pritchett 提出，是对 CAP 中 AP 路线的实践总结。它放弃了强一致性，追求最终一致性：
- BA — Basically Available（基本可用）：系统允许部分功能降级，但核心服务保持可用
- S — Soft State（软状态）：允许数据存在中间状态，不要求时刻一致
- E — Eventually Consistent（最终一致）：经过一定时间后，所有副本数据最终达成一致
BASE vs ACID：ACID 是单机事务的黄金标准，BASE 是分布式环境下对可用性与扩展性的妥协。BASE 不保证实时一致，但保证“最终会一致”。
3.3 2PC / 3PC：传统分布式事务协议
3.3.1 两阶段提交（2PC）
2PC 引入协调者（Coordinator）角色，将事务提交分为两个阶段：
| 阶段 | 动作 | 参与者状态 |
|---|---|---|
| 阶段一：准备 | 协调者向所有参与者发送 prepare 请求，参与者执行事务但不提交，返回 Yes/No | 就绪 / 中止 |
| 阶段二：提交/回滚 | 若全部返回 Yes，协调者发送 commit；否则发送 rollback | 提交 / 回滚 |
2PC 痛点：同步阻塞（参与者等待协调者指令期间锁定资源）、单点故障（协调者宕机导致事务悬空）、脑裂风险（网络分区时参与者无法确定协调者意图）。
3.3.2 三阶段提交（3PC）
3PC 在 2PC 基础上引入超时机制和中间阶段，降低阻塞范围：
- CanCommit（询问阶段）：协调者询问参与者是否具备提交条件，参与者返回可行性
- PreCommit（预提交阶段）：协调者发送预提交指令，参与者执行事务但不提交
- DoCommit（提交阶段）：协调者发送最终提交或中止指令
3PC 改进：参与者引入超时机制，在等待协调者指令超时后自动中止事务，避免 2PC 的无限阻塞问题。但 3PC 仍无法完全解决网络分区下的数据一致性问题。
3.4 TCC 模式：业务补偿型分布式事务
TCC（Try-Confirm-Cancel）是一种业务层面的分布式事务方案，将每个服务操作拆分为三个阶段：
| 阶段 | 操作 | 示例（订单+库存） |
|---|---|---|
| Try | 预留资源，检查业务条件 | 冻结库存数量，创建订单待支付状态 |
| Confirm | 确认执行，完成业务操作 | 扣减冻结库存，订单状态改为已支付 |
| Cancel | 取消操作，释放预留资源 | 释放冻结库存，订单状态改为已取消 |
TCC 优势：无全局锁、性能高、适合高并发场景。
TCC 挑战：业务侵入性强，每个服务需实现 Try/Confirm/Cancel 三个接口；Cancel 操作必须能正确回滚 Try 阶段的操作。
TCC 挑战：业务侵入性强，每个服务需实现 Try/Confirm/Cancel 三个接口；Cancel 操作必须能正确回滚 Try 阶段的操作。
3.5 Saga 模式：长事务的最终一致方案
Saga 模式将一个大事务拆分为多个本地事务，每个本地事务都有对应的补偿事务。Saga 有两种执行方式：
3.5.1 编排式 Saga（Choreography）
- 每个服务完成本地事务后，发布事件触发下一个服务
- 任一服务失败，通过事件触发补偿流程
- 适合服务数量少、流程简单的场景
3.5.2 协调式 Saga（Orchestration）
- 引入 Saga 协调器（Orchestrator）统一管理流程
- 协调器向各服务发送指令，并跟踪执行状态
- 适合服务数量多、流程复杂的场景
3.6 模式对比与选型建议
| 模式 | 一致性 | 性能 | 业务侵入 | 适用场景 |
|---|---|---|---|---|
| 2PC | 强一致 | 低（同步阻塞） | 低 | 传统数据库、短事务、低并发 |
| 3PC | 强一致（弱于2PC） | 中 | 低 | 对可用性有要求的传统场景 |
| TCC | 最终一致 | 高 | 高 | 高并发、资源预留型业务（库存、账户） |
| Saga | 最终一致 | 高 | 中 | 长事务、跨服务流程（订单、旅行预订） |
选型建议：金融、支付等强一致场景优先考虑 2PC 或 TCC；互联网高并发、长流程场景优先考虑 Saga；对一致性要求不高的场景可考虑消息队列+本地事件表实现最终一致。