您好,登錄后才能下訂單哦!
前言:
分布式事務專題一直是面試的重點,這篇文章主要是討論一下分布式事務中的2pc協議。如果你之前看過CAP和BASE理論,會對這篇文章的理解有更大的幫助。文末有福利分享哦朋友們
一、什么是2pc協議
2PC即兩階段提交協議,是將整個事務流程分為兩個階段,準備階段(Prepare phase)、提交階段(commitphase),2是指兩個階段,P是指準備階段,C是指提交階段。
如何理解呢?比如說同學聚會,AA制。
(1)準備階段:每個人出錢
(2)提交階段:錢齊了付款
在這倆階段中,任何一個環節出現了錯誤,整個事務都會流產。在常見的關系型數據庫中就支持了2pc協議。比如有名的mysql數據庫。
(1)準備階段(Prepare phase):事務管理器給每個參與者發送Prepare消息,每個數據庫參與者在本地執行事務,并寫本地的Undo/Redo日志,此時事務沒有提交。
(2)提交階段(commit phase):如果事務管理器收到了參與者的執行失敗或者超時消息時,直接給每個參與者發送回滾(Rollback)消息;
下面是成功的情況:階段1是準備階段,階段2是提交階段
下面是失敗的情況。
這就是失敗的情況。
二、使用seata實現2pc事務
這個seata是阿里提供的分布式事務框架。Seata把一個分布式事務理解成一個包含了若干分支事務的全局事務。全局事務的職責是協調其下管轄的分支事務達成一致,要么一起成功提交,要么一起失敗回滾。此外,通常分支事務本身就是一個關系數據庫的本地事務,下圖是全局事務與分支事務的關系圖:
Seata定義了3個組件來協議分布式事務的處理過程 。
(1)Transaction Manager (TM):事務管理器,TM需要嵌入應用程序中工作,它負責開啟一個全局事務,并最終向TC發起全局提交或全局回滾的指令。
(2)Transaction Coordinator (TC):事務協調器,它是獨立的中間件,需要獨立部署運行,它維護全局事務的運行狀態,接收TM指令發起全局事務的提交與回滾,負責與RM通信協調各各分支事務的提交或回滾。
(3)Resource Manager (RM):控制分支事務,負責分支注冊、狀態匯報,并接收事務協調器TC的指令,驅動分支(本地)事務的提交和回滾。
這些概念看起來有點懵逼,舉個例子吧:拿新用戶注冊送積分舉例Seata的分布式事務過程
具體的執行流程如下:
(1)用戶服務的 TM 向 TC 申請開啟一個全局事務,全局事務創建成功并生成一個全局唯一的XID。
(2)用戶服務的 RM 向 TC 注冊 分支事務,該分支事務在用戶服務執行新增用戶邏輯,并將其納入 XID 對應全局事務的管轄。
(3)用戶服務執行分支事務,向用戶表插入一條記錄。
(4)邏輯執行到遠程調用積分服務時(XID 在微服務調用鏈路的上下文中傳播)。積分服務的RM 向 TC 注冊分支事務,該分支事務執行增加積分的邏輯,并將其納入 XID 對應全局事務的管轄。
(5)積分服務執行分支事務,向積分記錄表插入一條記錄,執行完畢后,返回用戶服務。
(6)用戶服務分支事務執行完畢。
(7)TM 向 TC 發起針對 XID 的全局提交或回滾決議。
(8)TC 調度 XID 下管轄的全部分支事務完成提交或回滾請求。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。