1. 分布式事务概述
1.1 分布式事务的定义
分布式事务是指参与事务的多个操作分布在不同的网络节点（服务、数据库、消息队列等）上，但仍需保证这些操作满足 ACID 特性（原子性、一致性、隔离性、持久性）的事务处理机制。在单体架构中，事务由本地数据库引擎通过锁和日志机制完成；在分布式架构中，事务跨越进程边界，需要引入协调协议来达成全局一致。
核心矛盾：分布式事务的本质是在不可靠的网络和可能故障的节点上，模拟出“要么全部成功，要么全部回滚”的原子效果。
1.2 CAP 定理与 BASE 理论
理解分布式事务必须从 CAP 定理出发。CAP 定理由 Eric Brewer 于 2000 年提出，指出分布式系统最多同时满足以下三个特性中的两个：
| 特性 | 全称 | 说明 |
|---|---|---|
| C | Consistency（一致性） | 所有节点在同一时刻看到相同的数据；写操作完成后，后续读操作必须返回最新值。 |
| A | Availability（可用性） | 每个请求都能获得非错误的响应，但不保证返回最新数据。 |
| P | Partition Tolerance（分区容错性） | 系统在网络分区（节点间通信中断）时仍能正常运行。 |
由于网络分区在分布式系统中是必然发生的，因此实际设计时必须在 C 和 A 之间做出权衡：
- CP 系统：优先保证一致性，分区发生时牺牲可用性（如 Zookeeper、Etcd）。
- AP 系统：优先保证可用性，分区发生时牺牲强一致性（如 Eureka、Cassandra）。
BASE 理论是对 CAP 中 AP 路线的实践总结，由 eBay 架构师 Dan Pritchett 提出：
| 缩写 | 全称 | 含义 |
|---|---|---|
| BA | Basically Available（基本可用） | 系统允许出现部分功能降级，但核心服务保持可用。 |
| S | Soft State（软状态） | 允许数据存在中间状态，不要求强一致性。 |
| E | Eventually Consistent（最终一致性） | 经过一段时间后，所有副本数据最终达到一致状态。 |
实践启示：BASE 理论是 Saga 模式的理论基础。Saga 放弃强一致性，采用最终一致性 + 补偿回滚的设计，正是 BASE 思想在事务领域的落地。
1.3 分布式事务的挑战
在微服务和云原生架构中，分布式事务面临以下核心挑战：
- 网络不可靠：请求可能丢失、延迟或重复，导致事务状态不确定。
- 节点故障：参与事务的任意服务可能崩溃，需要故障恢复机制。
- 数据一致性：跨服务的数据更新需要保证不出现脏读、幻读或永久不一致。
- 性能开销：分布式协调协议（如 2PC/3PC）引入额外的网络往返和锁等待。
- 调试与追踪：事务链路跨越多个服务，问题定位和日志关联困难。
常见误区：不要试图在所有场景下都使用强一致性分布式事务。根据业务特性选择 Saga（最终一致）、TCC（补偿型）或 2PC（强一致）才是架构师的核心能力。
1.4 典型应用场景
分布式事务并非所有系统都需要，以下场景是典型的高频需求：
| 场景 | 业务示例 | 推荐模式 |
|---|---|---|
| 电商下单 | 创建订单 → 扣减库存 → 扣减账户余额 → 生成物流单 | Saga / TCC |
| 金融转账 | 扣减转出账户 → 增加转入账户 → 记录流水 | 2PC / Saga |
| 预订系统 | 预订酒店 → 预订机票 → 预订租车 | Saga（长事务） |
| 数据同步 | 主库写入 → 同步到多个从库或异构存储 | 最终一致性 + 补偿 |
| 跨服务编排 | 用户注册 → 创建账户 → 发送欢迎邮件 → 初始化推荐系统 | Saga / 事件驱动 |
1.5 分布式事务模式对比
业界主流分布式事务模式包括 2PC、TCC、Saga 和本地消息表。下表从关键维度进行对比：
| 模式 | 一致性 | 隔离性 | 性能 | 复杂度 | 适用场景 |
|---|---|---|---|---|---|
| 2PC | 强一致 | 高（锁资源） | 低（同步阻塞） | 中 | 短事务、低并发、金融核心 |
| TCC | 强一致 | 中（业务锁） | 中 | 高 | 短事务、高并发、需自定义隔离 |
| Saga | 最终一致 | 低（无锁） | 高 | 中 | 长事务、高可用、微服务编排 |
| 本地消息表 | 最终一致 | 低 | 高 | 低 | 异步解耦、消息驱动 |
课程定位：本课程聚焦 Saga 模式，因为它最适合微服务架构下的长事务场景，且与事件风暴（Event Storming）结合能高效完成分布式事务的建模与画布设计。