概述
學習了分布式事務的基礎理論，以理論為基礎，針對不同的分布式場景業界常見的解決方案有2PC、TCC、可靠消息最終一致性、最大努力通知這幾種。
什么是2PC
2PC即兩階段提交協議，是將整個事務流程分為兩個階段，准備階段（Prepare phase）、提交階段（commit phase），2是指兩個階段，P是指准備階段，C是指提交階段。舉例：張三和李四好久不見，老友約起聚餐，飯店老板要求先買單，才能出票。這時張三和李四分別抱怨近況不如意，囊中羞澀，都不願意請客，這時只能AA。只有張三和李四都付款，老板才能出票安排就餐。但由於張三和李四都是鐵公雞，形成了尷尬的一幕：
- 准備階段：老板要求張三付款，張三付款。老板要求李四付款，李四付款。
- 提交階段：老板出票，兩人拿票紛紛落座就餐。
例子中形成了一個事務，若張三或李四其中一人拒絕付款，或錢不夠，店老板都不會給出票，並且會把已收款退回。
整個事務過程由事務管理器和參與者組成，店老板就是事務管理器，張三、李四就是事務參與者，事務管理器負責決策整個分布式事務的提交和回滾，事務參與者負責自己本地事務的提交和回滾。
在計算機中部分關系數據庫如Oracle、MySQL支持兩階段提交協議，如下圖：
- 准備階段（Prepare phase）：事務管理器給每個參與者發送Prepare消息，每個數據庫參與者在本地執行事務，並寫本地的Undo/Redo日志，此時事務沒有提交。（Undo日志是記錄修改前的數據，用於數據庫回滾，Redo日志是記錄修改后的數據，用於提交事務后寫入數據文件）
- 提交階段（commit phase）：如果事務管理器收到了參與者的執行失敗或者超時消息時，直接給每個參與者發送回滾(Rollback)消息；否則，發送提交(Commit)消息；參與者根據事務管理器的指令執行提交或者回滾操作，並釋放事務處理過程中使用的鎖資源。注意:必須在最后階段釋放鎖資源。
下圖展示了2PC的兩個階段，分成功和失敗兩個情況說明：
- 成功情況：
- 失敗情況：
解決方案——XA方案
2PC的傳統方案是在數據庫層面實現的，如Oracle、MySQL都支持2PC協議，為了統一標准減少行業內不必要的對接成本，需要制定標准化的處理模型及接口標准，國際開放標准組織Open Group定義了分布式事務處理模型DTP（Distributed Transaction Processing Reference Model）。
下面新用戶注冊送積分為例來說明：
執行流程如下：
1、應用程序（AP）持有用戶庫和積分庫兩個數據源。
2、應用程序（AP）通過TM通知用戶庫RM新增用戶，同時通知積分庫RM為該用戶新增積分，RM此時並未提交事
務，此時用戶和積分資源鎖定。
3、TM收到執行回復，只要有一方失敗則分別向其他RM發起回滾事務，回滾完畢，資源鎖釋放。
4、TM收到執行回復，全部成功，此時向所有RM發起提交事務，提交完畢，資源鎖釋放。
DTP模型定義如下角色：
- AP(Application Program)：即應用程序，可以理解為使用DTP分布式事務的程序。
- RM(Resource Manager)：即資源管理器，可以理解為事務的參與者，一般情況下是指一個數據庫實例，通過資源管理器對該數據庫進行控制，資源管理器控制着分支事務。
- TM(Transaction Manager)：事務管理器，負責協調和管理事務，事務管理器控制着全局事務，管理事務生命周期，並協調各個RM。全局事務是指分布式事務處理環境中，需要操作多個數據庫共同完成一個工作，這個工作即是一個全局事務。
- DTP模型定義TM和RM之間通訊的接口規范叫XA，簡單理解為數據庫提供的2PC接口協議，基於數據庫的XA協議來實現2PC又稱為XA方案。
以上三個角色之間的交互方式如下：
1）TM向AP提供 應用程序編程接口，AP通過TM提交及回滾事務。
2）TM交易中間件通過XA接口來通知RM數據庫事務的開始、結束以及提交、回滾等。
總結：
整個2PC的事務流程涉及到三個角色AP、RM、TM。AP指的是使用2PC分布式事務的應用程序；RM指的是資源管理器，它控制着分支事務；TM指的是事務管理器，它控制着整個全局事務。
1）在准備階段RM執行實際的業務操作，但不提交事務，資源鎖定；
2）在提交階段TM會接受RM在准備階段的執行回復，只要有任一個RM執行失敗，TM會通知所有RM執行回滾操
作，否則，TM將會通知所有RM提交該事務。提交階段結束資源鎖釋放。
XA方案的問題：
1、需要本地數據庫支持XA協議。
2、資源鎖需要等到兩個階段結束才釋放，性能較差。
Seata方案
Seata是由阿里中間件團隊發起的開源項目 Fescar，后更名為Seata，它是一個是開源的分布式事務框架。
傳統2PC的問題在Seata中得到了解決，它通過對本地關系數據庫的分支事務的協調來驅動完成全局事務，是工作
在應用層的中間件。主要優點是性能較好，且不長時間占用連接資源，它以高效並且對業務0侵入的方式解決微服
務場景下面臨的分布式事務問題，它目前提供AT模式(即2PC)及TCC模式的分布式事務解決方案。
Seata的設計思想如下：
Seata的設計目標其一是對業務無侵入，因此從業務無侵入的2PC方案着手，在傳統2PC的基礎上演進，並解決2PC方案面臨的問題。
Seata把一個分布式事務理解成一個包含了若干分支事務的全局事務。全局事務的職責是協調其下管轄的分支事務達成一致，要么一起成功提交，要么一起失敗回滾。此外，通常分支事務本身就是一個關系數據庫的本地事務，下圖是全局事務與分支事務的關系圖：
與 傳統2PC 的模型類似，Seata定義了3個組件來協議分布式事務的處理過程：
Transaction Coordinator (TC)： 事務協調器，它是獨立的中間件，需要獨立部署運行，它維護全局事務的運
行狀態，接收TM指令發起全局事務的提交與回滾，負責與RM通信協調各各分支事務的提交或回滾。
Transaction Manager ™： 事務管理器，TM需要嵌入應用程序中工作，它負責開啟一個全局事務，並最終
向TC發起全局提交或全局回滾的指令。
Resource Manager (RM)： 控制分支事務，負責分支注冊、狀態匯報，並接收事務協調器TC的指令，驅動分
支（本地）事務的提交和回滾。
還拿新用戶注冊送積分舉例Seata的分布式事務過程：
具體的執行流程如下：
- 用戶服務的 TM 向 TC 申請開啟一個全局事務，全局事務創建成功並生成一個全局唯一的XID。
- 用戶服務的 RM 向 TC 注冊 分支事務，該分支事務在用戶服務執行新增用戶邏輯，並將其納入 XID 對應全局事務的管轄。
- 用戶服務執行分支事務，向用戶表插入一條記錄。
- 邏輯執行到遠程調用積分服務時(XID 在微服務調用鏈路的上下文中傳播)。積分服務的RM 向 TC 注冊分支事務，該分支事務執行增加積分的邏輯，並將其納入 XID 對應全局事務的管轄。
- 積分服務執行分支事務，向積分記錄表插入一條記錄，執行完畢后，返回用戶服務。
- 用戶服務分支事務執行完畢。
- TM 向 TC 發起針對 XID 的全局提交或回滾決議。
- TC 調度 XID 下管轄的全部分支事務完成提交或回滾請求。
Seata實現2PC與傳統2PC的差別：
架構層次方面，傳統2PC方案的 RM 實際上是在數據庫層，RM 本質上就是數據庫自身，通過 XA 協議實現，而
Seata的 RM 是以jar包的形式作為中間件層部署在應用程序這一側的。
兩階段提交方面，傳統2PC無論第二階段的決議是commit還是rollback，事務性資源的鎖都要保持到Phase2完成
才釋放。而Seata的做法是在Phase1 就將本地事務提交，這樣就可以省去Phase2持鎖的時間，整體提高效率。