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