微服務與分布式事務

分布式事務是隨着服務拆分而產生的問題，至於為什么要做服務拆分以及什么是微服務，可以參考下這里我們知道對於分布式場景而言，肯定是遵循CAP理論的，所以對於這種情況下的事務而言，跨多個服務的調用事務則成了一個令人頭疼的點，而Seata則是一個用於解決分布式環境下事務的框架。

Seata歷史介紹

Seata是阿里開發的一個用於微服務架構的高性能易使用的分布式事務框架。 Seata由TXC（Taobao Transaction Constructor，阿里於2014開始着手解決分布式事務的內部框架）-》GTX（Global Transaction Service，阿里於2016年將TXC發布於雲服務並且改名為GTX）-》Fescar（阿里於2019將GTS開源並改名為Fescar）-》Seata（Simple Extensible Autonomous Transaction Architecture，阿里將螞蟻金服框架DTX與Fescar結合並且改名為Seata）目前Seata已經是github上一個大熱的項目，年初開源，現在發布至0.8.0版本，已經有11000的star數，並且在快速的更新迭代。相信未來會是一個普遍的分布式事務解決方案。

Seata架構

Seata目前的事務模式有AT，TCC，Saga三種模式，默認即是AT模式，AT本質上是2pc協議的一種實現，三種模式的不同后面文章再詳細介紹。這里我們簡單介紹下Seata是如何解決分布式事務的

假設我們現在有一個商品購物的業務，對於后台系統而言有四個服務，Business(業務入口)，Storage（庫存服務），Order（訂單服務），Account（用戶服務），用戶通過Business購買商品下單，在系統內部會經歷以下流程：

如圖所示，Business通過rpc框架（dubbo，feign....)調用其他服務。Seata將上面整個調用鏈所產生的事務結合生成了一個全局事務：

如圖所示，對於全局事務而言，它由各個分支事務結合而成，而分支事務則代表一個服務的本地事務。

對於每個服務來說，代表了兩種角色：

如圖所示，對於每一個服務而言都有兩種角色（TM，RM）,在全局事務的過程中，它們會與TC進行通信協助完成整個事務，可以簡單介紹下每個角色的作用:

： Transaction Coordinator，事務協調器：監視每個全局事務的狀態，負責全局事務的提交和回滾。

: Transaction Manager, 事務管理者：向TC

發起，提交，回滾

全局事務的請求。

: Resource Manager, 資源管理器：服務向TC

發起，提交，報告

分支事務的請求，並且服務本地事務的回滾，提交。

Seata處理一個全局事務的流程如下：

TM向TC請求發起一個全局事務，TC返回一個代表這個全局事務的XID。
XID在rpc中傳播給每一個調用鏈中的服務。
每個RM拿到XID后向TC發起一個分支事務，TC返回一個代表這個分支事務的XID。
RM完成本地分支的業務，提交本地分支，並且報告給TC。
全局事務調用鏈處理完畢，TM根據有無異常向TC發起全局事務的提交或者回滾。

回滾：

假設某個RM本地事務失敗。該RM自身驅動本地事務回滾，並且報告給TC。
TM檢測到了某個分支事務失敗，向TC發起全局事務回滾。
TC給每一個RM發送消息，通知它們全部回滾。
TC將全局事務回滾的結果發送給TM。全局事務結束。

三種模式

AT模式

一階段

在一階段，Seata 會攔截“業務 SQL”，首先解析 SQL 語義，找到“業務 SQL”要更新的業務數據，在業務數據被更新前，將其保存成“before image”，然后執行“業務 SQL”更新業務數據，在業務數據更新之后，再將其保存成“after image”，最后生成行鎖。以上操作全部在一個數據庫事務內完成，這樣保證了一階段操作的原子性。

二階段

提交

二階段如果是提交的話，因為“業務 SQL”在一階段已經提交至數據庫，所以 Seata 框架只需將一階段保存的快照數據和行鎖刪掉，完成數據清理即可。
回滾

二階段如果是回滾的話，Seata 就需要回滾一階段已經執行的“業務 SQL”，還原業務數據。回滾方式便是用“before image”還原業務數據；但在還原前要首先要校驗臟寫，對比“數據庫當前業務數據”和 “after image”，如果兩份數據完全一致就說明沒有臟寫，可以還原業務數據，如果不一致就說明有臟寫，出現臟寫就需要轉人工處理。