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的開源