分布式事务处理：从理论基础到工程实践

随着微服务架构的普及，单体应用中的数据一致性保障逐渐演变为跨服务、跨数据库的分布式事务难题。本教程将系统性地介绍分布式事务的核心概念、经典协议与主流解决方案，帮助你从零掌握 2PC、TCC 与最终一致性等关键技术。

什么是分布式事务

在分布式系统中，一个业务操作往往需要跨越多个独立的数据库或服务实例。分布式事务的目标是保证这些跨节点的操作要么全部成功，要么全部失败，使系统始终处于一致的状态。

与单机事务通过 ACID 特性保证一致性不同，分布式事务面临网络不可靠、节点故障、时钟偏差等挑战，无法完全照搬传统的强一致性方案。因此，工程实践中衍生出了不同级别的一致性保障模型。

分布式事务的理论基石

在深入具体方案之前，我们需要理解两个关键理论：CAP 定理与BASE 理论。

CAP 定理

CAP 定理指出，在一个分布式系统中，一致性、可用性与分区容错性三者不可兼得：

• 一致性：所有节点在同一时刻看到相同的数据。
• 可用性：每个请求都能获得非错误的响应，但不保证数据是最新的。
• 分区容错性：系统在遇到网络分区（节点间通信失败）时仍能正常运作。

由于网络分区在实际系统中不可避免，因此必须在 CP（强一致性）与 AP（高可用性）之间做出权衡。分布式事务的设计本质上就是在二者之间寻找平衡。

BASE 理论

BASE 理论是对 CAP 中 AP 方案的延伸，它放弃了强一致性，转而追求最终一致性：

• Basically Available：系统出现故障时，保证核心功能可用，允许降级。
• Soft state：系统中的数据允许存在中间状态，且该状态不会影响系统整体可用性。
• Eventually consistent：经过一段时间后，所有数据副本最终能达到一致。

BASE 理论为构建高可用的分布式事务方案（如异步消息、补偿机制）提供了指导思想。

两阶段提交协议

两阶段提交协议是最经典的强一致性分布式事务解决方案，常用于数据库层面的跨资源协调。

协议角色

• 协调者：通常由事务管理器担任，负责统筹整个事务过程。
• 参与者：各个独立的资源管理器，例如数据库、消息队列等。

执行阶段

阶段一：投票阶段

1. 协调者向所有参与者发送prepare请求，询问是否可以提交事务。
2. 参与者执行事务操作（但不真正提交），将 Undo 和 Redo 信息写入日志，然后返回YES或NO。
3. 如果所有参与者均返回YES，则进入第二阶段；否则协调者决定中止事务。

阶段二：提交/回滚阶段

• 提交：若协调者收到全部YES，则向所有参与者发送commit请求，参与者完成事务提交并释放资源。
• 回滚：若存在任何NO或超时未响应，协调者发送rollback请求，参与者利用 Undo 日志进行回滚。

2PC 的优缺点

优点：

• 原理简单，易于实现。
• 保证强一致性，数据不会出现中间状态。

缺点：

• 同步阻塞：准备阶段锁定的资源必须等待协调者最终指令才能释放，期间其他事务无法使用这些资源。
• 单点故障：协调者是一个中心节点，一旦崩溃可能导致整个事务阻塞，直到协调者恢复。
• 脑裂问题：在第二阶段，如果协调者与部分参与者之间出现网络故障，可能导致数据不一致（一部分提交，另一部分未提交）。

尽管如此，2PC 在许多关系型数据库（如 MySQL XA 事务）和部分中间件中仍然被广泛使用，适用于对一致性要求极高且并发量不大的场景。

TCC 补偿事务

TCC（Try-Confirm-Cancel）是一种基于补偿思想的柔性分布式事务模型，它将一个业务操作分解为三个阶段，由业务方显式实现每一个步骤。

核心思想

将跨服务的操作拆分为：

• Try：预留业务资源（如冻结库存、预占优惠券），此阶段不实际发生业务变更。
• Confirm：确认提交，使用 Try 阶段预留的资源完成真正的业务操作，此步骤需要幂等。
• Cancel：取消释放，若事务需要回滚，则释放 Try 阶段预留的资源，此步骤同样需要幂等。

TCC 的事务协调器负责依次调用各服务的 Try 接口，并根据结果决定调用 Confirm 或 Cancel。

执行流程

1. 协调器调用所有参与服务的 Try 方法。
2. 若所有 Try 均成功，则依次调用各服务的 Confirm 方法；否则调用所有已成功 Try 服务的 Cancel 方法。
3. 在 Confirm 或 Cancel 过程中如果出现调用失败，协调器会不断重试，因此这两个操作必须设计为幂等，防止重复执行造成业务错误。

TCC 的优缺点

优点：

• 无资源锁，事务执行过程中不锁定数据库资源，性能较高。
• 业务方可以自行控制资源预留的粒度，灵活性强。
• 没有数据库层面的协议依赖，适用于异构数据源。

缺点：

• 业务侵入性强：每个参与方都必须额外开发 Try、Confirm、Cancel 三套逻辑，改造成本高。
• 数据一致性保障由业务层负责，可能出现补偿失败后的脏数据，需要额外的异常处理机制。
• 空回滚和悬挂：若 Try 由于网络超时未被协调者收到，协调者可能发起 Cancel，但此时资源并未预留（空回滚）；或者 Cancel 先于 Try 到达（悬挂），需要业务方妥善处理。

TCC 适用于对可用性和性能要求较高的核心交易链路，如电商下单、支付流程等。

最终一致性与消息驱动方案

在许多互联网业务中，强一致性并非绝对必要，最终一致性配合合理的业务设计往往可以达到较好的用户体验。

基于可靠消息的最终一致性

此方案的核心思想是：使用消息队列保证本地事务与消息发送的原子性，再由消费方通过重试和幂等消费保证业务最终完成。

本地消息表 + 轮询

1. 发起方在同一个本地事务中，既执行业务操作，又向本地消息表插入一条“待发送”消息。
2. 后台定时任务不断扫描消息表，将未成功发送的消息投递到 MQ。
3. 消费方从 MQ 拉取消息执行业务，并配合幂等性设计防止重复执行。
4. 发起方在确认消费成功后，更新消息状态为已完成或直接删除。

事务消息（如 RocketMQ）

RocketMQ 等中间件提供事务消息机制，将消息发送拆分为两阶段：

1. 发送半消息：生产者向 Broker 发送一条对于消费者不可见的半消息。
2. 执行本地事务：生产者执行本地数据库操作。
3. 提交或回滚：根据本地事务结果，向 Broker 发送 Commit 或 Rollback。若 Commit，Broker 将该消息投递给消费者；若 Rollback，则丢弃消息。
4. 回查机制：如果 Broker 未收到二次确认，会定期回查生产者以确定消息状态。

这种方式无需额外维护消息表，由中间件保障事务的最终一致性，大大简化了开发工作。

幂等性设计

最终一致性的实现强依赖于消费端的幂等处理。常用策略包括：

• 唯一约束：利用数据库唯一键避免重复插入。
• 状态机：业务状态流转前检查前置状态。
• Token 机制：每次请求携带唯一 Token，服务端校验并记录已处理 Token。

对账与补偿

即使有了消息和重试机制，在网络长时间不可用或程序 Bug 的情况下仍可能产生不一致。因此大部分高可靠性系统都会实现离线对账和自动补偿，定期扫描业务数据差异并进行修复。

对比与选型指南

没有银弹，选择方案时需结合业务实际：

• 若为银行核心账务系统，可考虑基于 2PC 的 XA 事务。
• 电商下单扣库存等强性能要求场景，TCC 更为合适。
• 积分发送、邮件通知等非核心链路，采用最终一致性即可大幅降低复杂度。

实战注意事项

1. 超时处理：无论何种协议，网络超时都是常见情况。必须为 Try、Confirm、Cancel 等操作设定合理的超时时间，并明确超时后的默认行为（重试、回滚还是报警人工介入）。
2. 幂等保证：Confirm 和 Cancel 必须实现幂等；消息消费端同一消息可能被多次投递，需要在业务层保证幂等。
3. 异常状态监控：分布式事务链路长、失控点增多，必须建立完善的监控体系，及时发现阻塞事务、大量回滚或补偿任务积压。
4. 人工干预：无法自动恢复的异常情况（如空回滚后需要人工核对）应提供管理后台，支持查询事务状态及手动重试/跳过。
5. 技术选型：尽量选用成熟框架减少自研成本，如 Seata（支持 AT、TCC、Saga 模式）、RocketMQ 事务消息等。

结语

分布式事务是构建可靠分布式系统的核心挑战之一。从追求强一致性的 2PC，到业务侵入式的 TCC，再到高可用的最终一致性方案，每种模型都有其适用的边界。理解背后的理论并灵活运用，你才能在保障业务一致性的同时，设计出高性能、高可用的系统。

希望本教程能为你在分布式事务的选型和落地中提供清晰的指引。