分布式事务-CSDN博客

本文链接：https://blog.csdn.net/qq_62877881/article/details/146963356

分布式事务

在分布式系统当中如果一个业务需要多个服务合作完成，每一个服务都有事务，多个事务必须同时成功或者失败，这样的事务就是**分布式事务**。

解决方案

使各个子事务之间能感知到彼此的事务状态，保证一致性。

Seata架构

三个重要角色:
在这里插入图片描述

TC（Transcation Coordinator) 事务协调者：
- 维护事务状态，协调全局事务提交或回滚。
TM（Transcation Manager）事务管理器：
- 定义全局事务范围、开始全局事务、提交或回滚全局事务。
RM（Resource Manager）资源管理器：
- 管理分支事务，与TC交谈一注册和报告分支事务状态。

Seata 架构工作流程

全局事务开始：TM 发起全局事务，向 TC 注册事务并获取 XID。XID 会在后续的服务调用中传播，用于标识该全局事务。
分支事务注册：涉及到的各个服务中的 RM 感知到全局事务的传播（通过 XID），将本地的业务操作注册为分支事务，并向 TC 进行注册，关联到对应的全局事务。
业务执行：各个 RM 按照业务逻辑执行本地分支事务，对本地资源进行操作，并记录操作日志等信息。
事务协调决策：所有分支事务执行完成后，TM 根据业务结果决定提交或回滚全局事务，并向 TC 发送相应请求。TC 收到请求后，根据各个 RM 上报的分支事务状态，决定是否进行全局事务的提交或回滚。如果所有分支事务都成功，TC 发起全局事务提交指令；若有任何一个分支事务失败，TC 发起全局事务回滚指令。
分支事务处理：RM 收到 TC 的提交或回滚指令后，执行相应操作。对于提交指令，RM 提交本地分支事务；对于回滚指令，RM 根据之前记录的操作日志，回滚本地分支事务，确保整个分布式系统的数据一致性。

Seata不同的分布式事务解决方案：

XA模式

1. XA 模式概述

XA（eXtended Architecture）是由 X/Open 组织提出的分布式事务处理（DTP，Distributed Transaction Processing）标准，旨在解决跨多个资源管理器（如数据库、消息队列等）的事务一致性问题。在 Seata 框架中，XA 模式是其支持的分布式事务处理模式之一，它利用数据库本身提供的 XA 协议来实现分布式事务。

2. Seata XA 模式中的角色

事务协调器（TC）：与 Seata 其他模式中的 TC 功能类似，负责维护全局事务的状态，协调全局事务的提交或回滚。它接收事务管理器（TM）的全局事务开始、提交或回滚请求，并向各个资源管理器（RM）发送相应的指令。
事务管理器（TM）：定义全局事务的范围，发起全局事务的开始、提交或回滚操作。TM 与 TC 交互，获取全局事务的唯一标识（XID），并在业务逻辑中传递该标识。
资源管理器（RM）：通常是数据库，支持 XA 协议。RM 负责管理本地资源（如数据库连接），并根据 TC 的指令执行分支事务的准备、提交或回滚操作。

3. Seata XA 模式的工作流程

（1）全局事务开始

TM 向 TC 发起全局事务开始请求，TC 为该全局事务分配一个唯一的 XID。
TM 将 XID 传递给参与该全局事务的各个业务服务。

（2）分支事务执行

每个业务服务中的 RM 接收到带有 XID 的业务请求后，开启一个本地的 XA 事务。
RM 执行具体的业务操作，如数据库的增删改查操作。这些操作在 XA 事务的上下文中进行，确保数据的一致性。

（3）准备阶段（Prepare Phase）

TC 向所有参与全局事务的 RM 发送“准备”指令。
每个 RM 执行本地事务的准备操作，将本地事务的操作结果持久化到磁盘（通常是写日志），但不提交事务。如果准备操作成功，RM 向 TC 报告“准备就绪”；如果出现错误，RM 向 TC 报告“准备失败”。

（4）提交/回滚阶段（Commit/Rollback Phase）

提交情况：如果所有 RM 都报告“准备就绪”，TC 向所有 RM 发送“提交”指令。每个 RM 收到指令后，正式提交本地事务，完成数据的持久化。
回滚情况：如果有任何一个 RM 报告“准备失败”，TC 向所有 RM 发送“回滚”指令。每个 RM 收到指令后，回滚本地事务，撤销之前的操作，保证数据的一致性。

4. 优缺点

优点

强一致性：XA 模式基于数据库的 XA 协议，能够保证在分布式环境下的强一致性。所有参与事务的资源要么全部提交，要么全部回滚，不存在部分提交的情况。
数据库原生支持：大多数主流数据库（如 MySQL、Oracle 等）都支持 XA 协议，无需额外开发复杂的补偿逻辑，降低了开发成本。

缺点

性能开销大：由于 XA 模式采用两阶段提交协议，在准备阶段和提交/回滚阶段都需要与各个 RM 进行交互，会产生较大的网络延迟和资源锁定时间。在高并发场景下，性能可能会受到较大影响。
资源锁定时间长：在准备阶段，RM 会对本地资源进行锁定，直到收到提交或回滚指令。这可能会导致其他事务等待资源，降低系统的并发性能。

5. 实现

@GlobalTransactional 注解

6. 适用场景

对数据一致性要求极高的场景：如金融交易系统，涉及资金的转账、结算等操作，必须保证数据的强一致性，避免出现资金不一致的问题。
数据库支持 XA 协议且并发量相对较低的场景：当数据库支持 XA 协议，并且系统的并发量不是特别高时，XA 模式可以作为一种简单有效的分布式事务解决方案。

AT模式

1. AT模式概述

AT（Automatic Transaction）模式是 Seata 提供的一种无侵入的分布式事务解决方案。它致力于在微服务架构下，以自动化的方式保障分布式事务的一致性，同时尽量减少对业务代码的侵入。其核心思想是利用数据库的快照技术，在业务操作前后分别记录数据的状态，以此来实现事务的回滚和提交。

2. Seata AT 模式中的角色

事务协调器（TC）：作为 Seata 架构的核心组件，负责维护全局事务的状态。它接收事务管理器（TM）发起的全局事务开始、提交或回滚请求，记录全局事务的执行状态，并根据这些状态向资源管理器（RM）发送相应的指令，协调各个分支事务的执行。
事务管理器（TM）：在业务系统中定义全局事务的范围。当业务需要进行分布式事务处理时，TM 向 TC 注册全局事务并获取全局唯一的事务 ID（XID）。之后，根据业务逻辑的执行结果，决定是向 TC 发送全局事务提交还是回滚的请求。
资源管理器（RM）：主要负责管理本地资源（如数据库）。在 AT 模式下，RM 会拦截业务对资源的操作，自动生成数据的前后镜像（快照）。在分支事务执行过程中，RM 与 TC 进行交互，注册分支事务并上报其状态，同时根据 TC 的指令完成分支事务的提交或回滚操作。

3. Seata AT 模式的工作流程

（1）全局事务开始

TM 向 TC 发起全局事务开始请求，TC 为该全局事务分配一个唯一的 XID。
TM 将 XID 传递给参与该全局事务的各个业务服务。

（2）分支事务执行（一阶段）

业务 SQL 执行：RM 拦截业务代码中的 SQL 操作。在执行 SQL 之前，RM 会根据 SQL 语句的条件查询当前数据的状态，生成“before image”（前镜像）。
业务数据更新：执行具体的业务 SQL 语句，对数据库中的数据进行更新。
生成 after image：更新完成后，RM 再次查询更新后的数据状态，生成“after image”（后镜像）。
记录日志：RM 将前镜像、后镜像以及业务 SQL 等信息记录到 UNDO_LOG 表中，同时向 TC 注册分支事务并报告执行状态。

（3）全局事务提交（二阶段）

异步提交：当所有分支事务都成功执行后，TM 向 TC 发送全局事务提交请求。TC 向各个 RM 发送分支事务提交指令。RM 收到指令后，会异步删除相应的 UNDO_LOG 记录，释放对资源的锁定，完成分支事务的提交。由于是异步操作，所以整体的提交过程效率较高。

（4）全局事务回滚（二阶段）

回滚操作：如果在全局事务执行过程中出现异常，TM 向 TC 发送全局事务回滚请求。TC 向各个 RM 发送分支事务回滚指令。RM 收到指令后，根据 UNDO_LOG 表中的前镜像和后镜像信息，生成反向 SQL 语句，将数据恢复到事务执行前的状态，完成分支事务的回滚。

4. 优缺点

优点

无侵入性：AT 模式对业务代码的侵入极小，开发人员只需要关注业务逻辑的实现，无需手动编写复杂的事务补偿逻辑。
高性能：在一阶段提交时，业务数据和回滚日志是同时写入数据库的，二阶段提交时采用异步操作，减少了事务的锁定时间，提高了系统的并发性能。
自动补偿：在全局事务回滚时，RM 能够根据 UNDO_LOG 自动生成反向 SQL 进行数据恢复，保证数据的一致性。

缺点

数据库支持要求高：AT 模式依赖于数据库的事务和 SQL 解析能力，需要数据库支持行级锁和 SQL 解析，目前主要支持关系型数据库，如 MySQL、Oracle 等。
数据隔离问题：在高并发场景下，可能会出现数据隔离问题，例如脏读、幻读等。

5. 实现

@GlobalTransactional 注解用于开启 Seata 的全局事务，给每一个数据库新增undo-log表。

6. 适用场景

业务逻辑简单、对性能要求较高的场景：由于 AT 模式无需手动编写复杂的补偿逻辑，且性能较高，适合于业务逻辑相对简单、对系统并发性能要求较高的场景，如电商系统中的订单创建、库存扣减等操作。
基于关系型数据库的分布式系统：AT 模式主要依赖于关系型数据库的事务和 SQL 解析能力，因此适用于基于关系型数据库构建的分布式系统。