图解7种分布式事务模型（一文带你掌握分布式事务）

admin管理员组

文章数量:1033251

图解7种分布式事务模型（一文带你掌握分布式事务）

Hello 我是方才，10人研发leader、4年团队管理&架构经验。文末，方才送你一份25年最新的架构师备考资料，记得领取哟！

分布式事务是微服务架构中的核心挑战之一，尤其在跨服务、跨数据库操作时需保证数据一致性。

今天方才就通过图解7种分布式事务模型，让你一次性掌握分布式事务！

1. 事务基础：ACID特性

事务基础：ACID特性

事务基础：ACID特性

在解决分布式事务的问题时，方才认为最应该优先考虑的方案是：通过设计去避免分布式事务，转为为本地事务。

比如在性能满足要求的情况下，将订单和库存功能放置在同一个服务中（这个例子可能不太合适，但思路是需要优先考虑的）。

2. 分布式事务协议

2PC（Two-Phase Commit，两阶段提交）

2PC（Two-Phase Commit，两阶段提交）

2PC（Two-Phase Commit，两阶段提交）

• 核心流程：
  1. 准备阶段（Prepare Phase）：协调者询问所有参与者是否可提交，参与者锁定资源并返回响应。
  2. 提交阶段（Commit Phase）：若所有参与者同意，协调者发送提交指令；否则发送回滚指令。
• 优点：强一致性，逻辑简单。
• 缺点：
  • 同步阻塞：参与者资源锁定时间长。
  • 单点故障：协调者宕机可能导致事务阻塞。
  • 数据不一致：网络分区时可能出现部分提交。

3PC（Three-Phase Commit，三阶段提交）

3PC（Three-Phase Commit，三阶段提交）

3PC（Three-Phase Commit，三阶段提交）

• 改进点：引入超时机制和预提交阶段，降低阻塞风险。
  • CanCommit：协调者询问参与者是否具备提交条件（不锁定资源）。
  • PreCommit：参与者锁定资源并反馈状态。
  • DoCommit：执行最终提交或回滚。
• 优点：减少阻塞时间，提升容错性。
• 缺点：实现复杂，仍无法完全避免数据不一致。

3.可靠事件队列

可靠事件队列（Reliable Event Queue）是一种基于最终一致性的分布式事务解决方案，通过异步事件驱动的方式，结合消息队列的可靠性机制，确保跨服务的事务最终一致。

ps：如果不想引入Seata组件，可以优先采用该方式，不过可靠事件队列，对研发的要求是更高的，因为消息存在重复或者重试的可能，所以相关实现需要保障幂等性。

• 核心原理
  • 事件驱动：将事务操作拆解为多个本地事务，通过事件（Event）通知下游服务。
  • 消息可靠性：利用消息队列（如 Kafka、RabbitMQ、RocketMQ）的持久化、重试、死信队列等机制，确保事件不丢失。
  • 幂等性：消费者通过唯一事务ID或业务唯一键保证操作幂等，避免重复处理。
• 适用场景
  • 跨服务最终一致性：如电商下单（订单、库存、支付）、用户注册（主服务、通知服务）。
  • 高并发场景：异步解耦，避免同步阻塞。
  • 容忍短暂不一致：接受秒级或分钟级延迟。
• 优点： 缺点：
  • 实现复杂（需处理事件表、重试、幂等）。
  • 数据一致性非实时（最终一致）。
  • 无强锁竞争，性能高。
  • 天然解耦，扩展性强。

4. Seata 组件详解

Seata（Simple Extensible Autonomous Transaction Architecture）是阿里巴巴开源的分布式事务解决方案，支持 AT、TCC、Saga、XA 四种模式，覆盖不同业务场景。官方地址：/

Seata 组件

Seata 组件

分布式事务包含以下 3 个核心组件：

• Transaction Coordinator（TC）：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
• Transaction Manager（TM）：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
• Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

一个典型的事务过程包括：

1. TM 向 TC 申请开启（Begin）一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
2. XID 在微服务调用链路的上下文中传播。
3. RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。
4. TM 向 TC 发起针对 XID 的全局提交（Commit）或回滚（Rollback）决议。
5. TC 调度 XID 下管辖的全部分支事务完成提交（Commit）或回滚（Rollback）请求。

事务模式是这个框架下 RM 驱动的分支事务的不同行为模式，即事务（分支）模式。事务模式包括 AT 模式、TCC 模式、Saga 模式和 XA 模式。

AT 模式（Automatic Transaction）

事务模式-AT

事务模式-AT

核心思想：通过代理数据源自动生成反向SQL，实现事务回滚。

适用场景：对业务侵入小，适合大部分OLTP场景。

AT 模式 RM 驱动分支事务的行为分为以下两个阶段：

• 执行阶段：
  1. 代理 JDBC 数据源，解析业务 SQL，生成更新前后的镜像数据，形成 UNDO LOG。
  2. 向 TC 注册分支。
  3. 分支注册成功后，把业务数据的更新和 UNDO LOG 放在同一个本地事务中提交。
• 完成阶段：
  • 全局提交，收到 TC 的分支提交请求，异步删除相应分支的 UNDO LOG。
  • 全局回滚，收到 TC 的分支回滚请求，查询分支对应的 UNDO LOG 记录，生成补偿回滚的 SQL 语句，执行分支回滚并返回结果给 TC。

TCC 模式（Try-Confirm-Cancel）

事务模式-TCC

事务模式-TCC

核心思想：通过业务逻辑实现事务补偿，需手动编写三个阶段：

1. Try：预留资源（如冻结库存）。
2. Confirm：确认操作（实际扣减库存）。
3. Cancel：取消操作（释放冻结的库存）。

优点：细粒度控制，支持高并发。

缺点：代码侵入性强，需处理幂等、悬挂等问题。

TCC 模式 RM 驱动分支事务的行为分为以下两个阶段：

• 执行阶段：
  1. 向 TC 注册分支。
  2. 执行业务定义的 Try 方法。
  3. 向 TC 上报 Try 方法执行情况：成功或失败。
• 完成阶段：
  • 全局提交，收到 TC 的分支提交请求，执行业务定义的 Confirm 方法。
  • 全局回滚，收到 TC 的分支回滚请求，执行业务定义的 Cancel 方法。

Saga 模式

事务模式-Saga

事务模式-Saga

核心思想：通过事件驱动，将长事务拆分为多个本地事务，每个事务提交后触发下一个事务，失败时执行逆向补偿。

适用场景：业务流程长、最终一致性可接受的场景（如电商订单+物流）。

Saga 模式 RM 驱动分支事务的行为包含以下两个阶段：

• 执行阶段：
  1. 向 TC 注册分支。
  2. 执行业务方法。
  3. 向 TC 上报业务方法执行情况：成功或失败。
• 完成阶段：
  • 全局提交，RM 不需要处理。
  • 全局回滚，收到 TC 的分支回滚请求，执行业务定义的补偿回滚方法。

XA 模式

事务模式-XA

事务模式-XA

基于数据库XA协议：依赖数据库的分布式事务能力（如MySQL XA）。

优点：强一致性，数据库原生支持。

缺点：性能低，数据库兼容性要求高。

XA 模式 RM 驱动分支事务的行为包含以下两个阶段：

• 执行阶段：
  1. 向 TC 注册分支。
  2. XA Start，执行业务 SQL，XA End。
  3. XA prepare，并向 TC 上报 XA 分支的执行情况：成功或失败。
• 完成阶段：
  • 收到 TC 的分支提交请求，XA Commit。
  • 收到 TC 的分支回滚请求，XA Rollback。

选型建议

模式	一致性	性能	侵入性	适用场景
AT	最终一致性	高	低	简单事务（如CRUD操作）
TCC	最终一致性	中	高	高并发、需资源预留（如秒杀）
Saga	最终一致性	中	中	长事务（如订单流程）
XA	强一致性	低	低	数据库支持XA协议的场景

最后

最后中，分布式事务如同一场“数据信任危机”——跨服务操作如何确保一致性？传统协议（2PC/3PC）虽强一致，却因性能瓶颈和单点故障举步维艰。但真正的破局密码竟是：优先通过设计规避分布式事务！ 通过服务拆分优化，将跨服务操作转为本地事务，化繁为简。

当分布式事务无法避免时，可靠事件队列以异步化、最终一致性的设计，成为高并发场景的轻量级救星，但需直面幂等性与消息可靠性的挑战。而开源利器Seata则带来更灵活的解法——AT模式零侵入自动回滚、TCC模式高并发资源预留、Saga长流程补偿，XA强一致兜底，四重模式覆盖从秒杀到物流的全场景需求！

无论是追求性能的可靠事件驱动，还是需要精细化控制的Seata方案，核心都在于权衡一致性与灵活性。选择没有标准答案，唯有深入业务，才能找到最适合的那把钥匙。

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-04-01，如有侵权请联系 cloudcommunity@tencent 删除模型事务性能分布式事务服务

图解7种分布式事务模型（一文带你掌握分布式事务）

Hello 我是方才，10人研发leader、4年团队管理&架构经验。文末，方才送你一份25年最新的架构师备考资料，记得领取哟！

分布式事务是微服务架构中的核心挑战之一，尤其在跨服务、跨数据库操作时需保证数据一致性。

今天方才就通过图解7种分布式事务模型，让你一次性掌握分布式事务！

1. 事务基础：ACID特性

事务基础：ACID特性

事务基础：ACID特性

在解决分布式事务的问题时，方才认为最应该优先考虑的方案是：通过设计去避免分布式事务，转为为本地事务。

比如在性能满足要求的情况下，将订单和库存功能放置在同一个服务中（这个例子可能不太合适，但思路是需要优先考虑的）。

2. 分布式事务协议

2PC（Two-Phase Commit，两阶段提交）

2PC（Two-Phase Commit，两阶段提交）

2PC（Two-Phase Commit，两阶段提交）

• 核心流程：
  1. 准备阶段（Prepare Phase）：协调者询问所有参与者是否可提交，参与者锁定资源并返回响应。
  2. 提交阶段（Commit Phase）：若所有参与者同意，协调者发送提交指令；否则发送回滚指令。
• 优点：强一致性，逻辑简单。
• 缺点：
  • 同步阻塞：参与者资源锁定时间长。
  • 单点故障：协调者宕机可能导致事务阻塞。
  • 数据不一致：网络分区时可能出现部分提交。

3PC（Three-Phase Commit，三阶段提交）

3PC（Three-Phase Commit，三阶段提交）

3PC（Three-Phase Commit，三阶段提交）

• 改进点：引入超时机制和预提交阶段，降低阻塞风险。
  • CanCommit：协调者询问参与者是否具备提交条件（不锁定资源）。
  • PreCommit：参与者锁定资源并反馈状态。
  • DoCommit：执行最终提交或回滚。
• 优点：减少阻塞时间，提升容错性。
• 缺点：实现复杂，仍无法完全避免数据不一致。

3.可靠事件队列

可靠事件队列（Reliable Event Queue）是一种基于最终一致性的分布式事务解决方案，通过异步事件驱动的方式，结合消息队列的可靠性机制，确保跨服务的事务最终一致。

ps：如果不想引入Seata组件，可以优先采用该方式，不过可靠事件队列，对研发的要求是更高的，因为消息存在重复或者重试的可能，所以相关实现需要保障幂等性。

• 核心原理
  • 事件驱动：将事务操作拆解为多个本地事务，通过事件（Event）通知下游服务。
  • 消息可靠性：利用消息队列（如 Kafka、RabbitMQ、RocketMQ）的持久化、重试、死信队列等机制，确保事件不丢失。
  • 幂等性：消费者通过唯一事务ID或业务唯一键保证操作幂等，避免重复处理。
• 适用场景
  • 跨服务最终一致性：如电商下单（订单、库存、支付）、用户注册（主服务、通知服务）。
  • 高并发场景：异步解耦，避免同步阻塞。
  • 容忍短暂不一致：接受秒级或分钟级延迟。
• 优点： 缺点：
  • 实现复杂（需处理事件表、重试、幂等）。
  • 数据一致性非实时（最终一致）。
  • 无强锁竞争，性能高。
  • 天然解耦，扩展性强。

4. Seata 组件详解

Seata（Simple Extensible Autonomous Transaction Architecture）是阿里巴巴开源的分布式事务解决方案，支持 AT、TCC、Saga、XA 四种模式，覆盖不同业务场景。官方地址：/

Seata 组件

Seata 组件

分布式事务包含以下 3 个核心组件：

• Transaction Coordinator（TC）：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
• Transaction Manager（TM）：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
• Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

一个典型的事务过程包括：

1. TM 向 TC 申请开启（Begin）一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
2. XID 在微服务调用链路的上下文中传播。
3. RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。
4. TM 向 TC 发起针对 XID 的全局提交（Commit）或回滚（Rollback）决议。
5. TC 调度 XID 下管辖的全部分支事务完成提交（Commit）或回滚（Rollback）请求。

事务模式是这个框架下 RM 驱动的分支事务的不同行为模式，即事务（分支）模式。事务模式包括 AT 模式、TCC 模式、Saga 模式和 XA 模式。

AT 模式（Automatic Transaction）

事务模式-AT

事务模式-AT

核心思想：通过代理数据源自动生成反向SQL，实现事务回滚。

适用场景：对业务侵入小，适合大部分OLTP场景。

AT 模式 RM 驱动分支事务的行为分为以下两个阶段：

• 执行阶段：
  1. 代理 JDBC 数据源，解析业务 SQL，生成更新前后的镜像数据，形成 UNDO LOG。
  2. 向 TC 注册分支。
  3. 分支注册成功后，把业务数据的更新和 UNDO LOG 放在同一个本地事务中提交。
• 完成阶段：
  • 全局提交，收到 TC 的分支提交请求，异步删除相应分支的 UNDO LOG。
  • 全局回滚，收到 TC 的分支回滚请求，查询分支对应的 UNDO LOG 记录，生成补偿回滚的 SQL 语句，执行分支回滚并返回结果给 TC。

TCC 模式（Try-Confirm-Cancel）

事务模式-TCC

事务模式-TCC

核心思想：通过业务逻辑实现事务补偿，需手动编写三个阶段：

1. Try：预留资源（如冻结库存）。
2. Confirm：确认操作（实际扣减库存）。
3. Cancel：取消操作（释放冻结的库存）。

优点：细粒度控制，支持高并发。

缺点：代码侵入性强，需处理幂等、悬挂等问题。

TCC 模式 RM 驱动分支事务的行为分为以下两个阶段：

• 执行阶段：
  1. 向 TC 注册分支。
  2. 执行业务定义的 Try 方法。
  3. 向 TC 上报 Try 方法执行情况：成功或失败。
• 完成阶段：
  • 全局提交，收到 TC 的分支提交请求，执行业务定义的 Confirm 方法。
  • 全局回滚，收到 TC 的分支回滚请求，执行业务定义的 Cancel 方法。

Saga 模式

事务模式-Saga

事务模式-Saga

核心思想：通过事件驱动，将长事务拆分为多个本地事务，每个事务提交后触发下一个事务，失败时执行逆向补偿。

适用场景：业务流程长、最终一致性可接受的场景（如电商订单+物流）。

Saga 模式 RM 驱动分支事务的行为包含以下两个阶段：

• 执行阶段：
  1. 向 TC 注册分支。
  2. 执行业务方法。
  3. 向 TC 上报业务方法执行情况：成功或失败。
• 完成阶段：
  • 全局提交，RM 不需要处理。
  • 全局回滚，收到 TC 的分支回滚请求，执行业务定义的补偿回滚方法。

XA 模式

事务模式-XA

事务模式-XA

基于数据库XA协议：依赖数据库的分布式事务能力（如MySQL XA）。

优点：强一致性，数据库原生支持。

缺点：性能低，数据库兼容性要求高。

XA 模式 RM 驱动分支事务的行为包含以下两个阶段：

• 执行阶段：
  1. 向 TC 注册分支。
  2. XA Start，执行业务 SQL，XA End。
  3. XA prepare，并向 TC 上报 XA 分支的执行情况：成功或失败。
• 完成阶段：
  • 收到 TC 的分支提交请求，XA Commit。
  • 收到 TC 的分支回滚请求，XA Rollback。

选型建议

模式	一致性	性能	侵入性	适用场景
AT	最终一致性	高	低	简单事务（如CRUD操作）
TCC	最终一致性	中	高	高并发、需资源预留（如秒杀）
Saga	最终一致性	中	中	长事务（如订单流程）
XA	强一致性	低	低	数据库支持XA协议的场景

最后

最后中，分布式事务如同一场“数据信任危机”——跨服务操作如何确保一致性？传统协议（2PC/3PC）虽强一致，却因性能瓶颈和单点故障举步维艰。但真正的破局密码竟是：优先通过设计规避分布式事务！ 通过服务拆分优化，将跨服务操作转为本地事务，化繁为简。

当分布式事务无法避免时，可靠事件队列以异步化、最终一致性的设计，成为高并发场景的轻量级救星，但需直面幂等性与消息可靠性的挑战。而开源利器Seata则带来更灵活的解法——AT模式零侵入自动回滚、TCC模式高并发资源预留、Saga长流程补偿，XA强一致兜底，四重模式覆盖从秒杀到物流的全场景需求！

无论是追求性能的可靠事件驱动，还是需要精细化控制的Seata方案，核心都在于权衡一致性与灵活性。选择没有标准答案，唯有深入业务，才能找到最适合的那把钥匙。

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-04-01，如有侵权请联系 cloudcommunity@tencent 删除模型事务性能分布式事务服务

本文标签： 图解7种分布式事务模型（一文带你掌握分布式事务）