Spring Cloud Alibaba Seata 源码分析-数据源代理
AT模式的核心点:
- 获取全局锁、开启全局事务
- 解析SQL并写入undolog
分析AT模式如何解析SQL并写入undolog,首先我们要先明确实际上Seata其中采用了数据源代理的模式。
那么这个就需要我们在回顾一下GlobalTransactionScanner这个类型,在这个类型中继承了一些的接口和抽象类,比较关键的几个:
- AbstractAutoProxyCreator
- InitializingBean
Spring Cloud Alibaba Seata 源码分析-数据源代理
分析AT模式如何解析SQL并写入undolog,首先我们要先明确实际上Seata其中采用了数据源代理的模式。
那么这个就需要我们在回顾一下GlobalTransactionScanner这个类型,在这个类型中继承了一些的接口和抽象类,比较关键的几个:
Spring Cloud Alibaba Seata 源码分析 服务端(TC)源码解读
我们的Seata服务端在应用的时候需要准备三张表,那么这三张表分别代表的意思就是
客户端请求服务端以后,我们就需要把对应的全局事务包括分支事务和全局锁全部存放到这里。
![image.png](spring-cloud-alibaba-seata-source-code-analysis-server (-tc)-source-code-interpretation/a1cca08a47184ea5b4d1a2ba1cb12b5e.png)
Spring Cloud Alibaba Seata 2PC 核心源码解读
GlobalTransactionalInterceptor全局事务拦截器,一旦执行拦截器,就会进入到其中的invoke方法,在这其中会做一些@GlobalTransactional注解的判断,如果有注解以后,会执行全局事务和全局锁,那么在执行全局事务的时候会调用handleGlobalTransaction全局事务处理器,这里主要是获取事务信息
1 | Object handleGlobalTransaction(final MethodInvocation methodInvocation, |
Spring Cloud Alibaba Seata 源码入口
首先一个Seata的客户端启动一般分为几个流程:
在这个其中,就会涉及到几个核心的类型,首先我们需要来看配置类型GlobalTransactionAutoConfiguration
Spring Cloud Alibaba Seata Saga 事务模式
Saga模式是SEATA提供的长事务解决方案,在Saga模式中,业务流程中每个参与者都提交本地事务,当出现某一个参与者失败则补偿前面已经成功的参与者,一阶段正向服务和二阶段补偿服务(执行处理时候出错了,给一个修复的机会)都由业务开发实现。
Spring Cloud Alibaba Seata TCC 事务模式
首先我们先来了解常规的TCC模式。
TCC 是分布式事务中的二阶段提交协议,它的全称为 Try-Confirm-Cancel,即资源预留(Try)、确认操作(Confirm)、取消操作(Cancel),他们的具体含义如下:
Spring Cloud Alibaba Seata XA 模式
Seata 1.2.0 版本重磅发布新的事务模式:XA 模式,实现对 XA 协议的支持。
我们从三个方面来深入分析:
首先我们需要先了解一下什么是XA?
XA 规范早在上世纪 90 年代初就被提出,用以解决分布式事务处理这个领域的问题。
注意:不存在某一种分布式事务机制可以完美适应所有场景,满足所有需求。
现在,无论 AT 模式、TCC 模式还是 Saga 模式,这些模式的提出,本质上都源自 XA 规范对某些场景需求的无法满足。
Spring Cloud Alibaba Seata 配置 Nacos 注册中心和配置中心
Seata支持注册服务到Nacos,以及支持Seata所有配置放到Nacos配置中心,在Nacos中统一维护;
高可用模式下就需要配合Nacos来完成
Seata-server端配置注册中心,在registry.conf中加入配置注册中心nacos
注意:确保client与server的注册处于同一个namespace和group,不然会找不到服务。
Spring Cloud Alibaba Seata AT 模式
概念:AT模式是一种无侵入的分布式事务解决方案,在 AT 模式下,用户只需关注自己的“业务 SQL”,用户的 “业务 SQL” 作为一阶段,Seata 框架会自动生成事务的二阶段提交和回滚操作。
两阶段提交协议的演变:
在一阶段中,Seata会拦截“业务SQL“,首先解析SQL语义,找到要更新的业务数据,在数据被更新前,保存下来”undo”,然后执行”业务SQL“更新数据,更新之后再次保存数据”redo“,最后生成行锁,这些操作都在本地数据库事务内完成,这样保证了一阶段的原子性。