问小白 wenxiaobai
资讯
历史
科技
环境与自然
成长
游戏
财经
文学与艺术
美食
健康
家居
文化
情感
汽车
三农
军事
旅行
运动
教育
生活
星座命理

分布式事务框架Seata

创作时间:
作者:
@小白创作中心

分布式事务框架Seata

引用
1
来源
1.
https://www.cnblogs.com/hld123/p/18268706

分布式事务框架Seata

概要
Seata(Simple Extensible Autonomous Transaction Architecture)是阿里巴巴开源的一款分布式事务解决方案,主要用于解决微服务架构中的分布式事务问题。Seata 提供了多种事务模式,如 AT(Automatic Transaction)、TCC(Try-Confirm-Cancel)、Saga 和 XA,适用于不同的业务场景.
Seata是Java领域很强大的分布式事务框架,其中默认支持的AT模式,相比于传统的2PC协议(基于数据库的XA协议),很好地解决了2PC长期锁资源的问题,提高了并发度。

一、Seata的系统组成
Seata有三个核心组件:

  • Transaction Coordinator(TC,事务协调器)—— 维护全局事务和分支事务的状态,驱动全局事务提交或回滚。
  • Transaction Manager(TM,事务管理器) —— 定义全局事务的范围,开始事务、提交事务、回滚事务。
  • Resource Manager(RM,资源管理器):—— 管理分支事务上的资源,向TC注册分支事务,汇报分支事务状态,驱动分支事务的提交或回滚。

三个组件相互协作,TC 以 Server 形式独立部署,TM 和 RM集成在应用中启动,其整体交互如下图:

1 ① TM 请求 TC, 开始一个新的全局事务,TC 会为这个全局事务生成一个 唯一XID
2 ② XID 通过微服务的调用链传递到其他微服务。
3 ③ RM 向TC 注册分支事务, 将其纳入XID 对应全局事务的管辖 ;
4 ④ TM 请求 TC 对这个 XID 进行提交或回滚
5 ⑤ TC 指挥这个 XID 下面的所有分支事务进行提交、回滚。

说明:XID(Transaction ID)是用于标识全局事务的唯一标识符。这通常包含 TC 的 IP 地址、端口号以及一个全局唯一的事务 ID。

比如:192.168.1.100:8091:20210408123456789

二、Seata的事务模式
Seata中常用的有两种分布式事务实现方案,AT及TCC。

  • 1)AT模式主要关注多 DB 访问的数据一致性,当然也包括多服务下的多 DB 数据访问一致性问题

  • 2)TCC 模式主要关注业务拆分,在按照业务横向扩展资源时,解决微服务间调用的一致性问题

这里我们关注常用的AT模式 (业务侵入小)。

三、Seata的AT模式
Seata AT模式是基于XA事务演进而来的一个分布式事务中间件,XA是一个基于数据库实现的分布式事务协议,本质上和两阶段提交一样,需要数据库支持,MySQL5.5及以上版本支持XA协议,其他数据库如Oracle,DB2也实现了XA接口。

  1. AT模式第一阶段

Seata 的JDBC 数据源代理通过对业务 SQL 的解析,把业务数据在更新前后的数据镜像组织成回滚日志,利用 本地事务 的 ACID 特性,将业务数据的更新和回滚日志的写入在同一个本地事务中提交。

这样,可以保证:任何提交的业务数据的更新一定有相应的回滚日志存在

如下图:

基于这样的机制,分支的本地事务便可以在全局事务的第一阶段提交,并马上释放本地事务锁定的资源。

这也是Seata和XA事务的不同之处:经典的2PC两阶段提交(XA)往往对资源的锁定需要持续到第二阶段实际的提交或者回滚操作。

也就是说:AT模式,可以在第一阶段释放对资源的锁定,降低了锁范围。这都要归功于回滚日志。

  1. AT模式第二阶段

1)场景一:提交,全局提交

如果决议是全局提交,此时分支事务此时已经完成提交,不需要同步协调处理(只需要异步清理回滚日志),Phase2 可以非常快速地完成。

如下图:

场景2:回滚,全局回滚

如果决议是全局回滚,RM 收到协调器发来的回滚请求,通过 XID 和 Branch ID 找到相应的回滚日志记录,通过回滚记录生成反向的更新 SQL 并执行,以完成分支的回滚。

如下图:

  1. AT模式相对于XA模式的优势

如下图:

说明:

  • 提高效率,即使第二阶段发生异常需要回滚,只需找对undolog中对应数据并反解析成sql来达到回滚目的

  • Seata无入侵,通过代理数据源将业务sql的执行解析成undolog来与业务数据的更新同时入库,达到了对业务无侵入的效果

四、Seata使用场景

Seata 在一些大型互联网企业和金融机构的项目中使用较多,但在普通企业或小型项目中,使用率相对较低。

这主要是由于以下原因:

  1. 复杂度

Seata 引入了较高的复杂度,需要开发团队对分布式事务有较深的理解,并且需要一定的运维能力。

  1. 性能开销

分布式事务往往伴随着性能开销,尤其是在高并发场景下,可能影响系统性能。

  1. 业务需求

并不是所有业务场景都需要分布式事务,很多业务可以通过其他方式(如消息队列、事件驱动、最终一致性)解决数据一致性问题。

参考链接:

https://www.cnblogs.com/crazymakercircle/p/15313875.html

© 2023 北京元石科技有限公司 ◎ 京公网安备 11010802042949号