分布式事务中间件 Seata 理论详解
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式事务中间件 Seata 理论详解相关的知识,希望对你有一定的参考价值。
简介
Seata 是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。 Seata 为用户提供了 AT、TCC、SAGA 和 XA 事务模式,为用户打造一站式的分布式解决方案。
Seata 的设计思路是将一个分布式事务理解成一个全局事务,下面挂了若干个分支事务,而一个分支事务是一个满足 ACID 的本地事务,因此我们可以像操作本地事务一样操作分布式事务。
Seata 内部定义了 3 个模块来处理全局事务和分支事务的关系和处理过程,这三个组件分别是:
- Transaction Coordinator (TC): 事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚。
- Transaction Manager (TM): 控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议。
- Resource Manager (RM): 控制分支事务,负责分支注册、状态汇报,并接收事务协调器的指令,驱动分支(本地)事务的提交和回滚。
seata中一个分布式事务的生命周期如下: 简单说整个全局事务的执行步骤:
- TM 向 TC 申请开启一个全局事务,TC 创建全局事务后返回全局唯一的 XID,XID 会在全局事务的上下文中传播;
- RM 向 TC 注册分支事务,该分支事务归属于拥有相同 XID 的全局事务;
- TM 向 TC 发起全局提交或回滚;
- TC 调度 XID 下的分支事务完成提交或者回滚。
支持模式
Seata AT 模式
两阶段提交协议的演变: 第一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源。核心在于对业务sql进行解析,转换成undolog,并同时入库。 第二阶段:
- 分布式事务操作成功,则TC通知RM异步删除undolog
- 分布式事务操作失败,TM向TC发送回滚请求,RM收到协调器TC发来的回滚请求,通过XID和Branch lD找到相应的回滚日志记录,通过回滚记录生成反向的更新SQL并执行,以完成分支的回滚。
Seata TCC 模式
整体是两阶段提交的模型。 全局事务是由若干分支事务组成的,分支事务要满足 两阶段提交 的模型要求,即需要每个分支事务都具备自己的: 一阶段 prepare 行为 二阶段 commit 或 rollback 行为
Seata Saga 模式
目前 SEATA 提供的 Saga 模式是基于状态机引擎来实现的,机制是: 通过状态图来定义服务调用的流程并生成 json 状态语言定义文件。 状态图中一个节点可以是调用一个服务,节点可以配置它的补偿节点。 状态图 json 由状态机引擎驱动执行,当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚。 可以实现服务编排需求,支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能。
Seata XA 模式
利用事务资源(数据库、消息服务等)对 XA 协议的支持,以 XA 协议的机制来管理分支事务的一种 事务模式。 执行阶段: -M可回滚:业务 SQL 操作放在 XA 分支中进行,由资源对 XA 协议的支持来保证可回滚。
- 持久化:XA 分支完成后,执行 XA prepare,同样,由资源对 XA 协议的支持来保证持久化(即,之后任何意外都不会造成无法回滚的情况)。
完成阶段:
- 分支提交:执行 XA 分支的 commit
- 分支回滚:执行 XA 分支的 rollback
以上是关于分布式事务中间件 Seata 理论详解的主要内容,如果未能解决你的问题,请参考以下文章
分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾