3. 本地事务与全局事务：实现原理与协议对比
在分布式系统的事务边界治理中，本地事务与全局事务是两种最基础的原子性保障模型。本地事务局限于单一资源管理器（如单个数据库），而全局事务跨越多个资源管理器，需要协调者统一调度。理解两者的实现原理、协议细节及性能差异，是设计API事务边界的前提。
3.1 本地事务实现原理
本地事务（Local Transaction）由单一数据库或消息队列内部的事务引擎管理，遵循ACID特性。其核心实现依赖日志（WAL）与锁机制。
3.1.1 核心流程
- 事务开始：应用向数据库发送
BEGIN或START TRANSACTION指令，事务管理器分配唯一事务ID（XID）。 - 操作执行：所有数据修改先写入重做日志（Redo Log）和撤销日志（Undo Log），再修改内存中的数据页。
- 提交（Commit）：将Redo Log强制刷盘（fsync），标记事务状态为“已提交”，释放锁资源。
- 回滚（Rollback）：利用Undo Log将数据页恢复到事务开始前的状态。
关键指标：本地事务的提交延迟主要取决于单次fsync耗时（通常2~10ms），吞吐量受限于磁盘IOPS。在单库场景下，本地事务是最高效的原子性方案。
3.1.2 本地事务的局限性
| 维度 | 说明 |
|---|---|
| 资源范围 | 仅能保证单一数据库或消息队列内的原子性 |
| 跨库操作 | 无法协调多个数据库、缓存、MQ之间的数据一致性 |
| 故障恢复 | 崩溃恢复依赖本地日志，无法感知其他参与者的状态 |
3.2 全局事务（XA）协议
全局事务（Global Transaction）由事务协调者（Transaction Coordinator, TC）统一管理多个资源管理器（Resource Manager, RM）的原子提交。XA规范（X/Open Distributed Transaction Processing）定义了TC与RM之间的标准接口。
3.2.1 XA接口核心方法
| 方法 | 方向 | 作用 |
|---|---|---|
xa_start |
TC → RM | 关联事务分支与全局事务ID |
xa_end |
TC → RM | 结束事务分支的操作阶段 |
xa_prepare |
TC → RM | 准备提交，RM记录准备状态并返回就绪 |
xa_commit |
TC → RM | 提交事务分支 |
xa_rollback |
TC → RM | 回滚事务分支 |
xa_recover |
TC → RM | 获取RM中处于准备状态但未完成的事务列表 |
3.3 两阶段提交（2PC）协议
两阶段提交（Two-Phase Commit, 2PC）是实现XA全局事务最经典的协议。它将提交过程拆分为准备阶段和提交阶段，确保所有参与者要么全部提交，要么全部回滚。
3.3.1 2PC流程详解
3.3.2 2PC的优缺点分析
| 维度 | 优点 | 缺点 |
|---|---|---|
| 原子性 | 严格保证所有参与者要么全部提交，要么全部回滚 | 协调者单点故障会导致事务阻塞 |
| 一致性 | 所有RM在提交前达成一致，数据状态确定 | 准备阶段锁定资源，并发性能下降 |
| 隔离性 | 准备阶段后，其他事务无法修改已锁定数据 | 锁持有时间从准备到提交完成，长事务风险高 |
| 持久性 | 准备阶段日志落盘，崩溃后可恢复 | 协调者崩溃后，参与者需阻塞等待恢复 |
| 性能 | 协议简单，实现成熟 | 至少2次RTT + 2次fsync，延迟高 |
3.4 本地事务与全局事务对比
| 对比维度 | 本地事务 | 全局事务（XA + 2PC） |
|---|---|---|
| 资源范围 | 单一RM | 多个RM（数据库、MQ、缓存等） |
| 协调者 | 无（由RM内部管理） | 需要独立的TC或嵌入应用 |
| 提交延迟 | 1次fsync | 至少2次fsync + 网络RTT |
| 锁持有时间 | 短（提交即释放） | 长（准备阶段到提交完成） |
| 吞吐量 | 高（单库TPS可达万级） | 低（受限于协调者与网络） |
| 故障恢复 | 自动恢复（基于本地日志） | 需人工或补偿事务介入 |
| 适用场景 | 单体应用、单库操作 | 跨库转账、分布式订单、强一致性要求 |
实践警示：2PC在微服务架构中容易成为性能瓶颈。当参与者数量超过3个时，事务成功率随参与者数量指数下降（每个参与者故障概率叠加）。建议仅在核心链路且参与者少于5个的场景下使用XA全局事务。
3.5 2PC的阻塞问题与优化方向
2PC最严重的缺陷是阻塞（Blocking）：当协调者崩溃时，所有处于准备状态的参与者必须持有锁并等待协调者恢复。这种阻塞可能持续数分钟甚至数小时，导致系统大面积不可用。
3.5.1 常见优化策略
- 超时与重试：参与者设置准备超时，超时后主动回滚并通知协调者。
- 三阶段提交（3PC）：引入“预提交”阶段，减少阻塞窗口，但无法完全消除。
- 补偿事务（Saga）：放弃全局锁，通过业务补偿实现最终一致性（后续章节详述）。
- 协调者高可用：使用选举机制（如ZooKeeper）实现TC主备切换。
3.5.2 2PC与3PC对比
| 特性 | 2PC | 3PC |
|---|---|---|
| 阶段数 | 2（准备 + 提交） | 3（准备 + 预提交 + 提交） |
| 阻塞风险 | 高（协调者崩溃后参与者阻塞） | 低（参与者超时可自行中止） |
| 网络开销 | 2次RTT | 3次RTT |
| 实现复杂度 | 低 | 中 |
| 工业应用 | 广泛（MySQL XA、Atomikos） | 较少（理论价值大于实践） |
选型建议：在API事务边界治理中，优先评估能否将跨库操作拆分为本地事务 + 异步补偿。若必须使用全局事务，建议将参与者数量控制在3个以内，并为协调者配置独立的故障恢复机制。