1. 分布式事务概述：CAP理论、BASE理论、分布式事务的挑战与场景
1.1 从单机事务到分布式事务
在单体应用时代，事务由数据库的 ACID 特性保障：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。然而，当系统拆分为多个微服务、数据分散到不同数据库实例后，单机事务的本地锁和日志机制无法跨网络协调。分布式事务应运而生，它是一组跨多个独立节点（服务、数据库、消息队列）的操作，要么全部成功提交，要么全部回滚，从而保证全局数据一致性。
核心矛盾： 分布式系统无法同时满足一致性、可用性和分区容错性，这是 CAP 定理的核心结论，也是分布式事务设计的根本约束。
1.2 CAP 理论：分布式系统的“不可能三角”
CAP 理论由 Eric Brewer 在 2000 年提出，描述了分布式系统在以下三个属性之间的权衡：
| 属性 | 英文 | 说明 |
|---|---|---|
| C — 一致性 | Consistency | 所有节点在同一时刻看到的数据完全相同。写操作完成后，任何后续读操作都能读到最新值。 |
| A — 可用性 | Availability | 每个请求都能获得一个（非错误的）响应，但不保证响应包含最新数据。 |
| P — 分区容错性 | Partition Tolerance | 系统在网络分区（节点间通信中断）时仍能继续运行。 |
定理核心： 在分布式系统中，P（分区容错性）是必须满足的，因为网络分区是不可避免的。因此，设计者只能在 CP（强一致性 + 分区容错） 和 AP（高可用 + 分区容错） 之间做出选择。
- CP 系统： 优先保证一致性，牺牲部分可用性。例如：ZooKeeper、etcd。当发生分区时，非多数派节点停止服务。
- AP 系统： 优先保证可用性，牺牲强一致性，允许最终一致。例如：Eureka、Cassandra。分区时所有节点继续响应，但数据可能不一致。
1.3 BASE 理论：AP 系统的实践哲学
BASE 理论是 CAP 理论中 AP 侧的具体延伸，由 eBay 架构师 Dan Pritchett 提出。它强调系统在无法保证强一致性时，通过牺牲即时一致性来换取高可用性，最终达到数据一致。
| 缩写 | 全称 | 含义 |
|---|---|---|
| BA | Basically Available | 基本可用。系统允许出现部分功能降级，但核心服务始终可用。 |
| S | Soft State | 软状态。允许系统在不同时刻存在中间状态，不要求强一致。 |
| E | Eventually Consistent | 最终一致性。经过一段时间后，所有副本数据最终达到一致。 |
实践启示： 在 Go 微服务架构中，BASE 理论指导我们使用异步消息、补偿事务（Saga）、本地消息表等模式，在保证可用性的前提下，通过重试和幂等设计实现最终一致。
1.4 分布式事务面临的核心挑战
相比单机事务，分布式事务在以下四个维度面临严峻挑战：
- 网络不可靠： 消息延迟、丢包、乱序、分区。事务协调者与参与者之间的通信随时可能中断。
- 节点故障： 任意参与者可能崩溃、重启或磁盘损坏，导致事务状态丢失。
- 时钟不一致： 不同机器的物理时钟存在偏差，难以精确判断事件先后顺序，影响超时和锁机制。
- 状态协调复杂： 两阶段提交（2PC）存在同步阻塞和协调者单点问题；三阶段提交（3PC）引入超时机制但增加了协议复杂度。
避坑提醒： 不要试图用分布式事务解决所有一致性问题。对于非关键数据（如用户浏览记录、日志），优先采用最终一致方案；对于资金、库存等强一致场景，务必设计幂等接口和补偿回滚逻辑。
1.5 典型应用场景
分布式事务并非适用于所有场景，以下三类场景是它的主要战场：
| 场景 | 示例 | 推荐方案 |
|---|---|---|
| 跨库转账 | 用户 A 在银行 X 扣款，用户 B 在银行 Y 入账 | TCC（Try-Confirm-Cancel）或 Saga |
| 订单与库存 | 下单扣库存、支付减余额、物流创建运单 | 本地消息表 + 消息队列 + 最终补偿 |
| 多服务写操作 | 用户注册同时创建账户、初始化积分、发送欢迎邮件 | Saga 编排模式 |
1.6 本章小结
- CAP 理论 揭示了分布式系统必须在一致性、可用性、分区容错性中三选二，而 P 是必选项。
- BASE 理论 为 AP 系统提供了“基本可用 + 软状态 + 最终一致”的实践路径。
- 分布式事务面临 网络不可靠、节点故障、时钟偏差、状态协调复杂 四大挑战。
- 典型场景包括 跨库转账、订单库存联动、多服务写操作，需根据业务一致性要求选择 TCC、Saga 或消息表方案。