seata相对于AT模式而言,虽然说没有框架帮忙处理前镜像和后镜像,但是它相对来说,比AT模式,要做的时候要多一些,相对于业务系统而言。比如补偿模式下的Tcc模式的流程:
整个流程下来,Tcc的执行流程比较简单,相对于AT模式而言。首先初始化事务协调器TC。完成事务协调器之后,启动服务端Netty。业务系统通过执行业务,通过Aop增强,将业务系统中带注解的相关信息GlobalTransactional和TwoPhaseBusinessAction逐一注册到Map结构的数据结构中,然后注册到RM中。接着基于全局事务进行发起。执行try操作,如果try操作没有出现异常,则执行confirm操作操作,否则执行cancel操作,而执行两个阶段的过程都是基于Aop增强+动态代理的。
引入seata client的依赖
业务逻辑上加@GlobalTransactional作为发起方的标识
引入@TwoPhaseBusinessAction,带注解的方法是try方法
对try补偿,调用confirm、cancal,完成提交或回滚
但是使用发现,如果分布式事务中嵌套分布式事务,如果嵌套的分布式事务出现异常,不会被捕捉到的问题,导致数据出现异常的问题。因此需要在嵌套的分布式事务中尽量避免异常。
1)首先GlobalTransactionScanner#wrapIfNecessary,进行Aop增强,进入到增强的逻辑,isTccAutoProxy设置remotingServiceMap信息。设置完成后,提取TwoPhaseBusinessAction注解带的信息。调用远程服务netty进行注册。将资源信息进行缓存,netty会基于注册事件请求注册资源处理器。
2)此时GlobalTransactionalInterceptor会进行拦截,也即从@GlobalTransactional作为发起方进行发起全局事务。GlobalTransactionalInterceptor会调用TransactionalTemplate执行execute,获取全局事务信息。设置事务的隔离级别。开启全局事务beginTransaction。
3)业务系统: 执行业务系统中的try()方法,基于invoke,此时会调用到业务系统的try方法,进行try操作。保存xid、分支类型、绑定分支。处理tcc切面,和返回业务结果。
4)ActionInterceptorHandler处理tcc切面,和返回业务结果。进行日志存储doTccActionLogStore。完成这个操作相当于一阶段完成,此时会对一阶段的执行状态进行上报, 分支上报、执行业务Action上下文清理。没有发生异常,提交事务commitTransaction。RmBranchCommitProcessor进行资源分支提交处理处理。TCCResourceManager中 branchCommit获取业务action上下文,TCCResourceManager:commitMethod.invoke(targetTCCBean, args)调用业务,如果当前提交正常,则执行confirm方法,否则执行调用业务系统cancel方法。
5)完成之后,执行全局事务提交结束commitTranscation。如果正常,则二阶段执行日志的删除,否则执行回滚。