seata tcc模式下的一个性能问题

短命女 2024-04-18 05:22 70阅读 0赞

项目地址：[https://github.com/seata/seata][https_github.com_seata_seata]  
官网地址：[https://seata.io/][https_seata.io]

##### 本文解释Seata中，AT模式和MT模式下的一个一阶段的区别。 #####

根据两阶段行为模式的不同，Seata将分支事务划分为2种：

*  Automatic (Branch) Transaction Mode
 *  Manual (Branch) Transaction Mode

### 1.AT模式 ###

AT 模式基于 支持本地 ACID 事务 的 关系型数据库：

一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。  
二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。  
二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

### 2. MT模式 ###

相应的，MT 模式，不依赖于底层数据资源的事务支持：  
一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。  
二阶段 commit 行为：调用 自定义 的 commit 逻辑。  
二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。  
所谓 MT 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。

### 3.一阶段解读 ###

在AT模式下，一阶段会做如下几个操作：

1.解析业务sql；  
2.获取sql执行前的镜像，前镜像；  
3.执行业务sql；  
4.获取sql执行后的镜像，后镜像；  
5.添加undo\_log日志，把前后镜像数据和业务sql相关的信息组成回滚日志，添加到undo\_log中；  
6.向TC注册分支事务，并申请相关目标数据的全局锁；  
7.事务提交，将业务操作和undo\_log一起提交；  
8.上报分支事务提交结果给TC；  
9.释放本地锁；  
10.释放数据库连接；

在AT模式下，一阶段，会有如上的多个步骤，以及解析存储undo\_log等操作；那么，在MT模式中，由于prepare逻辑有对应的rollback逻辑，显然这里是不用再添加回滚信息的。那么，这MT模式下一阶段的处理逻辑，是如何避免上述操作带来的性能损耗呢？

### 4.源码分析 ###

在方法拦截器MethodInterceptor接口下，有一个TCC拦截器实现类TccActionInterceptor，这个实现类有一个invoke方法：

@Override
        public Object invoke(final MethodInvocation invocation) throws Throwable {
            if(!RootContext.inGlobalTransaction()){
                //not in transaction
                return invocation.proceed();
            }
            Method method = getActionInterfaceMethod(invocation);
            TwoPhaseBusinessAction businessAction = method.getAnnotation(TwoPhaseBusinessAction.class);
            //try method
            if (businessAction != null) {
                //save the xid
                String xid = RootContext.getXID();
                //clear the context
                RootContext.unbind();
                try {
                    Object[] methodArgs = invocation.getArguments();
                    //Handler the TCC Aspect
                    Map<String, Object> ret = actionInterceptorHandler.proceed(method, methodArgs, xid, businessAction,
                            new Callback<Object>() {
                                @Override
                                public Object execute() throws Throwable {
                                    return invocation.proceed();
                                }
                            });
                    //return the final result
                    return ret.get(Constants.TCC_METHOD_RESULT);
                } finally {
                    //recovery the context
                    RootContext.bind(xid);
                }
            }
            return invocation.proceed();
        }

可以看到，在切面的切入点执行之前，和之后，有2个关键操作：  
把xid解绑

//save the xid
    String xid = RootContext.getXID();
    //clear the context
    RootContext.unbind();

恢复xid绑定

//recovery the context
    RootContext.bind(xid);

这么做的目的是什么呢？

当把xid解绑后，tcc的这个prepare分支事务执行时，框架不会拦截业务sql进行解析，也不会存储前后镜像和生成undo\_log日志，（即使使用了代理数据源，也不会）这样，tcc模式下，就避免了一阶段的上述操作带来的损耗。

[https_github.com_seata_seata]: https://github.com/seata/seata
[https_seata.io]: https://seata.io/