SEATA
简介
Seata是阿里开源的一款高性能分布式事务解决方案，在2019年1月初阿里分布式事务框架GTS开源了一个免费社区版Fescar，也就是说在阿里内部叫GTS，后面开源版本叫Fescar，后面再改名为Seata
seata是一款开源的分布式解决方案,致力于提高性能和简单易用的分布式事务服务.seata将为用户提供了AT,TCC,SAGA和XA模式,位数打造一站式的分布式解决方案
术语
TC(Transaction Coordinator)-事务协调者
维护全局和分支事务的状态,驱动全局事务提交或回滚
TM(Transaction Manager)-事务管理器
定义全局事务的范围:开始全局事务,提交或回滚事务
RM(Resource Manager)资源管理器
管理事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚
Seata AT 模式
AT模式是一种无侵入的分布式事务解决方案,在AT模式下,用户只需关注自己的业务sql,用户的业务sql作为一阶段,seata框架会自动生成事务的二阶段提交和回滚操作
前提
- 基于支持本地 ACID 事务的关系型数据库。
- Java 应用，通过 JDBC 访问数据库。
整体机制
两阶段提交协议的演变：
- 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段：
- 提交异步化，非常快速地完成。
- 回滚通过一阶段的回滚日志进行反向补偿。
写隔离
一段本地事务提交前,需要确保先拿到全局锁
拿不到全局锁,不能提交本地事务
拿全局锁的尝试被限制在一定的范围内,超出范围将放弃,并回滚本地事务,释放本地锁
流程
一阶段
在一阶段中,seata会拦截业务sql,用户的业务sql作为一阶段,stata框架会自动生成事务的二阶段提交和回滚操作,这些操作都在本地数据库事务内完成,这样保证了一阶段的原子性
二阶段
相对于一阶段,二阶段比较简单,负责整体的回滚和提交,如果之前一阶段中有本地事务没有通过,那么就执行全局回滚,否在执行全局提交,回滚用到的就是一阶段记录的undolog 通过回滚记录生成反向sql并执行,已完成分支的回滚.当然事务完成后会释放所有资源和删除所有日志
XA模式
seata1.2.0版本重磅发布事务模式XA模式,实现对XA协议的支持
XA规范是X/Open组织定义的分布式事务处理(DTP)标准
XA规范描述了全局事务管理器与局部的资源你管理器之间的接口.XA规范的目的是允许多个资源(如数据库,应用服务器,消息队列等)在同一十五中访问,这样可以使ACID属性跨应用程序而保持有效
XA规范使用俩阶段提交(2PC TWO-Phase Commit)来保证资源同时提交或回滚任何特定的事务
DTP模型定义如下角色
- AP:应用程序
- RM资源管理器
- TM事务管理器
DTP模式定义TM和RM之间通讯的接口规范叫XA,简理解为数据库提供的2pc协议基于数据库XA协议来实现的2pc方案又称为XA方案
痛点
如果一个参与全局事务的资源失联了,(收不到分支事务结束的命令),那么它锁定的数据将一直被锁定.甚至可能产生死锁
也是seata引入xa模式重点要解决的问题
TCC
TCC分别对应Try,Confirm,Canel具体含义如下
- Try:预留业务资源
- Confirm:确认执行业务操作
- Cancel:取消执行业务操作
具体见
SAGA事务模式
SAGA是seata提供的一个长事务解决方案,在saga模式中,业务流程中每个 参与者都提交本地事务,当出现某一个参与者失败则补偿前面已经成功的参与者,一阶段正向服务和二阶段补偿服务(执行处理时错了,给一个修复的机会)都由业务开发来实现
saga模式下分布式事务通常是由事件驱动的,各个参与者之间是异步执行的,saga模式是一种长事务解决方案
为什么需要saga
之前我们学习saga分布式三种操作模型中所使用的的微服务全部可以根据开发者的需求进行修改,但是在一些特殊环境下,比如老系统,封闭系统(无法修改)同时没有任何分布式事务引入,那么AT,XA,TCC模型将全部不能使用,为了解决这一的问题,才引用了SAGa模型
sata模式是sata提供的长事务解决方案提供了易购系统的事务统一处理模型.在saga模式中,所有的子业务都不直接参与整体的事务处理(只负责本地的事务处理),而是全部交由了最终调用端负责实现,而在进行总业务逻辑处理时,在某个子业务出现问题时,啧自动补偿全面其他已成功的参与者,这样一阶段的正向服务调用和二阶段的服务补偿处理全部由总业务开发实现
