1. 分布式事务概述
1.1 分布式事务的定义
分布式事务是指参与事务的多个操作分布在不同的网络节点（服务、数据库、消息队列等）上，且这些操作必须作为一个整体执行单元，遵循 ACID（原子性、一致性、隔离性、持久性）原则。在单体架构中，事务由本地数据库引擎通过锁和日志机制保证；在分布式环境下，事务的协调需要跨网络、跨进程的协议来达成最终一致。
核心特征： 分布式事务 = 多个独立节点上的本地事务 + 全局协调协议。全局协调协议负责确保所有节点要么全部提交（Commit），要么全部回滚（Rollback）。
1.2 CAP 定理与 BASE 理论
CAP 定理
CAP 定理（由 Eric Brewer 提出）指出，一个分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 全称 | 说明 |
|---|---|---|
| C | 一致性（Consistency） | 所有节点在同一时刻看到相同的数据副本；写操作完成后，任何后续读操作都能读到最新值。 |
| A | 可用性（Availability） | 每个请求都能获得一个非错误的响应，但不保证响应包含最新数据。 |
| P | 分区容错性（Partition Tolerance） | 系统在网络分区（节点间通信中断）时仍能继续运行。 |
由于网络分区在分布式系统中是必然发生的，因此实际设计时必须在 CP（放弃可用性，保证一致性）和 AP（放弃强一致性，保证可用性）之间做出选择。传统关系型数据库的分布式事务（如 XA 协议）通常选择 CP；而互联网高并发场景下的微服务架构更倾向于 AP。
BASE 理论
BASE 理论是对 CAP 中 AP 方案的延伸，由 eBay 架构师 Dan Pritchett 提出，核心思想是放弃强一致性，允许系统在一段时间内处于不一致状态，但最终会达到一致。BASE 包含三个要素：
- BA（Basically Available） —— 基本可用：系统在出现故障时允许损失部分可用性，如响应时间延长或功能降级。
- S（Soft State） —— 软状态：允许系统在不同节点间存在中间状态，该状态不影响系统整体可用性。
- E（Eventually Consistent） —— 最终一致性：经过一段时间的异步同步后，所有副本最终会达到一致状态。
实践启示： 在 Go 微服务架构中，BASE 理论指导我们优先使用异步消息、本地消息表、TCC（Try-Confirm-Cancel）等柔性事务方案，而不是强依赖两阶段提交（2PC）这种刚性事务协议。
1.3 分布式事务的挑战
在分布式环境下实现事务，面临以下核心挑战：
| 挑战 | 描述 | 典型场景 |
|---|---|---|
| 网络不确定性 | 网络延迟、丢包、分区导致协调节点无法准确判断远端状态。 | 2PC 协调者等待参与者响应超时 |
| 节点故障 | 任意参与节点可能崩溃，导致事务悬挂或数据不一致。 | 订单服务写入成功，但库存服务宕机 |
| 数据一致性 | 跨库、跨服务的写操作难以保证原子性和隔离性。 | 支付扣款成功但订单状态未更新 |
| 性能开销 | 分布式事务协议（如 2PC/3PC）需要多次网络交互和锁资源。 | 高并发下数据库锁竞争导致吞吐量骤降 |
| 调试与追踪 | 事务链路跨越多个服务，问题定位和日志关联困难。 | 分布式事务回滚时部分补偿失败 |
1.4 典型应用场景
分布式事务并非所有场景都需要，以下场景是典型的高频需求：
- 电商下单：订单服务 + 库存服务 + 支付服务 + 积分服务，需要保证扣库存、扣款、生成订单、加积分全部成功或全部回滚。
- 跨行转账：A 银行扣款与 B 银行入账必须原子完成，涉及两个独立数据库系统。
- 微服务 Saga 编排：长业务流程（如旅行预订：机票 + 酒店 + 租车）中，每个步骤对应一个本地事务，失败时执行逆向补偿操作。
- 数据同步与迁移：将数据从旧系统迁移到新系统时，需要保证源端和目标端的数据最终一致。
避坑提示： 不要在所有跨服务调用中都引入分布式事务。对于非关键数据（如操作日志、用户浏览记录），使用最终一致性 + 幂等重试即可；只有涉及资金、库存、订单状态等核心资产时，才需要引入分布式事务协议。