4. 分布式事务协议：2PC、3PC、TCC 与 Saga 模式
在分布式系统中，跨多个节点、多个服务的数据一致性是核心挑战。分布式事务协议通过协调参与者（Participant）与协调者（Coordinator）之间的交互，在可用性与一致性之间做出权衡。本章深入剖析四种主流协议：两阶段提交（2PC）、三阶段提交（3PC）、TCC 模式与 Saga 模式，并对比其适用场景与压测关注点。
4.1 两阶段提交（2PC）
2PC 是最经典的强一致性分布式事务协议，分为投票阶段（Voting Phase）和提交阶段（Commit Phase）。协调者向所有参与者发送 prepare 请求，参与者执行本地事务但不提交，返回 Yes/No；若全部返回 Yes，协调者发送 commit，否则发送 abort。
压测关注点：2PC 在投票阶段会锁定资源（如数据库行锁），高并发下锁等待时间急剧上升，容易导致事务超时和死锁。压测时需重点监控协调者单点瓶颈与参与者锁持有时间。
| 维度 | 说明 |
|---|---|
| 一致性 | 强一致性，所有节点要么全部提交，要么全部回滚 |
| 可用性 | 协调者为单点，宕机后参与者阻塞等待，系统不可用 |
| 性能 | 同步阻塞，资源锁定时间长，高并发下吞吐量低 |
| 适用场景 | 短事务、低并发、对一致性要求极高的场景（如银行转账） |
4.2 三阶段提交（3PC）
3PC 在 2PC 基础上引入超时机制和预提交阶段（PreCommit），将投票阶段拆分为 CanCommit 和 PreCommit，降低阻塞范围。协调者超时后自动 abort，参与者超时后自动 commit（避免无限等待）。
压测提示：3PC 减少了阻塞时间，但引入了“参与者超时自动提交”的风险——若网络分区导致参与者误判，可能破坏一致性。压测时需注入网络延迟和分区故障，验证超时阈值设置是否合理。
4.3 TCC 模式
TCC（Try-Confirm-Cancel）是一种补偿型柔性事务模式，将每个服务操作拆分为三个阶段：Try（预留资源）、Confirm（确认执行）、Cancel（取消释放）。业务方需自行实现幂等和补偿逻辑。
- Try：检查并预留业务资源（如冻结库存、锁定账户余额）。
- Confirm：真正执行业务操作，使用 Try 阶段预留的资源。
- Cancel：释放 Try 阶段预留的资源，回滚业务。
压测陷阱：TCC 的 Cancel 操作必须幂等且高效。压测时若 Cancel 逻辑存在 bug（如重复释放资源），会导致数据不一致。建议在压测脚本中模拟 Try 成功但 Confirm 超时的场景，验证 Cancel 的幂等性。
| 维度 | 2PC | TCC |
|---|---|---|
| 资源锁定 | 数据库行锁/表锁，粒度粗 | 业务预留，粒度细（如冻结字段） |
| 一致性 | 强一致性 | 最终一致性 |
| 性能 | 低（锁等待） | 高（无长锁） |
| 业务侵入 | 低（对业务透明） | 高（需实现 Try/Confirm/Cancel） |
| 适用场景 | 短事务、低并发 | 长事务、高并发、跨服务 |
4.4 Saga 模式
Saga 模式将长事务拆分为一系列本地事务，每个本地事务对应一个补偿事务。Saga 有两种执行方式：Choreography（编排）和Orchestration（编排器）。任一本地事务失败，则按逆序依次触发补偿事务。
压测策略：Saga 的补偿链长度直接影响恢复时间。压测时需构造“第 N 步失败”的场景，测量补偿事务的完整执行时间与资源释放效率。对于编排模式，还需关注事件总线的消息积压。
4.5 四种协议对比总结
| 协议 | 一致性 | 资源锁定 | 阻塞 | 业务侵入 | 典型场景 |
|---|---|---|---|---|---|
| 2PC | 强一致性 | 数据库锁 | 同步阻塞 | 低 | 银行转账、账户扣款 |
| 3PC | 强一致性（有风险） | 数据库锁 | 超时降级 | 低 | 对可用性有要求的强一致场景 |
| TCC | 最终一致性 | 业务预留 | 无阻塞 | 高 | 高并发、跨服务、长事务 |
| Saga | 最终一致性 | 无锁 | 无阻塞 | 中 | 微服务编排、事件驱动 |
压测选型建议：若压测目标为高吞吐、低延迟，优先选择 TCC 或 Saga；若压测目标为数据强一致性验证，选择 2PC 并重点测试协调者容错与锁超时。3PC 在实际生产中使用较少，压测时需特别关注超时参数对一致性的影响。