1. 分布式事务基础
1.1 分布式事务概念
分布式事务是指参与事务的多个操作分布在不同的网络节点（服务、数据库、消息队列等）上，但仍需保证这些操作满足 ACID 特性（原子性、一致性、隔离性、持久性）的事务处理模型。在微服务架构与 gRPC 接口调用场景中，一次业务请求往往需要跨多个服务完成数据变更，分布式事务成为保障数据一致性的核心机制。
核心场景：用户下单操作涉及订单服务、库存服务、账户服务、物流服务，每个服务独立部署且拥有独立数据库，一次下单成功需要所有服务协同提交或全部回滚。
1.2 CAP 定理
CAP 定理由 Eric Brewer 在 2000 年提出，是分布式系统设计的基石。定理指出：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两项。
| 特性 | 定义 | 说明 |
|---|---|---|
| C（一致性） | 所有节点在同一时刻看到相同的数据 | 写操作完成后，任何后续读操作都能读到最新值 |
| A（可用性） | 每个请求都能获得非错误的响应 | 系统始终对外提供服务，不拒绝请求 |
| P（分区容错性） | 系统在网络分区时仍能正常运行 | 节点间通信中断时，系统仍可继续工作 |
在实际分布式系统中，网络分区是不可避免的，因此必须在 CP 和 AP 之间做出权衡：
- CP 系统：优先保证一致性和分区容错性，牺牲可用性。典型场景：分布式数据库（ZooKeeper、etcd）。
- AP 系统：优先保证可用性和分区容错性，牺牲一致性。典型场景：DNS、CDN、社交动态流。
1.3 BASE 理论
BASE 理论是 CAP 定理在 AP 方向的延伸，由 eBay 架构师 Dan Pritchett 提出。它强调在分布式系统中通过牺牲强一致性来换取可用性和性能，最终达到最终一致性。
| 缩写 | 全称 | 核心含义 |
|---|---|---|
| BA | Basically Available（基本可用） | 系统允许出现部分功能降级，但核心服务始终可用 |
| S | Soft State（软状态） | 允许系统中间状态存在，不要求时刻强一致 |
| E | Eventually Consistent（最终一致性） | 经过一段时间后，所有副本数据最终达到一致 |
实践启示：在 gRPC 接口压测场景中，BASE 理论指导我们设计异步补偿机制和状态校验策略，而非追求每个 RPC 调用的实时强一致。
1.4 分布式事务的挑战
在 gRPC 接口压测场景库中，分布式事务面临以下核心挑战，直接影响压测模型的设计与结果分析：
- 网络不确定性：gRPC 调用依赖 HTTP/2 长连接，网络延迟、丢包、分区会导致事务超时或状态未知。
- 事务协调开销：两阶段提交（2PC）等协议需要协调者与参与者多次交互，增加响应时间和失败概率。
- 数据一致性保障：在并发压测下，脏读、不可重复读、幻读等问题被放大，需要幂等设计和补偿事务。
- 性能瓶颈：分布式事务锁机制和日志同步会显著降低吞吐量，压测时需要精确测量事务成功率与延迟分布。
- 故障恢复复杂度：节点宕机、消息丢失、日志不一致等场景的恢复逻辑难以在压测中完整模拟。
压测注意：在 gRPC 接口压测中，分布式事务的超时设置、重试策略和幂等校验是三个最容易出错的环节。建议在场景库中单独设计“网络分区+事务超时”组合用例，以验证系统的容错边界。