分散式場景之剛性事務-2PC詳解
分散式一致性
分散式場景下,多個服務同時對服務一個流程,比如電商下單場景,需要支付服務進行支付、庫存服務扣減庫存、訂單服務進行訂單生成、物流服務更新物流資訊等。如果某一個服務執行失敗,或者網路不通引起的請求丟失,那麼整個系統可能出現資料不一致的原因。
上述場景就是分散式一致性問題,追根到底,分散式一致性的根本原因在於資料的分散式操作,引起的本地事務無法保障資料的原子性引起。
分散式一致性問題的解決思路有兩種,一種是分散式事務,一種是儘量透過業務流程避免分散式事務。分散式事務是直接解決問題,而業務規避其實透過解決出問題的地方(解決提問題的人)。其實在真實業務場景中,如果業務規避不是很麻煩的前提,最優雅的解決方案就是業務規避。
事務分類
分散式事務實現方案從型別上去分剛性事務、柔型事務。剛性事務:通常無業務改造,強一致性,原生支援回滾/隔離性,低併發,適合短事務。柔性事務:有業務改造,最終一致性,實現補償介面,實現資源鎖定介面,高併發,適合長事務。
剛性事務:XA 協議(2PC、JTA、JTS)、3PC
柔型事務:TCC/FMT、Saga(狀態機模式、Aop模式)、本地事務訊息、訊息事務(半訊息)
2PC定義
2PC全稱Two-phaseCommit,中文名是二階段提交,是XA規範的實現思路,XA規範是 X/Open DTP 定義的交易中介軟體與資料庫之間的介面規範(即介面函式),交易中介軟體用它來通知資料庫事務的開始、結束以及提交、回滾等。XA 介面函式由資料庫廠商提供。
X/Open DTP是X/Open 組織(即現在的 Open Group )1994定義的分散式事務處理模型。XA規模型包括應用程式( AP )、事務管理器( TM )、資源管理器( RM )、通訊資源管理器( CRM )四部分。一般,常見的事務管理器( TM )是交易中介軟體,常見的資源管理器( RM )是資料庫,常見的通訊資源管理器( CRM )是訊息中介軟體。
2PC 通常使用到XA中的三個角色TM、AP
AP:事務發起方,通常為微服務自身;定義事務邊界(事務開始、結束),並訪問事務邊界內的資源
TM:事務協調方,事務操作總控;管理事務全域性事務,分配事務唯一標識,監控事務的執行進度,負責事務的提交、回滾、失敗恢復。
RM:本地事務資源,根據協調方命令進行操作;管理本地共享資源(既資料庫)。
2PC流程
2PC 分成2個階段,第一階段:請求階段(commit-request phase,或稱表決階段,voting phase)和第二階段:提交階段(commit phase)。
表決階段:事務協調者(TM)序列給每個參與者(RM)傳送Prepare訊息,每個參與者要麼直接返回失敗,要麼在本地SQL執行、記錄事務日誌(Undo、Redo),但不提交,到達一種“萬事俱備,只欠東風”的狀態。
可以進一步將準備階段分為以下三個步驟:
1)TM序列向每個參與者節點詢問是否可以執行提交操作,並等待各參與者節點的響應。
2)參與者節點執行詢問的所有SQL語句,並將Undo和Redo寫入日誌。
3)各參與者節點響應TM發起的詢問。如果參與者節點的事務操作實際執行成功,則返回一個”success”訊息;如果參與者節點的事務操作實際執行失敗,則返回一個”abort”訊息。
提交階段:如果TM收到了參與者的失敗訊息或者超時,直接給每個參與者傳送回滾(Rollback)訊息;否則,傳送提交(Commit)訊息;參與者根據TM的指令執行提交或者回滾操作,釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)
分支一--當TM從所有參與者節點獲得的相應訊息都為”success”時:
1)TM向所有參與者節點發出”正式提交(commit)”的請求。
2)參與者節點正式完成操作,並釋放在整個事務期間內佔用的資源。
3)參與者節點向TM傳送”完成”訊息。
4)TM受到所有參與者節點反饋的”完成”訊息後,完成事務。
分支二--如果任一參與者節點在第一階段返回的響應訊息為”abort”,或者 TM在第一階段的詢問超時之前無法獲取所有參與者節點的響應訊息時:
1)TM向所有參與者節點發出”回滾操作(rollback)”的請求。
2)參與者節點利用之前寫入的Undo資訊執行回滾,並釋放在整個事務期間內佔用的資源。
3)參與者節點向TM傳送”回滾完成”訊息。
4)TM受到所有參與者節點反饋的”回滾完成”訊息後,取消事務。
不管最後結果如何,第二階段都會結束當前事務。
總結
2PC雖然將XA規範方案細化成思路,也形成了流程圖,大部情況下確實能提供原子性操作,但是仍存在一定問題,所以又出現了3PC。
領取更多免費資料及影片
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69976011/viewspace-2696321/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 分散式架構,剛性事務-2PC必須注意的問題及3PC詳細解分散式架構
- 分散式柔性事務之事務訊息詳解分散式
- 分散式事務解決方案——柔性事務與服務模式分散式模式
- 分散式柔性事務的TCC方案分散式
- ORACLE分散式事務鎖各種場景下的處理詳解Oracle分散式
- 分散式事務解決方案與適用場景分析分散式
- 分散式事務-2PC和3PC分散式
- PHP分散式事務-兩段式提交 2PC(二)PHP分散式
- 一種基於柔性事務的分散式事務解決方案設計探究分散式
- 工商銀行分散式服務 C10K 場景解決方案分散式
- 五大分散式場景解決方案分散式
- 【分散式】Zookeeper應用場景分散式
- Git詳解之五:分散式GitGit分散式
- 分散式事務(1)---2PC和3PC理論分散式
- 剛柔並濟的開源分散式事務解決方案分散式
- Spring分散式事務XA事務(兩段提交2PC)實現Spring分散式
- 分散式理論(三) - 2PC協議分散式協議
- 【分散式鎖的演化】“超賣場景”,MySQL分散式鎖篇分散式MySql
- Oracle Gateway for SQL Server時2PC分散式事務異常處理OracleGatewaySQLServer分散式
- Spring的分散式事務實現(JTA+XA/2PC)Spring分散式
- 各種分散式事務的實現方式適用的場景分散式
- 分散式服務協調員zookeeper - 應用場景和監控分散式
- tcc分散式事務框架原始碼解析系列(三)之啟動詳解分散式框架原始碼
- 揭祕GBase 8c分散式事務處理核心技術之2PC協議分散式協議
- 分散式資料庫的需求與場景分散式資料庫
- 分散式儲存Ceph之PG狀態詳解分散式
- PHP 微服務之【分散式事務】PHP微服務分散式
- PHP 微服務之 [分散式事務]PHP微服務分散式
- 分散式一致性協議之2PC和3PC分散式協議
- 詳解Redis分散式鎖Redis分散式
- 打造企業級微服務平臺架構,分散式應用場景管理微服務架構分散式
- 天翼雲分散式快取服務(Redis)的應用場景(乾貨)分散式快取Redis
- 剛剛,華為全場景 AI 計算框架MindSpore開源!AI框架
- 分散式架構中非同步的使用場景分散式架構非同步
- 微服務架構中的分散式事務全面詳解 -DZone微服務微服務架構分散式
- 分散式事務(四)之TCC分散式
- 分散式事務框架 seata-golang 通訊模型詳解分散式框架Golang模型
- 3大主流分散式事務框架詳解(圖文總結)分散式框架