分布式事務專題一直是面試的重點，這篇文章主要是討論一下分布式事務中的2pc協(xié)議。如果你之前看過CAP和BASE理論，會對這篇文章的理解有更大的幫助。

一、什么是2pc協(xié)議

2PC即兩階段提交協(xié)議，是將整個事務流程分為兩個階段，準備階段（Prepare phase）、提交階段（commit
phase），2是指兩個階段，P是指準備階段，C是指提交階段。

如何理解呢？比如說同學聚會，AA制。

（1）準備階段：每個人出錢

（2）提交階段：錢齊了付款

在這倆階段中，任何一個環(huán)節(jié)出現了錯誤，整個事務都會流產。在常見的關系型數據庫中就支持了2pc協(xié)議。比如有名的mysql數據庫。

（1）準備階段（Prepare phase）：事務管理器給每個參與者發(fā)送Prepare消息，每個數據庫參與者在本地執(zhí)行事
務，并寫本地的Undo/Redo日志，此時事務沒有提交。

（2）提交階段（commit phase）：如果事務管理器收到了參與者的執(zhí)行失敗或者超時消息時，直接給每個參與者發(fā)送回滾(Rollback)消息；

下面是成功的情況：階段1是準備階段，階段2是提交階段

image

下面是失敗的情況。

image

這就是失敗的情況。

二、使用seata實現2pc事務

這個seata是阿里提供的分布式事務框架。Seata把一個分布式事務理解成一個包含了若干分支事務的全局事務。全局事務的職責是協(xié)調其下管轄的分支事務達成一致，要么一起成功提交，要么一起失敗回滾。此外，通常分支事務本身就是一個關系數據庫的本地事務，下圖是全局事務與分支事務的關系圖：

image

Seata定義了3個組件來協(xié)議分布式事務的處理過程 。

image

（1）Transaction Manager (TM)：事務管理器，TM需要嵌入應用程序中工作，它負責開啟一個全局事務，并最終向TC發(fā)起全局提交或全局回滾的指令。

（2）Transaction Coordinator (TC)：事務協(xié)調器，它是獨立的中間件，需要獨立部署運行，它維護全局事務的運行狀態(tài)，接收TM指令發(fā)起全局事務的提交與回滾，負責與RM通信協(xié)調各各分支事務的提交或回滾。

（3）Resource Manager (RM)：控制分支事務，負責分支注冊、狀態(tài)匯報，并接收事務協(xié)調器TC的指令，驅動分支（本地）事務的提交和回滾。

這些概念看起來有點懵逼，舉個例子吧：拿新用戶注冊送積分舉例Seata的分布式事務過程

image

具體的執(zhí)行流程如下：

（1）用戶服務的 TM 向 TC 申請開啟一個全局事務，全局事務創(chuàng)建成功并生成一個全局唯一的XID。

（2）用戶服務的 RM 向 TC 注冊 分支事務，該分支事務在用戶服務執(zhí)行新增用戶邏輯，并將其納入 XID 對應全局
事務的管轄。

（3）用戶服務執(zhí)行分支事務，向用戶表插入一條記錄。

（4）邏輯執(zhí)行到遠程調用積分服務時(XID 在微服務調用鏈路的上下文中傳播)。積分服務的RM 向 TC 注冊分支事
務，該分支事務執(zhí)行增加積分的邏輯，并將其納入 XID 對應全局事務的管轄。

（5）積分服務執(zhí)行分支事務，向積分記錄表插入一條記錄，執(zhí)行完畢后，返回用戶服務。

（6）用戶服務分支事務執(zhí)行完畢。

（7）TM 向 TC 發(fā)起針對 XID 的全局提交或回滾決議。

（8）TC 調度 XID 下管轄的全部分支事務完成提交或回滾請求。

image