随着各种微服务分布式的流行,单体应用被拆分成微服务应用,原来的三个模块被拆分成三个独立的应用,分别使用三个独立的数据源,业务操作需要调用三个服务来完成。此时每个服务内部的数据一 致性由本地事务来保证,但是全局的数据 致性问题没法保证。
一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用,就会产生分布式事务问题,这也就引出我们的Seata来进行处理分布式事务了~
Seata简介
Seata 是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式,为用户打造一站式的分布式解决方案。在 Seata 开源之前,Seata 对应的内部版本在阿里经济体内部一直扮演着分布式一致性中间件的角色,帮助经济体平稳的度过历年的双11,对各BU业务进行了有力的支撑。经过多年沉淀与积累,商业化产品先后在阿里云、金融云进行售卖。2019.1 为了打造更加完善的技术生态和普惠技术成果,Seata 正式宣布对外开源,未来 Seata 将以社区共建的形式帮助其技术更加可靠与完备。
http://seata.io/zh-cn/docs/overview/what-is-seata.html里面有详细解释AT、TCC模式等详解
一个典型的分布式事务过程有 :分布式事务处理过程的ID+三组件模型组成
Transaction ID XID :全局唯一的事务ID
TC组件:事务协调者 Transaction Coordinator(TC)
- 维护全局和分支事务的状态,驱动全局事务提交或回滚 :比如说主播老师,或者seate服务
TM组件:事务管理器 Transaction Manager(TM)
- 定义全局事务的范围:开始全局事务、提交或回滚全局事务:比如说班主任,或者添加了@GlobalTranctional注解的orderservice入口
RM组价:资源管理器 Resource Manager(RM)
- 管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚:比如上课学生、或者者是其他被调用的微服务storageService、accountService等对应的数据库db
处理过程:
1. TM向TC申请开启一 个全局事务,全局事务创建成功并生成一 个全局唯一的XID;
2. XID在微服务调用链路的上下文中传播;
3. RM向TC注册分支事务,将其纳入XID对应全局事务的管辖;
4. TM向TC发起针对XID的全局提交或回滚决议;
5. TC调度XID下管辖的全部分支事务完成提交或回滚请求。
Seata的下载地址:
http://seata.io/zh-cn/blog/download.html,然后选择发布说明,进去选择zip包下载
选择合适的版本进行下载zip包!
Seata的使用
直接一个@GlobalTranctional注解就ok了~~使用简单~但是需要其他的配置之类的,下面一篇文章将详细介绍seata的安装~~
Seata 支持四种模式 AT、TCC、SAGA、XA等模式
AT模式:
一阶段加载:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源
在一阶段,Seata会拦截“业务SQL",
1、解析SQL语义,找到“业务SQL"要更新的业务数据,在业务数据被更新前,将其保存成"before image” ,
2、执行“业务SQL"更新业务数据,在业务数据更新之后,
3、其保存成"after image” ,最后生成行锁。
以上操作全部在一个数据库事务内完成, 这样保证了一阶段操作的原子性。
二阶段提交:提交异步化,非常快速地完成
二阶段如果顺利提交的话,因为“业务 SQL"在一阶段已经提交至数据库,所以Seata框架只需将一阶段保存的快照数据和行锁删掉, 完成数据清理即可。
二阶段回滚:回滚通过一阶段的回滚日志进行反向补偿
阶段如果是回滚的话,Seata就需要回滚一阶段已经执行的“业务SQL" ,还原业务数据。
回滚方式便是用"before image” 还原业务数据;但在还原前要首先要校验脏写,对比”数据库当前业务数据”和“after image"如果两份数据完全一 致就说明没有脏写,可以还原业务数据,如果不一 致就说明有脏写,出现脏写就需要转人工处理。
整体流程: