分布式事务

最新推荐文章于 2025-04-24 19:53:39 发布

虚行

最新推荐文章于 2025-04-24 19:53:39 发布

阅读量696

点赞数 19

文章标签：分布式

本文链接：https://blog.youkuaiyun.com/XuXing_java/article/details/146018127

版权

分布式事务是指在分布式系统中涉及到多个数据库或多个应用程序之间的事务处理，这些数据库或应用程序可能分布在不同的物理节点上，甚至可能位于不同的地理位置。在分布式事务中，需要确保所有参与者的事务操作都能够保持一致性，即所有参与者的事务要么全部提交成功，要么全部回滚。

为了解决分布式事务的问题，出现了一些分布式事务解决方案，如XA协议、TCC事务、最大努力通知等。

表格对比

	2PC	3PC	XA （XA 是 2PC 的标准实现）	AT (Automatic Transaction)	TCC (Try-Confirm-Cancel)	Saga
优点	为啥2PC是一个强一致性的了，因为他是一个事务，是严格遵循ACID的			没有入侵，按照Seata的要求引入@GlobalTransaction注解	不管你是Redis、MySQL还是ES，反正他就是要你自己实现Try、Confirm和Cancel，具体的逻辑你自己写，提交、回滚
	2PC是一个事务，拆分成了准备阶段和提交阶段，但是他还是一个事务			需要把写数据库和写Redis放到同一个分布式事务中，AT模式就不支持了	业务代码侵入性：TCC需要将事务操作拆分为Try、Confirm和Cancel三个步骤
	Prepare阶段事务是不提交的，直到第二个阶段实物才会提交。所以他的事务更长，阻塞时间更差，性能更差。		XA中，一阶段是只做资源占用，二阶段在进行回滚或者提交	Seata的AT模式中，为了提升性能，直接提交了事务，在二阶段，需要回滚的话再执行回滚。	每一个步骤操作数据库的时候都是一个单独的事务，单独开启，单独提交。TCC是最终一致性，通过全局锁和重试机制保证最终一致。
描述	协调者指挥，参与者投票，一致才提交。	多一个阶段，减少锁定，但复杂。	2PC 的标准实现，数据库支持。	自动 undo log，无锁高性能。	业务层 Try、Confirm、Cancel，手动补偿。	事务链+补偿，最终一致性。
使用注意	2PC 依赖协调者和参与者之间的可靠通信，网络中断或延迟可能导致事务阻塞。	大多数数据库和消息队列并未实现 3PC 协议，导致无法使用。	存在资源锁定问题，不适合追求高性能的场景。	1.依赖MySQL的undolog， 2.不适合要求立即一致性的业务（如金融转账）	适合复杂业务场景，在简单业务中使用得不偿失。	不适合需要立即一致性的业务（如实时库存扣减）
一致性	强一致	强一致	强一致	弱一致	弱一致	最终一致
隔离性			完全隔离	基于全局锁隔离	基于资源预留隔离	无隔离
代码入侵	代码入侵低，但性能受限	代码入侵低，但性能受限	代码入侵低，但性能受限	自动 undo log，无锁	高性能，手动补偿	事务链+补偿
性能	性能受限	性能受限	性能受限	高性能	高性能	高性能
适用场景	数据库支持 XA	少用，复杂	数据库支持 XA	数据库支持 MVCC	业务复杂，需手动控制	长事务，业务流程复杂

Java 中分布式事务的几种实现方式：2PC、3PC、XA、AT、TCC、Saga，包括它们的底层原理、性能、代码入侵程度

1. 2PC (Two-Phase Commit)

底层原理

2PC 是一种基于协调者的分布式事务协议，分为两个阶段：

准备阶段：协调者向所有参与者发送“准备”请求，参与者执行本地事务但不提交，回复“准备好”或“失败”。
提交阶段：如果所有参与者都回复“准备好”，协调者发送“提交”命令；否则发送“回滚”命令。
问题：若协调者故障，可能导致资源长时间锁定。

性能

高延迟：需要两次网络往返，性能较差。
资源锁定：准备阶段会锁定资源，影响并发性。

代码入侵

低：通常由数据库或消息队列实现，应用层只需调用相关接口，代码改动较小。

快速记忆

“协调者指挥，参与者投票，投票一致才提交。”

2. 3PC (Three-Phase Commit)

底层原理

3PC 是 2PC 的改进版，分为三个阶段：

CanCommit：协调者询问参与者是否可以提交，参与者回复“可以”或“不行”。
PreCommit：如果所有参与者同意，协调者发送“预提交”命令，参与者准备提交。
DoCommit：协调者发送“提交”命令，参与者完成提交。
改进：引入超时机制，减少资源锁定时间。

性能

中等延迟：比 2PC 多一个阶段，但减少了资源锁定时间。
复杂性：实现复杂，实际应用较少。

代码入侵

低：与 2PC 类似，通常由底层系统实现，应用层代码改动小。

快速记忆

“多一个阶段，减少锁定，但实现复杂。”

3. XA (eXtended Architecture)

底层原理

基于 2PC：XA 是 2PC 的标准实现，定义了事务管理器和资源管理器之间的接口。
多资源协调：支持多个数据库或消息队列的事务协调。

性能

与 2PC 类似：高延迟，资源锁定时间长。

代码入侵

低：应用层只需配置 XA 数据源（如 JDBC 的 XADataSource），代码改动少。

快速记忆

“XA 是 2PC 的标准实现，数据库支持 XA 接口。”

4. AT (Automatic Transaction)

底层原理

自动补偿：在事务提交前，记录 undo log，若失败则根据日志自动回滚。
无锁：不依赖全局锁，利用数据库的 MVCC（多版本并发控制）实现。

性能

高性能：无全局锁，依赖数据库并发控制，延迟低。
适用场景：需要数据库支持 MVCC。

代码入侵

低：由框架（如 Seata）自动处理，应用层代码改动小。

快速记忆

“自动记录 undo log，失败自动回滚，无锁高性能。”

5. TCC (Try-Confirm-Cancel)

底层原理

Try：预留资源，检查业务逻辑是否可行。
Confirm：确认提交，释放预留资源。
Cancel：取消预留，释放资源。
手动补偿：业务层需实现 Try、Confirm、Cancel 三个接口。

性能

高性能：不锁定资源，Try 阶段仅预留资源。
复杂性：开发成本高，需手动实现补偿逻辑。

代码入侵

高：业务层需显式实现 Try、Confirm、Cancel 逻辑，代码入侵明显。

快速记忆

“业务层实现 Try、Confirm、Cancel，手动补偿。”

6. Saga

底层原理

事务链：将长事务拆分为多个本地事务，每个事务有对应的补偿操作。
补偿机制：若某一步失败，执行前面已完成事务的补偿操作。
最终一致性：不保证隔离性，依赖业务补偿实现一致性。

性能

高性能：异步执行，不锁定资源。
适用场景：适合长事务或复杂业务流程。

代码入侵

高：业务层需实现每个本地事务及其补偿逻辑。

快速记忆

“将长事务拆分为多个本地事务，失败时补偿。”

表格对比

实现方式	底层原理	性能	代码入侵	适用场景
2PC	准备+提交/回滚	高延迟，资源锁定	低	数据库支持 XA
3PC	CanCommit+PreCommit+DoCommit	中等延迟，减少锁定	低	少用，复杂
XA	2PC 标准实现	与 2PC 类似	低	数据库支持 XA
AT	自动 undo log，无锁	高性能	低	数据库支持 MVCC
TCC	Try-Confirm-Cancel	高性能，手动补偿	高	业务复杂，需手动控制
Saga	事务链+补偿	高性能，最终一致性	高	长事务，业务流程复杂

快速记忆总结

2PC：协调者指挥，参与者投票，一致才提交。
3PC：多一个阶段，减少锁定，但复杂。
XA：2PC 的标准实现，数据库支持。
AT：自动 undo log，无锁高性能。
TCC：业务层 Try、Confirm、Cancel，手动补偿。
Saga：事务链+补偿，最终一致性。

总结

以上六种分布式事务实现方式各有优劣：

2PC、3PC、XA 更适合数据库层面的强一致性场景，代码入侵低，但性能受限。
AT 提供高性能和低代码入侵，适合支持 MVCC 的数据库。
TCC 和 Saga 强调最终一致性和高性能，但需要业务层深度参与，代码入侵高。

选择时需根据业务场景（如一致性要求、事务长度、性能需求）进行权衡。希望这个回答对你理解 Java 中的分布式事务有所帮助！

使用场景及优缺点点对比

下面是对 Java 中分布式事务模式（2PC、3PC、XA、AT、TCC、Saga）在哪些场景中不能使用，以及使用时可能存在问题的详细整理和分析。这些模式各有其特性，因此适用场景和局限性也不同。

1. 2PC (Two-Phase Commit, 两阶段提交)

不适用场景

高并发、高吞吐量系统：2PC 在提交事务时会长时间锁定资源，导致并发性能下降，难以满足高吞吐量需求。
网络不稳定环境：2PC 依赖协调者和参与者之间的可靠通信，网络中断或延迟可能导致事务阻塞。
不支持 XA 协议的数据库：如果数据库（如某些 NoSQL 数据库）不支持 XA 协议，2PC 无法实施。

使用问题

性能瓶颈：资源锁定时间长，降低系统响应速度和吞吐量。
单点故障：协调者若发生故障，参与者可能无限期等待，导致资源持续被锁定。
复杂性：实现和维护成本较高，尤其在分布式系统中管理多个参与者时。

2. 3PC (Three-Phase Commit, 三阶段提交)

不适用场景

简单系统：3PC 比 2PC 更复杂，适合高可靠性需求的场景，在简单系统中使用显得过度设计。
不支持 3PC 协议的系统：大多数数据库和消息队列并未实现 3PC 协议，导致无法使用。
高延迟敏感系统：3PC 增加了一个准备阶段，延长事务时间，不适合对延迟敏感的场景。

使用问题

实现复杂：协议设计复杂，实际应用中很少使用，开发和调试成本高。
性能开销：多一个阶段增加了网络通信和计算开销。
一致性问题：尽管比 2PC 更可靠，但在某些故障场景下仍可能出现数据不一致。

3. XA (eXtended Architecture, 扩展架构)

不适用场景

不支持 XA 协议的数据库：如某些 NoSQL 数据库或旧版本关系型数据库，无法使用 XA。
高性能需求系统：XA 基于 2PC，存在资源锁定问题，不适合追求高性能的场景。
云原生环境：微服务架构中，XA 对数据库层强一致性的依赖使其难以适配分布式系统的灵活性。

使用问题

资源锁定：事务执行期间长时间锁定资源，影响并发性能。
单点故障：事务管理器故障可能导致事务无法完成，阻塞系统。
复杂配置：多数据库环境下，XA 数据源的配置和管理较为繁琐。

4. AT (Automatic Transaction, 自动事务)

不适用场景

不支持 MVCC 的数据库：AT 依赖数据库的多版本并发控制（MVCC）机制，若数据库不支持（如某些早期版本数据库），则无法使用。
需要强一致性场景：AT 提供的是最终一致性，不适合要求立即一致性的业务（如金融转账）。
复杂业务逻辑：AT 自动生成回滚日志（undo log），难以应对复杂的业务补偿逻辑。

使用问题

性能开销：生成和执行 undo log 会增加数据库负载，影响性能。
数据一致性：在高并发场景下，可能出现短暂的数据不一致。
数据库限制：依赖数据库的快照隔离级别，不支持所有数据库类型。

5. TCC (Try-Confirm-Cancel, 尝试-确认-取消)

不适用场景

业务逻辑简单：TCC 实现成本高，适合复杂业务场景，在简单业务中使用得不偿失。
不支持补偿的业务：如果业务无法设计 Try、Confirm、Cancel 三个阶段的逻辑，TCC 无法实施。
高并发场景：Try 阶段预留资源时间过长，可能影响系统性能。

使用问题

开发成本高：业务层需手动实现 Try、Confirm、Cancel 逻辑，增加开发和维护工作量。
一致性问题：若 Confirm 或 Cancel 阶段失败，可能导致数据不一致。
资源预留：Try 阶段预留资源，若事务未及时完成，资源占用时间较长。

6. Saga

不适用场景

需要强一致性场景：Saga 提供最终一致性，不适合需要立即一致性的业务（如实时库存扣减）。
不支持补偿的业务：如果业务无法设计补偿操作，Saga 无法使用。
短事务：Saga 更适合长事务或复杂业务流程，短事务使用显得复杂。

使用问题

开发成本高：每个本地事务需实现对应的补偿逻辑，增加开发工作量。
一致性延迟：最终一致性可能导致数据不一致的时间窗口。
补偿失败：若补偿操作失败，可能需要人工干预，影响系统可靠性。

总结表格

模式	不适用场景	使用问题
2PC	高并发、高吞吐量、网络不稳定、不支持 XA	性能瓶颈、单点故障、复杂性
3PC	简单系统、不支持 3PC、高延迟敏感	实现复杂、性能开销、一致性问题
XA	不支持 XA、高性能需求、云原生环境	资源锁定、单点故障、复杂配置
AT	不支持 MVCC、强一致性、复杂业务	性能开销、数据一致性、数据库限制
TCC	业务简单、不支持补偿、高并发	开发成本高、一致性问题、资源预留
Saga	强一致性、不支持补偿、短事务	开发成本高、一致性延迟、补偿失败

总结

Java 中的分布式事务模式各有优缺点，选择时需根据具体业务需求、系统架构和数据库支持情况进行权衡：

2PC、3PC、XA：适合数据库层强一致性需求，但性能较低，适合传统单体架构。
AT：提供高性能和自动化补偿，但依赖数据库特性，适合最终一致性场景。
TCC 和 Saga：强调业务灵活性和最终一致性，适合微服务架构，但开发成本较高。

AT与XA的对比

1. XA 模式

1.1 基本原理

XA 模式基于 X/Open 组织提出的 XA 分布式事务处理规范，采用两阶段提交（2PC）协议来保证事务一致性。其核心组件包括事务管理器（TM）和资源管理器（RM，通常是数据库）。

第一阶段（准备阶段）：事务管理器向所有资源管理器发送“准备”请求，资源管理器执行本地事务但不提交，返回“准备好”或“失败”。
第二阶段（提交阶段）：若所有资源管理器回复“准备好”，事务管理器发出“提交”命令；否则发出“回滚”命令。

在 Seata 中，XA 模式通过数据库的原生 XA 支持实现，应用程序需配置 XA 数据源（如 DataSourceProxyXA），由 Seata 的 TM 协调事务。

1.2

优点

强一致性：通过 2PC 协议，所有参与者要么全部提交，要么全部回滚，保证了强一致性。
高隔离性：准备阶段锁定资源，直到事务完成，提供较高的隔离级别（如数据库默认的隔离级别）。
标准化：XA 是广泛认可的协议，被大多数主流数据库（如 MySQL InnoDB、Oracle）支持。

1.3 缺点

性能较低：两阶段提交涉及多次网络通信（准备和提交），导致延迟较高。
资源锁定时间长：资源在准备阶段被锁定，直到提交或回滚完成，影响并发性能。
故障敏感：若协调者在准备后、提交前失败，资源可能长时间处于锁定状态。
数据库兼容性问题：Seata 的 XA 模式对某些数据库（如 Oracle）支持有限，因为 Seata 的一些优化与标准 XA 协议冲突。

1.4 使用场景

需要强一致性和高隔离性的场景，如金融系统中的核心交易。
数据库完全支持 XA 协议且性能要求不高的环境。

2. AT 模式

2.1 基本原理

AT 模式是 Seata 独创的自动事务模式，旨在以非侵入的方式处理分布式事务。它基于支持本地 ACID 事务的关系型数据库，采用一阶段提交结合补偿机制实现分布式事务。

第一阶段：在本地事务中同时提交业务数据和回滚日志（存储在 undo_log 表中），然后释放本地锁和连接资源。
第二阶段：若全局事务决定提交，则异步清理回滚日志；若决定回滚，则根据回滚日志执行补偿操作。

AT 模式通过 Seata 的数据源代理拦截业务 SQL，自动生成回滚日志，并在全局事务协调下完成提交或回滚。

2.2 优点

高性能：第一阶段完成后即释放锁，锁持有时间短，提升并发能力。
异步处理：第二阶段提交异步执行，降低延迟。
故障健壮性：即使协调者失败，资源不会长时间锁定，系统可继续运行，后续通过补偿恢复。
广泛适用性：支持大多数关系型数据库（如 MySQL、Oracle、PostgreSQL），仅需支持本地 ACID 事务。

2.3 缺点

最终一致性：默认提供最终一致性，隔离级别为读未提交，需额外配置（如全局锁）实现更高隔离性。
轻微侵入：需在数据库中创建 undo_log 表，存储回滚信息。
存储开销：大型事务可能导致 undo_log 表占用较多空间。

2.4 使用场景

高并发、性能敏感的微服务架构。
可接受最终一致性或通过配置实现更高隔离性的场景。
数据库支持本地事务但未必支持 XA 的环境。

3. AT 与 XA 的详细对比

特性	AT 模式	XA 模式
一致性	最终一致性，可通过全局锁实现读已提交	强一致性
隔离性	默认读未提交，可通过 SELECT FOR UPDATE 提升至读已提交	高隔离性（取决于数据库实现）
性能	高（短锁时间，异步提交）	低（长锁时间，同步提交）
锁持有时间	短（第一阶段后释放）	长（直到第二阶段完成）
故障恢复	健壮（不阻塞资源，可异步补偿）	较弱（协调者失败可能导致资源锁定）
数据库支持	支持本地 ACID 事务的数据库（如 MySQL、Oracle 等）	需支持 XA 协议的数据库（Seata 对 Oracle 等有限制）
业务侵入性	无侵入业务逻辑，但需添加 undo_log 表	无需 schema 变更
实现复杂度	Seata 负责回滚日志和全局锁管理	依赖数据库的 XA 实现
适用场景	高性能微服务、最终一致性可接受	强一致性需求、金融核心交易

4. 总结与选择建议

AT 模式
AT 模式通过一阶段提交和补偿机制实现了高性能和灵活性，锁释放早、支持异步操作，非常适合现代微服务架构。它默认提供最终一致性，但可通过全局锁等机制提升隔离性。AT 模式对数据库要求较低（仅需支持本地事务），且在 Seata 中应用更广泛，是大多数场景下的首选。
XA 模式
XA 模式依赖两阶段提交，提供强一致性和高隔离性，适合对数据一致性要求极高的场景。然而，其性能开销大、资源锁定时间长，且 Seata 的实现可能与某些数据库（如 Oracle）的标准 XA 协议不完全兼容，限制了其适用性。