当前位置：首页 > news >正文

62.微服务保姆教程 (五) Seata--微服务分布式事务组件

news 来源：原创 2025/5/21 0:35:48

Seata–微服务分布式事务组件

一、什么是分布式事务

1.什么是事务

事务指的是一个操作单元，在这个操作单元中的所有操作最终要保持一致的行为，要么所有操作都成功，要么所有的操作都被撤销。

2.本地事务

本地事务是指基于关系型数据库的事务，也称为传统事务。大多数场景下，我们的应用都只需要提供单一的数据库，这种情况下的事务称之为本地事务。本地事务的ACID特性是数据库直接提供。

使用@Transational声明事务

3.分布式事务

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

比如：

下面的两种情况，一种是同一个事务用到两个数据库，一个是同一个事务中的操作在不同的微服务上，可能使用同一个数据库，也可能用两个数据库。

在这里插入图片描述

二、微服务分布式事务组件–Seata

1、Seata是什么

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。其中AT是阿里首推的模式。

官网：https://seata.io/zh-cn/

2、分布式事务提交协议

2.1两阶段提交（2PC）

两阶段提交又称2PC（two-phase commit protocol）,2pc是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）。

阶段1：预处理阶段/请求阶段

1.询问协调者向所有参与者发送事务请求，询问是否可以执行事务操作，然后等待各个参与者的响应。

2 执行各个参与者接收到协调者事务请求后，执行事务操作，并将Undo和Redo信息记录到事务日志中。

3 响应如果参与者成功执行了事务并写入了Undo和Redo信息，则向协调者返回YES响应，否则返回NO响应。当然，参与者也可能宕机，从而不能返回响应。

阶段2：提交回滚阶段/执行阶段

1.Commit/rollback请求, 在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。

2 事务提交参与者收到Commit或者rollback请求，执行事务提交或回滚操作，完成后释放事务执行期占用的所有资源。

3 反馈结果参与者执行事务提交后向协调者发送Ask响应

4 完成事务协调者接收到所有参与者的Ack响应后，完成事务提交。

在这里插入图片描述

两阶段提交（Two-Phase Commit, 2PC）是分布式事务处理中常用的一种协议，它用于确保分布式系统中所有参与者的事务要么都成功提交，要么都回滚，从而保证数据的一致性。以下是两阶段提交的主要优缺点：

二阶段提交的优势

保证一致性：2PC 协议能确保分布式事务的原子性，保证所有参与者要么都提交事务，要么都回滚，避免了数据的不一致性。
协议简单：2PC 协议相对简单，易于理解和实现。它主要包括两个阶段：准备阶段和提交阶段，步骤清晰明了。
事务管理：能够管理跨多个系统或服务的事务，确保各个参与者的操作要么全部成功，要么全部失败。

二阶段提交的缺点

同步阻塞：在两阶段提交过程中，所有参与者在等待协调者的响应时会进入阻塞状态。尤其是在协调者发起提议后，如果协调者宕机或失去联系，所有参与者将长时间处于阻塞状态，无法继续其他操作。
单点故障：协调者作为协议中的中心节点，如果协调者出现故障，可能导致整个事务无法完成。协调者故障会使得事务处于未决状态，难以恢复。
恢复复杂：如果协调者在准备阶段或提交阶段发生故障，可能导致事务的状态不一致。虽然有一些恢复策略，但实现起来相对复杂，尤其是在协调者宕机后，如何恢复事务的状态。
性能开销：两阶段提交协议涉及到网络通信和等待响应的过程，会带来一定的性能开销。尤其是在大规模分布式系统中，网络延迟和消息传递的开销会影响整体性能。
过于保守：2PC 协议中，只要有一个参与者无法提交，整个事务都会被回滚。这种保守的处理方式可能导致系统的吞吐量降低，因为事务必须保证所有参与者都成功才能提交。

2.2 三阶段提交(3PC)

三阶段提交协议在协调者和参与者中都引入超时机制，并且把两阶段提交协议的第一个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。形成canCOmmit、PreCommit、和doCommit三个阶段组成的事物处理协议。

三阶段提交（Three-Phase Commit, 3PC 或 TCC）是分布式事务处理中用于解决两阶段提交（Two-Phase Commit, 2PC）协议存在的一些问题的改进方案。三阶段提交协议是为了解决两阶段提交中存在的同步阻塞、单点问题、数据不一致和过于保守等问题而提出的。

三阶段提交分为以下三个阶段：

预备（Prepare）阶段

协调者向所有参与者发送预备（Prepare）请求。
参与者收到预备请求后，参与者的事务处于准备状态，会执行事务的本地操作，并记录事务的状态。
如果参与者发现自己的状态不能满足事务要求，或者在准备阶段出现问题，它会通知协调者它不能通过预备状态。

投票（Vote）阶段

如果所有参与者都同意事务可以进入提交阶段，那么协调者会收到所有成功的响应，然后向所有参与者发送提交（Commit）请求。
如果协调者收到任何一个参与者的失败（Reject）响应，它会收集所有参与者的响应，并决定是否需要回滚。

提交（Commit）/回滚（Abort）阶段

如果协调者确定所有参与者都能够提交事务，它会向所有参与者发送提交请求。
如果协调者确定任何参与者无法提交，它会向所有参与者发送回滚请求。

三阶段提交的关键改进在于引入了一个“投票”阶段，这个阶段确保除非所有参与者都可以提交事务，否则事务不会被提交。这样就避免了单点问题和在某些情况下数据不一致的问题，因为如果有一个参与者拒绝提交，那么所有参与者都会知道事务需要被回滚。

三阶段提交的优势

避免单点问题：在三阶段提交中，即使协调者故障，参与者的状态也是确定的，因此可以避免单点问题。
减少同步阻塞：由于增加了投票阶段，三阶段提交可以减少因等待协调者响应而产生的同步阻塞。
提高数据一致性：通过增加一个阶段来确保所有参与者都准备提交，三阶段提交可以减少数据不一致的风险。

三阶段提交的缺点

三阶段提交也有其缺点，比如它可能会增加系统的复杂性，同时也可能增加了系统在最终一致性方面的延迟，因为参与者和服务需要等待协调者的最终决定。

三阶段提交机制在实际应用中可能不如预期的那样普遍，因为它对网络通信和系统之间的同步有更严格的要求，而且在某些情况下的性能可能不如直接的二阶段提交好。在实际实现时，需要根据具体场景权衡利弊。

3、Seata事务模式

seata提供了4种事务模式（AT、TCC、Saga、XA )的分布式事务实现。

其中AT模式是阿里首推的模式。

AT 模式：适用于需要自动化事务管理的场景，简单易用，但只对关系型数据库有用。
TCC 模式：适用于需要细粒度控制和灵活事务处理的场景，但开发复杂度较