分布式事务框架-seata初识

摘自:https://www.cnblogs.com/iceggboom/p/12144570.html

分布式事务框架-seata初识

一、事务与分布式事务

事务,在数据库中指的是操作数据库的最小单位,往大了看,事务是应用程序中一系列严密的操作,所有操作必须成功完成,否则在每个操作中所作的所有更改都会被撤消。

那为什么会有分布式事务呢?单机事务是通过将操作限制在一个会话内通过数据库本身的锁以及日志来实现ACID.因为引入了分布式架构,所以事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.简单说就是多各数据库之间无法保证保证各自的操作同时成功或同时失败。

二、介绍

Seata:Simple Extensible Autonomous Transaction Architecture,简易可扩展的自治式分布式事务管理框架,其前身是fescar。阿里巴巴GTS的开源版实现,是一种分布式事务的解决方案。

三、架构

  • Coordinator Core:最下面的模块是事务协调器核心代码,主要用来处理事务协调的逻辑,如是否 Commit、Rollback 等协调活动。
  • Store:存储模块,用来将我们的数据持久化,防止重启或者宕机数据丢失。
  • Discover:服务注册/发现模块,用于将 Server 地址暴露给 Client。
  • Config:用来存储和查找服务端的配置。
  • Lock:锁模块,用于给 Seata 提供全局锁的功能。
  • Rpc:用于和其他端通信。
  • HA-Cluster:高可用集群,目前还没开源。为 Seata 提供可靠的高可用功能。

四、工作流程

1)参与角色

Transaction Coordinator(TC):管理全局的分支事务的状态,用于全局性事务的提交和回滚。
Transaction Manager(TM):事务管理器,用于开启全局事务、提交或者回滚全局事务,是全局事务的开启者。
Resource Manager(RM):资源管理器,用于分支事务上的资源管理,向TC注册分支事务,上报分支事务的状态,接受TC的命令来提交或者回滚分支事务。

2)流程

  1. TM向TC请求发起一个全局事务,TC返回一个代表这个全局事务的XID。
  2. XID在rpc中传播给每一个调用链中的服务。
  3. 每个RM拿到XID后向TC发起一个分支事务,TC返回一个代表这个分支事务的XID。
  4. RM完成本地分支的业务,提交本地分支,并且报告给TC。
  5. 全局事务调用链处理完毕,TM根据有无异常向TC发起全局事务的提交或者回滚。
  6. 假设某个RM本地事务失败。该RM自身驱动本地事务回滚,并且报告给TC。
  7. TM检测到了某个分支事务失败,向TC发起全局事务回滚。
  8. TC给每一个RM发送消息,通知它们全部回滚。
  9. TC将全局事务回滚的结果发送给TM,全局事务结束。

五、设计思想(重点)

Seata 的设计思路是将一个分布式事务可以理解成一个全局事务,下面挂了若干个分支事务,而一个分支事务是一个满足 ACID 的本地事务,因此我们可以操作分布式事务像操作本地事务一样。Seata 的事务提交方式跟 XA 协议的两段式提交在总体上来说基本是一致的,但XA 协议它依赖的是数据库层面来保障事务的一致性,也即是说 XA 的各个分支事务是在数据库层面上驱动的,由于 XA 的各个分支事务需要有 XA 的驱动程序,一方面会导致数据库与 XA 驱动耦合,另一方面它会导致各个分支的事务资源锁定周期长,所以性能较差。

Seata 在数据源做了一层代理层,所以我们使用 Seata 时,我们使用的数据源实际上用的是 Seata 自带的数据源代理 DataSourceProxy,Seata 在这层代理中加入了很多逻辑,主要是解析 SQL,把业务数据在更新前后的数据镜像组织成回滚日志,并将 undo log 日志插入 undo_log 表中,保证每条更新数据的业务 sql 都有对应的回滚日志存在。这样做的好处就是,本地事务执行完可以立即释放本地事务锁定的资源,然后向 TC 上报分支状态。当 TM 决议全局提交时,就不需要同步协调处理了,TC 会异步调度各个 RM 分支事务删除对应的 undo log 日志即可,这个步骤非常快速地可以完成;当 TM 决议全局回滚时,RM 收到 TC 发送的回滚请求,RM 通过 XID 找到对应的 undo log 回滚日志,然后执行回滚日志完成回滚操作。

六、其他模式

上面说的是seata的模式模式AT,seata也针对TCC做了适配兼容,支持TCC事务方案,原理前面已经介绍过,基本思路就是使用侵入业务上的补偿及事务管理器的协调来达到全局事务的一起提交及回滚。

七、总结

1)优点

  • 阿里背书,社区活跃,github1.3w start。
  • 相对2pc来说性能有较大提升,避免多个库锁定导致的性能急剧下降。
  • 使用简单,学习成本低,对业务无入侵,对于AT模式来说,只需一个注解就可以实现分布式事务。
  • 可通过HA-Cluster保证高可用。
  • 灵活,拓展性高,配置,服务发现和注册,全局锁,可由用户自己实现。

2)缺点

  • TC不支持集群部署,一旦TC宕机会导致无法处理分布式事务。
  • Seata的引入全局锁会额外增加死锁的风险。
  • 单机多数据源跨服务目前不支持。

原文地址:https://www.cnblogs.com/xichji/p/12147929.html

时间: 2024-10-29 04:39:26

分布式事务框架-seata初识的相关文章

Spring Cloud Alibaba | 微服务分布式事务之Seata

Spring Cloud Alibaba | 微服务分布式事务之Seata 本篇实战所使用Spring有关版本: SpringBoot:2.1.7.RELEASE Spring Cloud:Greenwich.SR2 Spring CLoud Alibaba:2.1.0.RELEASE 1. 概述 在构建微服务的过程中,不管是使用什么框架.组件来构建,都绕不开一个问题,跨服务的业务操作如何保持数据一致性. 2. 什么是分布式事务? 首先,设想一个传统的单体应用,无论多少内部调用,最后终归是在同一

基于Dubbo的分布式事务框架(LCN)

原文地址:http://原文地址:https://github.com/1991wangliang/transaction 该框架依赖Redis/dubbo/txManager服务.依赖第三方框架lorne_core 原理与功能 基于对spring tx PlatformTransactionManager的本地模块事务控制从而达到全局控制事务的目的.该框架兼容任何依赖PlatformTransactionManager的DB框架.利用三阶段提交的方式来确保事务的一致性,支持本地事务和分布式事务

tcc分布式事务框架解析

前言碎语 楼主之前推荐过2pc的分布式事务框架LCN.今天来详细聊聊TCC事务协议. 2pc实现:https://github.com/codingapi/tx-lcn tcc实现:https://github.com/yu199195/hmily 首先我们了解下什么是tcc,如下图 tcc分布式事务协议控制整体业务事务分为三个阶段. try:执行业务逻辑 confirm:确定业务逻辑执行无误后,确定业务逻辑执行完成 cancel:假如try阶段有问题,执行cancel阶段逻辑,取消try阶段的

如何实现一个TCC分布式事务框架的一点思考

一个TCC事务框架需要解决的当然是分布式事务的管理.关于TCC事务机制的介绍,可以参考TCC事务机制简介.http://www.bytesoft.org/tcc-intro TCC事务模型虽然说起来简单,然而要基于TCC实现一个通用的分布式事务框架,却比它看上去要复杂的多,不只是简单的调用一下Confirm/Cancel业务就可以了的. 本文将以Spring容器为例,试图分析一下,实现一个通用的TCC分布式事务框架需要注意的一些问题. 一.TCC全局事务必须基于RM本地事务来实现全局事务 TCC

分布式事务框架选型

个人发展建议:研究源码,知核心,知原理,清楚了解细节,甚至改造,自己写!! 阿里Fescar(GTS开源版本,GTS有阿里云服务)官方中文:https://github.com/alibaba/fescar/wiki/Home_Chinese 开源消息和与其他分布式框架(ByteTCC.LCN)对比:https://blog.csdn.net/xlgen157387/article/details/86289066 介绍和对比:https://blog.csdn.net/weixin_39800

阿里分布式事务seata入门(采坑)

1. 阿里分布式事务seata入门(采坑) 1.1. 前言 seata是feascar改名而来,这是阿里在19年年初开源出来的分布式事务框架,当初刚出来的时候就想研究下了,一直拖到了现在,目前是0.8.0版本,看版本就知道这还是个比较新的项目,但现在已经有上万个Star了,可见阿里的影响力.但是虽然有阿里背书,该挖坑还得挖,它宣称集成它比较简单,导致的是现在它的文档优点残缺不全,好几个文档标题点进去都没内容,不知道为什么删了,可能是更新比较快,文档跟不上节奏索性删了[手动滑稽] 1.2. 快速开

分布式事务解决方案框架(LCN)

事物概念 事物特性(ACID) 原子性(A) 所谓的原子性就是说,在整个事务中的所有操作,要么全部完成,要么全部不做,没有中间状态.对于事务在执行中发生错误,所有的操作都会被回滚,整个事务就像从没被执行过一样. 一致性(C) 事务的执行必须保证系统的一致性,就拿转账为例,A有500元,B有300元,如果在一个事务里A成功转给B50元,那么不管并发多少,不管发生什么,只要事务执行成功了,那么最后A账户一定是450元,B账户一定是350元. 隔离性(I) 所谓的隔离性就是说,事务与事务之间不会互相影

kafka实现分布式事务

分布式事务 概念: 分布式事务就是指事务的参与者.支持事务的服务器.资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.以上是百度百科的解释,简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败. 本质上来说,分布式事务就是为了保证不同数据库的数据一致性.实现分布式事务方案有很多种,有阿里的seata,基于tcc的高性能分布式事务框架hmily和lcn等开源框架外,还有基于mq来实现分

seata-分布式事务与seata

分布式事务与 Seata 分布式事务 分布式事务是个现实中很常见的现象,日常的跨行转账就是一个很典型的分布式事务. 现实中,每个银行各自管理各自的账户,在执行跨行转账时,需要确保转出账户扣费正确,转入账户增加正确的金额.在电子渠道上操作看着很简单,其后台需要执行分布式事务的处理流程有很多步骤,如果账户不平,还需要进行人工对账,中间涉及到一系列的制度和机制.这里暂且不涉及电子交易的安全可信的问题,只讨论分布式事务. 转账的数字形式上无非是一系列的电子信号,但是它是用户的财富的事实代表,其转移有法律