上文我们分析了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的开源