1. 分布式事务概述
1.1 分布式事务的定义
分布式事务是指参与事务的多个节点分布在不同的物理或逻辑进程中，通过网络通信协同完成一个原子性操作。在单体数据库中，事务由本地 ACID 机制保障；在分布式环境下，事务的原子性、一致性、隔离性和持久性需要跨节点协调，面临网络延迟、节点故障、数据分区等挑战。
核心特征：分布式事务 = 多个独立数据节点 + 全局原子提交 + 跨网络协调协议。
1.2 CAP 定理与 BASE 理论
CAP 定理
CAP 定理（Brewer 定理）指出，分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 全称 | 说明 |
|---|---|---|
| C | Consistency（一致性） | 所有节点在同一时刻看到相同的数据 |
| A | Availability（可用性） | 每个请求都能获得非错误的响应 |
| P | Partition Tolerance（分区容错性） | 系统在网络分区时仍能正常运行 |
在实际分布式系统中，网络分区是必然发生的，因此必须在 C 和 A 之间做出权衡：
- CP 系统：优先保证一致性，分区时牺牲可用性（如 Zookeeper、etcd）。
- AP 系统：优先保证可用性，分区时允许短暂不一致（如 Cassandra、DynamoDB）。
- CA 系统：在无分区时兼顾一致性和可用性，但无法容忍分区（理论存在，实际罕见）。
BASE 理论
BASE 理论是对 CAP 中 AP 方向的实践总结，由 eBay 架构师 Dan Pritchett 提出，核心思想是放弃强一致性，追求最终一致性：
| 缩写 | 全称 | 含义 |
|---|---|---|
| BA | Basically Available（基本可用） | 系统允许部分功能降级，但核心服务始终可用 |
| S | Soft State（软状态） | 允许数据存在中间状态，不要求实时一致 |
| E | Eventually Consistent（最终一致） | 经过一段时间后，所有副本数据最终达到一致 |
实践启示：分布式事务压测中，BASE 理论指导我们关注“最终一致性窗口”的长度和系统在软状态下的吞吐表现，而非追求严格的实时一致。
1.3 分布式事务的典型应用场景
分布式事务在以下场景中广泛使用，每个场景对一致性、性能和容错的要求各不相同：
- 跨库转账：银行 A 扣款 + 银行 B 入账，必须保证原子性，通常使用两阶段提交（2PC）。
- 订单与库存：下单扣库存、支付减余额、物流创建运单，涉及多个微服务的数据变更。
- 电商秒杀：高并发下扣减库存、生成订单、更新用户积分，要求高性能和最终一致性。
- 跨数据中心同步：主备数据中心之间的数据复制，需要保证数据不丢失且最终一致。
- SaaS 多租户计费：用户操作触发多个租户的计费记录更新，涉及跨分区事务。
压测关注点：不同场景对事务协议的选择差异很大。跨库转账适合 2PC/3PC 强一致协议；电商秒杀更适合 TCC 或 Saga 等柔性事务方案。压测时需要根据场景选择对应的 gRPC 通信模式和事务协调策略。
1.4 分布式事务与 gRPC 的关联
gRPC 作为高性能 RPC 框架，在分布式事务中承担以下关键角色：
- 事务协调通信：事务协调器与参与者之间通过 gRPC 双向流或 Unary 调用传递 Prepare、Commit、Rollback 指令。
- 状态上报：参与者通过 gRPC 流式 RPC 实时上报事务执行状态，支持超时重试和故障检测。
- 跨语言互操作：gRPC 的 Protobuf 序列化保证不同语言实现的微服务之间的事务消息格式一致。
- 压测可观测性：gRPC 内置的拦截器和 Tracing 机制可以精确记录每个事务阶段的延迟和错误率。
课程定位：本课程将围绕 gRPC 通信机制，设计分布式事务压测方案，验证不同事务协议（2PC、TCC、Saga）在 gRPC 环境下的性能边界和一致性保障能力。