1. 分布式事务概述
1.1 分布式系统数据一致性问题
在单体架构中，事务通常依赖本地数据库的 ACID 特性，通过锁和日志保证数据一致性。当系统拆分为多个独立服务、数据分散存储在不同节点时，一次业务操作往往需要跨多个服务、多个数据库实例协同完成，由此引入了分布式数据一致性问题。
典型场景包括：
- 跨库转账：A 账户扣款与 B 账户入账不在同一数据库，无法依赖单库事务。
- 订单与库存：订单服务创建订单，库存服务扣减库存，两者必须原子完成。
- 支付与积分：支付成功同时增加用户积分，任一失败都需要回滚。
核心矛盾：分布式环境下，网络不可靠、节点可能宕机、时钟不同步，使得传统单机事务的原子性和隔离性难以直接迁移到分布式场景。
1.2 ACID 与 BASE 理论
ACID 是传统关系型数据库事务的基石，而 BASE 理论则面向分布式系统，在可用性和一致性之间做出权衡。
| 特性 | ACID（单机/强一致性） | BASE（分布式/最终一致性） |
|---|---|---|
| 原子性 (Atomicity) | 事务全部成功或全部回滚 | 基本可用 (Basically Available)：系统允许部分失败，但整体可用 |
| 一致性 (Consistency) | 事务前后数据满足所有约束 | 软状态 (Soft State)：允许中间状态存在，不要求时刻一致 |
| 隔离性 (Isolation) | 并发事务互不干扰 | 最终一致性 (Eventually Consistent)：经过一段时间后数据达到一致 |
| 持久性 (Durability) | 提交后数据永久保存 | （通常保留持久性要求） |
实践启示：在 gRPC 微服务架构中，强一致性场景（如支付、库存扣减）通常需要引入分布式事务协议（如 Saga、2PC）；而弱一致性场景（如用户通知、日志记录）可以接受 BASE 模型，通过异步补偿达到最终一致。
1.3 CAP 定理与 PACELC 权衡
CAP 定理（由 Eric Brewer 提出）指出，分布式系统在一致性 (Consistency)、可用性 (Availability)、分区容错性 (Partition Tolerance) 三者中最多只能同时满足两个。
- C (Consistency)：所有节点在同一时刻看到相同的数据。
- A (Availability)：每个请求都能获得一个（非错误的）响应。
- P (Partition Tolerance)：系统在网络分区（节点间通信中断）时仍能正常运行。
由于网络分区在分布式系统中不可避免，实际设计通常是在 CP 和 AP 之间做选择：
- CP 系统：发生分区时，牺牲可用性，等待数据一致后再提供服务（如 ZooKeeper、etcd）。
- AP 系统：发生分区时，继续提供服务，但可能返回不一致的数据，后续通过补偿达到最终一致（如 Cassandra、DynamoDB）。
PACELC 权衡是对 CAP 的扩展，进一步考虑了正常运行时的延迟与一致性取舍。PACELC 公式为：
If Partition (P) → 在 A 和 C 之间选择
Else (E) → 在 Latency (L) 和 Consistency (C) 之间选择
这意味着：
- 当发生网络分区时，系统遵循 CAP 定理，在可用性和一致性之间取舍。
- 当系统正常运行时（无分区），设计者需要在延迟 (Latency) 和一致性 (Consistency) 之间权衡：强一致通常引入额外同步开销，增加响应延迟；弱一致则能降低延迟，但可能返回旧数据。
gRPC 事务设计启示：在 gRPC 微服务调用链中，网络分区是常态而非异常。设计分布式事务时，必须明确每个业务场景在 PACELC 坐标系中的位置：核心资金链路通常选择 CP（强一致 + 可能降级），而非关键链路（如通知、日志）可以选择 AP（高可用 + 最终一致）。gRPC 的拦截器、超时重试和幂等机制是实现这些权衡的基础设施。