1. 分布式事务基础：概念、理论与协议
1.1 分布式事务核心概念
分布式事务是指参与事务的多个节点分布在不同的网络进程或物理机器上，但仍需保证所有节点上的数据操作满足 ACID（原子性、一致性、隔离性、持久性）特性。在微服务与 gRPC 架构中，一次业务请求往往跨越多个服务，每个服务维护自己的数据库，传统的本地数据库事务无法跨服务边界生效，因此需要引入分布式事务协调机制。
关键术语：
- 全局事务（Global Transaction）：由协调者发起的跨多个参与者的原子操作单元。
- 分支事务（Branch Transaction）：每个参与者本地执行的事务片段。
- 协调者（Coordinator）：负责调度所有参与者，决定全局提交或回滚。
- 参与者（Participant）：执行本地事务并响应协调者指令的节点。
1.2 CAP 理论
CAP 理论是分布式系统的基石，由 Eric Brewer 提出。它指出一个分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 全称 | 说明 |
|---|---|---|
| C | Consistency（一致性） | 所有节点在同一时刻看到相同的数据副本 |
| A | Availability（可用性） | 每个请求都能获得非错误的响应，但不保证数据最新 |
| P | Partition Tolerance（分区容错性） | 系统在网络分区（节点间通信中断）时仍能正常运行 |
实际取舍： 在分布式环境中，网络分区是不可避免的，因此 P 必须保证。实际设计是在 CP（放弃可用性）与 AP（放弃强一致性）之间做选择。例如，ZooKeeper 选择 CP，Eureka 选择 AP。
1.3 BASE 理论
BASE 理论是对 CAP 中 AP 方案的延伸，由 eBay 架构师 Dan Pritchett 提出。它强调系统在分区期间放弃强一致性，但保证最终一致性。
| 缩写 | 全称 | 含义 |
|---|---|---|
| BA | Basically Available（基本可用） | 系统允许部分功能降级，但核心服务仍可用 |
| S | Soft State（软状态） | 允许数据副本存在中间状态，不要求实时一致 |
| E | Eventually Consistent（最终一致） | 经过一段时间后，所有副本数据最终达到一致 |
与 ACID 的对比： ACID 追求强一致性，适用于本地事务；BASE 追求最终一致性，适用于跨服务的分布式场景。在 gRPC 分布式事务压测中，BASE 模型更常见，因为网络延迟和部分失败是常态。
1.4 两阶段提交（2PC）
2PC 是经典的分布式事务协议，由一个协调者和多个参与者组成。整个过程分为两个阶段：
- 准备阶段（Vote Phase）：协调者向所有参与者发送 prepare 请求，参与者执行本地事务但不提交，返回 Yes（准备成功）或 No（准备失败）。
- 提交阶段（Commit Phase）：如果所有参与者都返回 Yes，协调者发送 commit 指令，参与者提交事务；如果有任一参与者返回 No 或超时，协调者发送 abort 指令，参与者回滚事务。
2PC 的优缺点：
- 优点： 原理简单，强一致性，多数数据库和消息队列原生支持。
- 缺点： 同步阻塞（参与者等待协调者指令期间锁定资源）；单点故障（协调者宕机可能导致事务悬挂）；数据不一致（第二阶段部分参与者提交成功、部分失败）。
1.5 三阶段提交（3PC）
3PC 是 2PC 的改进版本，引入超时机制和额外的预提交阶段，减少阻塞时间。三个阶段如下：
| 阶段 | 名称 | 动作 | 超时处理 |
|---|---|---|---|
| 1 | CanCommit（询问） | 协调者询问参与者是否可以提交，参与者返回 Yes/No | 参与者超时自动中止 |
| 2 | PreCommit（预提交） | 协调者发送预提交指令，参与者执行事务但不提交，返回 ACK | 参与者超时自动提交（避免长时间阻塞） |
| 3 | DoCommit（正式提交） | 协调者发送正式提交指令，参与者提交事务 | 参与者超时自动提交（降低数据不一致风险） |
2PC vs 3PC 对比：
- 3PC 引入超时机制，参与者不再无限等待协调者，降低了阻塞时间。
- 3PC 增加 PreCommit 阶段，让参与者提前锁定资源并确认状态，减少第二阶段失败的概率。
- 3PC 的代价是增加了一次网络交互，性能略低于 2PC，且仍无法完全解决数据不一致问题（例如协调者在 PreCommit 后宕机，参与者超时自动提交可能导致部分节点提交、部分节点回滚）。
1.6 小结：分布式事务协议选型参考
| 协议 | 一致性级别 | 阻塞情况 | 网络开销 | 适用场景 |
|---|---|---|---|---|
| 2PC | 强一致性 | 同步阻塞 | 2 轮 RTT | 对一致性要求极高、参与者较少、网络稳定的场景 |
| 3PC | 强一致性（弱于 2PC） | 较少阻塞（超时机制） | 3 轮 RTT | 需要减少阻塞、能接受略低一致性的场景 |
| TCC（后续章节展开） | 最终一致性 | 无阻塞 | 2~3 轮 RTT | 高并发、长事务、需要业务补偿的场景 |
| Saga（后续章节展开） | 最终一致性 | 无阻塞 | N 轮 RTT | 长流程、异步、允许补偿的微服务场景 |
压测视角提示： 在 gRPC 分布式事务压测中，2PC 和 3PC 的阻塞特性会直接影响吞吐量和延迟分布。如果压测发现事务成功率低或响应时间抖动剧烈，应优先检查协调者是否成为瓶颈、参与者是否因资源锁定导致死锁、以及网络分区是否触发了超时回滚。后续章节将结合 gRPC 接口调用日志和分布式追踪数据，演示具体的故障排查方法。