Fescar(Seata)-Springcloud流程分析-2阶段

上文我们分析了fescar的一阶段执行过程。在一阶段中，服务起始方发起全局事务并注册到TC。在调用协同服务时，协同服务的事务分支事务会先完成阶段一的事务提交或回滚，并生成事务回滚的undo_log日志，同时上报其事务状态。出现任何异常都会通知TC,TC会通知各个一阶段已提交的事物通过undo_log发起回滚。如果没有异常即可提交事务。

现在我们了解下事务的提交和回滚。

事务提交

fescar通过netty进行服务之间的通信。上文我们说过，无论是提交还是回滚，本质都是发起一次请求到TC。TC在接收到请求后悔分发到com.alibaba.fescar.rm.AbstractRMHandler完成相应的逻辑。下图是相应的请求链

在com.alibaba.fescar.rm.datasource.DataSourceManager#branchCommit中fescar完成了相应的全局事务提交，这里DataSourceManager委托给asyncWorker去实现相应逻辑，asyncWorker是一个异步线程池

我们看下asyncWorker的分支提交代码

1.asyncWorker首先会把分支提交包装成一个二阶段的上下文，并添加到任务数组中

2.定时的去遍历任务数组，删除各个分支事务的undolog。注意这里并没有拿到代理DataSourceProxy。

引用一张官方的流程图

事务回滚

回到DatasourceManage，我们看com.alibaba.fescar.rm.datasource.DataSourceManager#branchRollback这个方法

实际的逻辑是在com.alibaba.fescar.rm.datasource.undo.UndoLogManager#undo中，很明显undo要做的事情就是去执行一阶段生成的undolog进行回滚

最后引用一张官方流程图

---

fescar的流程分析就告一段落了。其实还有很多的细节需要去完善，例如fescar对异常的处理，undo_log的拼接和执行等。fescar现在改名seata，下个版本将会执行HA，还是很期待它的第一个生产版本。通过本次源码的分析。对于feacar将整个jdbc中的Datasouce，Connnection，Statement三大组件进行了重写的思路感到大开眼界，自己也写了小demo，这次确实学到了好多东西！感谢fescar的开源