分布式事务协调器Seata

Seata 是什么？ | Apache Seata

1、四种模式的选择

1.1 只有AT、 XA模式是代码无侵入的。首选这两个。

1.2 XA模式

XA 是一种基于两阶段提交协议（2PC）的分布式事务协议，它由 X/Open 组织提出。在这种模式下，事务管理器（Transaction Manager, TM）需要与多个资源管理器（Resource Manager, RM）进行协调，以确保事务的原子性。

两阶段提交协议（2PC）的工作过程：

• 第一阶段（准备阶段）：事务管理器指示参与事务的所有资源管理器准备提交事务。每个资源管理器将对事务进行准备，如果可以提交事务，就将事务数据写入日志文件并向事务管理器返回一个“准备好”响应。
• 第二阶段（提交/回滚阶段）：如果所有资源管理器都报告准备好，则事务管理器指示它们提交事务。如果任何资源管理器不能提交事务，则事务管理器指示所有资源管理器回滚事务。

Seata XA 模式的实现使用了上述两阶段提交协议来确保分布式事务的原子性。在 Seata 中，TM 负责协调整个事务的提交或回滚，而 RM 则是分布式事务中各个数据库实例或其他事务资源。

Seata XA 模式的优点：

• 一致性：通过使用 2PC 确保事务的强一致性。
• 遵循标准：XA 协议是一个成熟的、经过广泛验证的分布式事务协议。

Seata XA 模式的缺点：

• 性能成本：由于涉及多个阶段和网络往返，性能可能低于其他轻量级事务协议（如AT模式）。
• 锁资源：在两阶段提交过程中，会在涉及的资源上持有锁，可能导致资源锁定时间较长。

使用场景：

Seata XA 模式适合于对数据一致性要求极高的场景，以及对性能要求不是非常敏感的环境。由于它提供了强一致性保证，因此常用于金融、支付等领域的应用。

1.3 AT模式

Seata AT模式（Automatic Transaction Mode）是Seata提供的一种创新的分布式事务解决方案，它不同于传统的XA模式。AT模式旨在通过一种轻量级的方式，提供高性能且易于使用的分布式事务能力。AT模式主要针对关系型数据库的分布式事务处理。

AT模式的工作原理：

AT模式通过以下三个核心组件来管理分布式事务的生命周期：

1. 事务协调器（TC，Transaction Coordinator）： TC是分布式事务的协调者，负责维护全局事务的状态，并驱动全局事务的提交或回滚。

2. 事务管理器（TM，Transaction Manager）： TM负责定义事务的范围，即开始和结束全局事务的边界，它会在适当的时机向TC注册并报告全局事务的状态。

3. 资源管理器（RM，Resource Manager）： RM负责管理分布式事务中涉及的资源，通常是数据库连接。它将具体的数据库操作与TC进行通信，并接受TC的指令来提交或回滚分支事务。

AT模式的事务处理过程：

AT模式通过以下步骤来处理事务：

1. 开始全局事务： 当应用需要执行分布式事务时，TM向TC发起一个新的全局事务，并获得一个全局事务ID（XID）。

2. 业务执行： 在执行业务操作时，每个数据库操作都被看作是全局事务的一个分支。RM负责拦截数据操作请求，并执行两件事情：一是在本地数据库中执行实际的SQL操作；二是记录数据操作前后的状态差异，称为before image和after image，用于后续的事务提交或回滚。

3. 请求事务提交： 业务执行完毕后，TM会向TC请求提交全局事务。

4. TC驱动二阶段提交/回滚： 在第一阶段，TC会询问所有参与当前全局事务的RM是否准备好提交事务。如果所有RM都报告准备就绪，TC将进入第二阶段，指示所有RM提交分支事务。 如果任何一个RM报告准备失败，或者业务逻辑中发生异常导致TM请求回滚全局事务，TC则会指示所有RM回滚分支事务。

5. 事务回滚处理： 如果分支事务需要回滚，RM会使用记录的before image来撤销之前的操作，确保数据的一致性。

AT模式的优点：

• 高性能：与XA模式相比，AT模式不需要两阶段锁定资源，因此可以减少锁的竞争，提高性能。
• 简单易用：AT模式对开发者更加友好，避免了XA中复杂的API和协议。

AT模式的缺点：

• 资源占用：由于需要记录数据修改的前后镜像，会增加存储的消耗。
• 数据一致性：在某些极端情况下，例如服务宕机或网络分区，可能会暂时出现数据不一致的情况。

AT模式适用于需要处理高并发事务，且对一致性要求不是极端严格的分布式系统。它能够很好地平衡分布式事务的性能和一致性需求。在实际部署Seata和使用AT模式之前，建议对Seata的架构和工作机制有一个深入的理解，并进行充分的测试以确保它适合你。

1.4 AT模式的的原理

如何工作的？

1. 全局事务的开始：当应用 A 的操作被 @GlobalTransactional 注解标记时，Seata 会开始一个全局事务，并创建一个全局事务 ID。

2. 事务上下文传递：应用 A 调用应用 B 时，Seata 的客户端会自动将全局事务 ID 和其他事务上下文信息通过 RPC 调用传递给应用 B。

3. 参与全局事务：应用 B 接收到全局事务 ID 后，如果它进行数据库操作，那么这些操作将会被 Seata 拦截，确保它们在全局事务的上下文中执行。这就意味着，应用 B 虽然没有显式地使用 @GlobalTransactional，但它的数据库操作仍然会参与到全局事务中。

4. 资源注册与分支事务：应用 B 的数据库操作将作为一个分支事务注册到 Seata 服务器。全局事务由主事务和多个分支事务组成，它们共同构成了完整的业务逻辑。

5. 全局事务的提交或回滚：当主事务（应用 A）完成所有逻辑，根据执行结果，Seata 会决定提交或回滚全局事务。如果提交，所有参与该全局事务的分支事务也将被提交；如果回滚，所有分支事务也将回滚。

这意味着， 如果应用A调用应用B，如果A开启全局事务，  只要B有 @Transactional 注解（只要有事务操作，没有任何注解同样，待验证），它也可以通过 Seata 的事务上下文传递机制参与到应用 A 的全局事务中。这是因为，Seata 通过全局事务 ID 和事务上下文的传递，确保所有相关的微服务调用都在同一个全局事务的范围内执行。这种机制有效地实现了跨服务的分布式事务管理。

拦截原理？

Seata 底层通过数据源代理和资源管理器来实现对数据库操作的拦截。当你在应用中集成了 Seata，并配置了它的数据源代理，Seata 会在事务执行过程中拦截数据库操作的原理如下：

1. 数据源代理:

   • 在 Seata 中，数据源代理是对真实数据源（如 JDBC 数据源）的一个代理封装。
   • 当应用启动后，并且已经将 Seata 的数据源代理配置为数据源时，所有通过该数据源进行的数据库操作都会被代理拦截。

2. 全局事务 ID 传递:

   • 在分布式事务的上下文中，全局事务 ID 是标识整个事务的唯一键。
   • 通过 RPC 调用（如 Feign、Dubbo）时，全局事务 ID 和其他相关信息会通过请求头等方式传递给下游服务。

3. 资源管理器:

   • Seata 维护了一个资源管理器，用于注册和管理事务分支。
   • 当应用 B 的 Seata 数据源代理拦截一个数据库操作时，它会通过资源管理器向 Seata 服务端报告，并注册一个新的事务分支。
   • 资源管理器负责协调全局事务和分支事务的提交或回滚。

4. 事务拦截与封装:

   • 拦截数据库操作后，Seata 会将这些操作封装为分支事务，并记录下来，以便在全局事务提交或回滚时能够统一进行处理。
   • Seata 会创建一个临时的分支事务日志记录在数据库中，以跟踪每个分支事务的状态。

5. 分支事务处理:

   • 对于每个分支事务，Seata 会记录其前镜像（Before Image）和后镜像（After Image）。
   • 前镜像用于在回滚时恢复数据，后镜像用于在提交时确定数据变更。

6. 全局事务提交或回滚:

   • 当全局事务发起者决定提交或回滚时，Seata 会协调所有分支事务一起提交或回滚。
   • 如果是提交，Seata 会确保所有分支事务的本地事务被提交。
   • 如果是回滚，Seata 会使用前镜像将数据恢复到全局事务开始之前的状态。

如果应用 A 没有开启全局事务（没有使用 @GlobalTransactional 注解），但是调用了应用 B，而应用 B 开启了全局事务（使用了 @GlobalTransactional 注解），则事务的行为将会以应用 B 为中心。在这种情况下，应用 B 的全局事务将不会自动包含应用 A 的任何数据库操作，因为全局事务的上下文是在应用 B 中创建的。这里是一个简要的概述：

1. 应用 A 的操作:

   • 应用 A 中的操作将被视为普通的本地事务或者非事务操作，这取决于应用 A 是否使用了本地的 @Transactional 注解或者其他事务控制机制。
   • 应用 A 的数据库操作将不会被 Seata 管理，因为没有全局事务上下文被创建。

2. 调用应用 B:

   • 当应用 A 调用应用 B 时，应用 B 中的 @GlobalTransactional 注解将启动一个新的全局事务。
   • 由于应用 A 没有在全局事务中，因此其调用不会传递任何全局事务上下文给应用 B。

3. 应用 B 的全局事务:

   • 应用 B 中，随着 @GlobalTransactional 注解的执行，Seata 将创建一个全局事务 ID，并管理应用 B 内的所有数据库操作。
   • 如果应用 B 进一步调用其他应用（如应用 C），并且这些应用集成了 Seata，那么这些应用的操作也将成为应用 B 全局事务的一部分。

4. 事务的提交或回滚:

   • 应用 B 作为全局事务的发起者，将决定何时提交或回滚全局事务。
   • 只有应用 B（以及它调用的其他应用，如果它们已集成 Seata 并且接收到了全局事务上下文）内的操作会在全局事务中被提交或回滚。应用 A 的操作将不受影响，因为它们不在全局事务的上下文中。

总结: 在这个例子中，应用 A 和应用 B 的事务是分离的。应用 A 的数据库操作不会参与到应用 B 的全局事务中，因为全局事务的上下文是在调用链的下游应用 B 中创建的。如果应用 A 需要将其操作包含在全局事务中，那么它也需要使用 @GlobalTransactional 注解来创建或参与全局事务，并确保全局事务 ID 能够在调用链中传递到应用 B。

在设计微服务架构中的事务策略时，需要仔细规划哪些服务应该负责全局事务的管理，以及如何传播和维护事务上下文。

1.5 分布式事务支持REQUIRES_NEW吗？

在 Seata 和其他分布式事务解决方案中，并没有与 Spring 本地事务传播特性完全对应的概念。在 Spring 本地事务中，Propagation.REQUIRES_NEW 表示当前方法不管外部是否存在事务都会创建一个新的事务，并在该方法执行结束后提交或回滚该事务。

然而，在 Seata 的分布式事务环境中，事务传播机制的行为有所不同，原因如下：

1. 全局事务上下文：

   • Seata 通过全局事务上下文来管理和维护全局事务及其分支事务。
   • 当一个服务方法被 @GlobalTransactional 注解标记时，Seata 会为该方法创建一个全局事务。

2. 分支事务创建：

   • 在全局事务中，当调用其他服务或方法时，Seata 会创建一个分支事务，这个分支事务是全局事务的一部分。
   • 分支事务并不是独立的事务，而是隶属于全局事务，全局事务决定了所有分支事务的最终提交或回滚。

3. 事务传播行为：

   • 在 Seata 中，即使一个方法尝试使用类似于 Propagation.REQUIRES_NEW 的行为，它仍然会被包含在当前的全局事务中而不是创建一个全新的事务。
   • Seata 目前不支持在一个全局事务中创建一个独立的事务，所有操作都是在全局事务的上下文中进行的。

如果你想在 Seata 环境中模拟 Propagation.REQUIRES_NEW 的行为，可以考虑以下几点：

• 异步处理：将需要新事务的操作放在异步方法中执行，这样它们可以在不同的线程中运行，与主全局事务相隔离。
• 本地事务模式：在 Seata 的全局事务之外执行需要新事务的方法，例如，通过手动管理事务或使用本地事务注解而不是 @GlobalTransactional。
• 使用嵌套事务：对于支持嵌套事务的数据库，你可以创建一个嵌套事务分支，但请注意，这仍然属于全局事务的范畴。

请记住，Seata 的主要目的是管理分布式事务，因此在设计事务策略时，考虑全局事务的一致性和隔离性是至关重要的。如果有必要在分布式事务中模拟 REQUIRES_NEW 的行为，建议审慎考虑设计策略，并确保理解这种做法对事务完整性的潜在影响。

2、SringBoot整合seata

参考：

Spring Boot 集成Seata_springboot整合seata-CSDN博客