分布式事务实战全景：从两阶段提交到Saga模式的工程决策

引言

在分布式系统中，事务的跨服务一致性是永恒的技术难题。从单体应用的 ACID 事务到微服务架构下的分布式事务，如何在数据一致性、系统可用性和性能之间找到平衡点，一直是架构师和工程师面临的核心挑战。本文将系统梳理分布式事务的演进历程：从经典的两阶段提交（2PC）到 compensatory 的 Saga 模式，从事务消息到 TCC 协议，结合具体代码示例和生产级实践经验，为你构建完整的分布式事务技术全景。

一、分布式事务的本质挑战

当业务操作需要跨多个独立的数据存储系统或微服务时，传统单机事务的 ACID 特性无法直接延伸。分布式事务面临的核心挑战包括：

• 网络不可靠性：节点间通信存在延迟、超时、丢包等风险，任何一次 RPC 失败都可能导致事务状态不一致
• 部分失败：参与者节点可能成功提交后宕机，或在准备阶段完成后无法收到协调者的最终指令
• 时钟偏移：不同节点的本地时钟存在偏差，导致基于时间戳的全局排序不可靠
• 性能约束：强一致性协议往往意味着更高的延迟和更低的吞吐量

二、两阶段提交（2PC）：经典但脆弱的基石

两阶段提交是分布式事务最经典的协议，由协调者（Coordinator）和多个参与者（Participant）组成，将事务提交过程拆分为投票和提交两个阶段。

2.1 协议流程

阶段一（Prepare/Voting）：协调者向所有参与者发送 Prepare 请求，各参与者执行本地事务但不提交（写入 undo/redo log），然后回复 Yes 或 No。

阶段二（Commit/Abort）：如果所有参与者回复 Yes，协调者发送 Commit 指令；否则发送 Abort 指令。参与者在收到指令后执行正式提交或回滚。

2.2 存在的问题

• 同步阻塞：参与者在 Prepare 后持有全局锁等待协调者指令，长时间阻塞导致连接池耗尽
• 协调者单点故障：如果协调者在阶段二崩溃，参与者将无法获知最终决策，持有锁的资源会一直阻塞
• 脑裂风险：网络分区时，部分参与者超时后自行决策可能与已提交的参与者不一致
• 性能瓶颈：两轮 RPC 交互加上额外的日志刷盘，延迟通常为单事务的 2-3 倍

2.3 代码示例：2PC 简化实现

// 协调者核心逻辑
pub struct TwoPhaseCoordinator {
    participants: Vec