seata xid是什么_又见分布式事务之阿里开源Seata

最新推荐文章于 2024-07-29 17:57:21 发布

weixin_40002611

最新推荐文章于 2024-07-29 17:57:21 发布

阅读量163

点赞数

文章标签： seata xid是什么

本文链接：https://blog.csdn.net/weixin_40002611/article/details/112278182

版权

Seata是一款由阿里巴巴开源的分布式事务解决方案，它实现了业务层面的无侵入分布式事务处理。Seata通过TM（事务管理器）、TC（事务协调器）和RM（资源管理器）三个组件，使得在微服务架构中操作分布式事务如同本地事务一样简单。Seata使用全局事务和分支事务的概念，每个分支事务是一个满足ACID的本地事务，通过UNDO_LOG表记录回滚数据，实现即使在第一阶段也能直接提交事务。在Seata的AT模式下，它依赖数据库的ACID特性，而MT模式则允许对业务有入侵的自定义操作。

摘要由CSDN通过智能技术生成

欢迎关注头条号：老顾聊技术

精品原创技术分享，知识的组装工

前言

分布式微服务中事务问题，是一直困扰着大家的。之前老顾已经介绍过如何利用rocketmq的事务消息解决事务问题，今天老顾再来介绍另一个方案；提供小伙伴们另一个选择。

解决方案有哪些？

分布式事务方案大致分为对业务无侵入型和有侵入型。

无侵入型的方案有基于数据库的XA协议的两阶段提交，它的优点对业务无侵入，缺点也很明显；数据库必须支持XA协议，且支持XA协议对性能的影响很大，因为它会造成事务资源长时间得不到释放。数据库的吞吐量极低。

为了解决这个问题，就出来了很多业务层面的实现二阶段的提交方案，如：很出名的 TCC 方案，基于 TCC 也有很多成熟的框架，如 ByteTCC、tcc-transaction。

另一种就是最终一致性的方案，如：rocketmq事务消息。

但上面的TCC方案、或者最终一致性方案都会涉及到业务代码的改造，对业务有侵入。

下面我们来介绍一下今天的主角。

Seata

Seata的分布式事务解决方案是业务层面的解决方案，业务层上无需关心分布式事务机制的约束，它将给我们的微服务架构带来质的提升，只依赖于单台数据库的事务能力。

Seata 的设计思路是将一个分布式事务可以理解成一个全局事务，下面挂了若干个分支事务，而一个分支事务是一个满足 ACID 的本地事务，因此我们可以操作分布式事务像操作本地事务一样。

Seata 内部定义了 3个模块来处理全局事务和分支事务的关系和处理过程，这三个组件分别是：

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

其中，TM是一个分布式事务的发起者和终结者，TC负责维护分布式事务的运行状态，而RM则负责本地事务的运行。如下图所示：

下面是一个分布式事务在Seata中的执行流程：

1)TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。2)XID 在微服务调用链路的上下文中传播。3)RM 向 TC 注册分支事务，接着执行这个分支事务并提交(重点：RM在第一阶段就已经执行了本地事务的提交/回滚)，最后将执行结果汇报给TC。4)TM 根据 TC 中所有的分支事务的执行情况，发起全局提交或回滚决议。5)TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

分支事务为什么能直接提交？

Seata能够在第一阶段直接提交事务，是因为Seata框架为每一个RM维护了一张UNDO_LOG表(这张表需要客户端自行创建)，其中保存了每一次本地事务的回滚数据。因此，二阶段的回滚并不依赖于本地数据库事务的回滚，而是RM直接读取这张UNDO_LOG表，并将数据库中的数据更新为UNDO_LOG中存储的历史数据。

如果第二阶段是提交命令，那么RM事实上并不会对数据进行提交(因为一阶段已经提交了)，而实发起一个异步请求删除UNDO_LOG中关于本事务的记录。

原理就是先保存之前的老数据，一旦出现异常，就是把老数据再更新回去。

Seata执行流程

下面是一个Seata中一个分布式事务执行的详细过程：

1)首先TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。

2)XID 在微服务调用链路的上下文中传播。

3)RM 开始执行这个分支事务，RM首先解析这条SQL语句，生成对应的UNDO_LOG记录。下面是一条UNDO_LOG中的记录：

{    "branchId": 641789253,    "undoItems": [{        "afterImage": {            "rows": [{                "fields": [{                    "name": "id",                    "type": 4,                    "value": 1                }, {                    "name": "name",                    "type": 12,                    "value": "GTS"                }, {                    "name": "since",                    "type": 12,                    "value": "2014"                }]            }],            "tableName": "product"        },        "beforeImage": {            "rows": [{                "fields": [{                    "name": "id",                    "type": 4,                    "value": 1                }, {                    "name": "name",                    "type": 12,                    "value": "TXC"                }, {                    "name": "since",                    "type": 12,                    "value": "2014"                }]            }],            "tableName": "product"        },        "sqlType": "UPDATE"    }],    "xid": "xid:xxx"}

可以看到，UNDO_LOG表中记录了分支ID，全局事务ID，以及事务执行的redo和undo数据以供二阶段恢复。

4)RM在同一个本地事务中执行业务SQL和UNDO_LOG数据的插入。在提交这个本地事务前，RM会向TC申请关于这条记录的全局锁。如果申请不到，则说明有其他事务也在对这条记录进行操作，因此它会在一段时间内重试，重试失败则回滚本地事务，并向TC汇报本地事务执行失败。如下图所示：