📚 课程目录第2章分布式事务基础回顾

2、分布式事务基础回顾：CAP理论、BASE理论、2PC、3PC、TCC、Saga模式核心概念

在构建分布式事务压测场景之前，必须重新夯实分布式事务的理论基石。本章将系统梳理从理论到落地的关键概念，包括 CAP 与 BASE 理论、2PC 与 3PC 协议、以及 TCC 与 Saga 模式。这些知识将直接指导后续压测场景的模型设计与故障注入策略。

2.1 CAP 理论：分布式系统的“不可能三角”

CAP 理论由 Eric Brewer 于 2000 年提出，是分布式系统设计的根本约束。它指出一个分布式系统最多只能同时满足以下三个特性中的两个：

特性	全称	核心含义	压测关注点
C	Consistency（一致性）	所有节点在同一时刻看到相同的数据	数据校验点、读写延迟
A	Availability（可用性）	每个请求都能获得非错误的响应	请求成功率、超时率
P	Partition Tolerance（分区容错性）	系统在网络分区时仍能正常运行	网络故障注入、脑裂场景

压测启示： 在压测场景中，必须明确被测系统选择了 CP 还是 AP 路线。CP 系统（如 Zookeeper）在分区时会拒绝写入，压测需关注可用性降级；AP 系统（如 Cassandra）则可能返回旧数据，压测需关注最终一致性的收敛时间。

2.2 BASE 理论：最终一致性的实践哲学

BASE 理论是对 CAP 中 AP 路线的延伸，由 eBay 架构师 Dan Pritchett 提出。它强调系统在分区情况下优先保证可用性，通过“软状态”和“最终一致性”来弥补一致性缺口。

BA — Basically Available（基本可用）：系统允许出现部分功能降级，但核心服务保持可用。
S — Soft State（软状态）：允许数据存在中间状态，不要求时刻强一致。
E — Eventually Consistent（最终一致性）：经过一段时间后，所有副本数据最终达到一致。

  压测映射： BASE 系统在压测中需要设计“异步对账”场景。压测脚本应在写入后等待一个可配置的窗口期（如 5 秒），再发起读取校验，以验证最终一致性是否在预期时间内收敛。

2.3 2PC（两阶段提交）协议

2PC 是分布式事务的经典协调协议，分为 准备阶段（Vote Phase） 和 提交阶段（Commit Phase）。它依赖一个全局协调者（Coordinator）来驱动所有参与者（Participants）完成事务。

阶段	协调者动作	参与者动作	可能的结果
Phase 1：准备	发送 prepare 请求，等待所有参与者响应	执行本地事务（写 undo/redo 日志），返回 Yes/No	全部 Yes → 进入 Phase 2；任一 No → 全局回滚
Phase 2：提交	根据 Phase 1 结果发送 commit 或 rollback 指令	收到 commit 后提交本地事务；收到 rollback 后回滚	全部提交成功 → 事务完成；部分失败 → 需补偿

2PC 的致命缺陷： 协调者是单点故障；Phase 2 期间参与者处于阻塞状态，锁资源无法释放；如果协调者在 Phase 2 崩溃，参与者将无法确定是提交还是回滚，导致数据不一致。这些正是压测中需要重点模拟的故障场景。

2.4 3PC（三阶段提交）协议

3PC 是 2PC 的改进版本，引入 超时机制 和 预提交（Pre-commit） 阶段，降低阻塞范围。它将 2PC 的 Phase 1 拆分为 CanCommit 和 PreCommit 两个阶段。

CanCommit（询问阶段）：协调者询问所有参与者是否具备提交条件，参与者仅做可行性检查，不锁定资源。
PreCommit（预提交阶段）：协调者收到全部 Yes 后，发送 preCommit 指令；参与者执行本地事务并写日志，但暂不提交。
DoCommit（提交阶段）：协调者确认所有参与者 preCommit 成功后，发送 doCommit 指令；参与者正式提交事务。

3PC 引入了参与者的超时机制：如果参与者在 PreCommit 后未收到 doCommit，会在超时后自动提交，从而避免 2PC 中的无限阻塞。但 3PC 仍无法完全解决网络分区下的数据一致性问题。

2.5 TCC 模式（Try-Confirm-Cancel）

TCC 是一种业务层面的补偿型分布式事务方案，将每个服务接口拆分为三个操作：Try（预留资源）、Confirm（确认执行）、Cancel（取消回滚）。它不依赖数据库的 XA 协议，性能优于 2PC。

操作	业务含义	成功条件	失败处理
Try	检查并预留业务资源（如冻结库存、锁定账户余额）	所有参与者 Try 成功	任一 Try 失败 → 全局 Cancel
Confirm	真正执行业务操作（扣减库存、转账扣款）	所有参与者 Confirm 成功	Confirm 失败 → 重试或人工介入
Cancel	释放 Try 阶段预留的资源（解冻库存、退回余额）	所有参与者 Cancel 成功	Cancel 失败 → 重试直到成功

  压测设计要点： TCC 的压测必须覆盖“Try 成功但 Confirm 超时”和“Cancel 幂等性”两类场景。建议在压测脚本中注入 Confirm 阶段的随机延迟，观察 Cancel 补偿链路是否能够正确触发并保持幂等。

2.6 Saga 模式

Saga 模式是一种长事务解决方案，将一个分布式事务拆分为一系列本地事务，每个本地事务对应一个 补偿事务（Compensation）。Saga 有两种编排方式：

Choreography（编排）：每个服务在完成本地事务后，通过事件驱动触发下一个服务。无中心协调者，耦合度较高。
Orchestration（编排器）：由一个 Saga 编排器（Orchestrator）集中管理事务流程，编排器负责调用各服务并处理补偿逻辑。

Saga 不要求“立即一致性”，只保证最终一致性。如果某个本地事务失败，Saga 会反向执行所有已成功事务的补偿操作。

压测陷阱： Saga 的补偿操作必须具有幂等性。在压测中，如果补偿操作因网络抖动被重复执行，必须确保不会产生重复退款、重复解冻等副作用。建议在压测脚本中为每个补偿操作添加去重标识（Idempotency Key）。

2.7 核心概念对比总结

方案	一致性级别	资源锁定	协调者	适用场景	压测重点
2PC	强一致性	是（阻塞）	有	短事务、低并发	协调者故障、参与者超时
3PC	强一致性（弱于 2PC）	部分（预提交）	有	对可用性要求稍高的场景	网络分区、超时自动提交
TCC	最终一致性	是（业务预留）	有	高并发、短事务	Confirm 超时、Cancel 幂等
Saga	最终一致性	否	可选	长事务、跨服务	补偿链路、幂等性、事件丢失