4. 分布式事务基础：CAP定理、BASE理论、2PC/3PC协议、TCC模式、Saga模式概述
在分布式系统与微服务架构中，事务的原子性与一致性面临网络分区、节点故障等现实挑战。本章将系统梳理分布式事务的核心理论基础与主流实现模式，为后续在事件风暴画布中进行领域建模与架构落地奠定知识基石。
4.1 CAP定理：分布式系统的“不可能三角”
CAP定理由Eric Brewer于2000年提出，是分布式系统设计的根本约束。它指出：一个分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 全称 | 含义 | 典型场景 |
|---|---|---|---|
| C | Consistency（一致性） | 所有节点在同一时刻看到相同的数据副本 | 银行转账、库存扣减 |
| A | Availability（可用性） | 每个请求都能获得非错误的响应（不保证数据最新） | CDN缓存、商品浏览 |
| P | Partition Tolerance（分区容错性） | 系统在网络分区（节点间通信中断）时仍能正常运行 | 跨机房部署、微服务间网络抖动 |
关键认知： 在分布式系统中，网络分区是必然发生的，因此P是必须选择的。实际架构决策是在CP（强一致+分区容忍）与AP（高可用+分区容忍）之间权衡。
4.2 BASE理论：对强一致性的柔性妥协
BASE理论是AP架构的实践指导，由eBay架构师Dan Pritchett提出。它是对ACID强一致性模型的柔性替代，核心思想是：基本可用 + 软状态 + 最终一致性。
- BA（Basically Available）基本可用： 系统允许部分功能降级，但核心服务保持可用。例如：秒杀场景下，非核心服务（如历史订单查询）暂时不可用。
- S（Soft State）软状态： 允许系统存在中间状态，数据副本在一段时间内可以不一致。例如：订单状态为“支付中”，而非立即变为“已支付”。
- E（Eventually Consistent）最终一致性： 在没有新更新的前提下，经过足够长的时间，所有数据副本最终达到一致状态。
领域建模启示： 在事件风暴画布中，BASE理论指导我们使用“补偿事件”和“重试事件”来建模最终一致性流程，而非依赖强事务锁。
4.3 2PC/3PC协议：传统XA分布式事务
4.3.1 两阶段提交（2PC）
2PC是分布式事务的经典协议，引入协调者（Coordinator）和参与者（Participant）角色，分为两个阶段：
- 准备阶段（Vote Phase）： 协调者向所有参与者发送“准备”请求，参与者执行本地事务但不提交，返回Yes/No。
- 提交阶段（Commit Phase）： 如果所有参与者都返回Yes，协调者发送“提交”指令；否则发送“回滚”指令。
| 阶段 | 协调者动作 | 参与者动作 | 可能风险 |
|---|---|---|---|
| 准备阶段 | 发送prepare请求，等待所有参与者响应 | 执行本地事务，写undo/redo日志，返回Yes/No | 参与者锁定资源，阻塞时间长 |
| 提交阶段 | 根据收集结果，发送commit或rollback | 收到commit则提交，收到rollback则回滚 | 协调者单点故障时，参与者可能一直阻塞 |
2PC的致命缺陷： 同步阻塞 + 协调者单点故障。当协调者在提交阶段崩溃时，参与者无法确定是提交还是回滚，资源锁无法释放，导致系统不可用。
4.3.2 三阶段提交（3PC）
3PC在2PC基础上引入超时机制和预提交阶段，降低阻塞范围：
- CanCommit（询问阶段）： 协调者询问参与者是否具备提交条件，参与者返回Yes/No。此阶段不执行事务。
- PreCommit（预提交阶段）： 协调者发送预提交指令，参与者执行事务并写日志，但暂不提交。参与者引入超时，超时后自动中止。
- DoCommit（提交阶段）： 协调者发送最终提交或中止指令。参与者超时后默认提交（避免2PC的无限阻塞）。
4.4 TCC模式：业务层面的两阶段补偿
TCC（Try-Confirm-Cancel）是一种业务侵入性的分布式事务方案，由支付宝提出。它将每个服务接口拆分为三个操作：
| 阶段 | 操作 | 业务含义 | 示例（账户扣款） |
|---|---|---|---|
| Try | 预留资源 | 检查业务条件并锁定资源，不实际执行 | 冻结用户账户中的100元 |
| Confirm | 确认执行 | 真正执行业务操作，使用Try阶段预留的资源 | 将冻结的100元划转至商家账户 |
| Cancel | 取消回滚 | 释放Try阶段预留的资源 | 解冻用户账户中的100元 |
TCC核心优势： 无资源阻塞，性能优于2PC；业务逻辑可控，适合高并发场景。
TCC核心挑战： 业务侵入性强，每个服务需实现Try/Confirm/Cancel三个接口；Cancel操作必须支持幂等。
TCC核心挑战： 业务侵入性强，每个服务需实现Try/Confirm/Cancel三个接口；Cancel操作必须支持幂等。
4.5 Saga模式：基于事件驱动的长事务编排
Saga模式是一种最终一致性的分布式事务解决方案，通过将长事务拆分为一系列本地事务，并为每个本地事务定义补偿操作。Saga有两种编排方式：
- Choreography（编排/事件驱动）： 每个服务在完成本地事务后发布领域事件，触发下一个服务执行。无中心协调者。
- Orchestration（编排/协调器驱动）： 引入一个Saga协调器（Orchestrator），负责向各服务发送指令并处理补偿逻辑。
事件风暴画布中的Saga建模： 在Choreography模式下，每个服务完成本地事务后，在画布上产出“事件”（如 OrderCreated、PaymentCompleted），这些事件作为触发下一个聚合的“命令”。Orchestration模式则对应画布上的“决策命令”和“流程节点”。
4.6 分布式事务模式对比总结
| 模式 | 一致性模型 | 资源阻塞 | 业务侵入性 | 适用场景 | 典型代表 |
|---|---|---|---|---|---|
| 2PC | 强一致 | 高（锁定资源） | 低 | 短事务、低并发、传统数据库 | XA、JTA |
| 3PC | 强一致（有风险） | 中（超时释放） | 低 | 对2PC的改进，但较少使用 | Paxos Commit |
| TCC | 最终一致 | 低（预留资源） | 高 | 高并发、业务逻辑清晰的场景 | Seata TCC、Hmily |
| Saga | 最终一致 | 无 | 中 | 长事务、跨多个微服务、异步流程 | Axon、Eventuate、Seata Saga |
架构落地建议： 在事件风暴画布中，优先选择Saga模式（尤其是Choreography风格）来建模分布式事务，因为它与领域事件的天然契合度最高。对于核心资金链路，可考虑TCC模式以获取更强的资源控制。尽量避免使用2PC/3PC，除非遗留系统强制要求。