Distributed--2PC和3PC
阿新 • • 發佈:2019-03-31
能夠 問題 廣泛 思想 記錄 情況 coord 決定 有效
在分布式系統中,每一個機器節點雖然都能夠明確地知道自己在進行事務操作過程中的結果是成功或失敗,但卻無法直接獲取到其他分布式節點的操作結果.因此,當一個事務操作需要跨越多個分布式節點的時候,為了保持事務處理的ACID特性,就需要引入一個稱為協調者(Coordinator)的組件來統一調度所有分布式節點的執行邏輯,這些調度的分布式節點則被稱為參與者(Participant).協調者負責調用參與者的行為,並最終決定這些參與者是否要把事務真正進行提交.
基於這個思想,衍生出了二階段提交(2PC)和三階段提交(3PC)兩種協議.
2PC
2PC,是Two-Phase Commit的縮寫,即二階段提交,是計算機網絡尤其是在數據庫領域內,為了是基於分布式系統架構下的所有節點在進行事務處理過程中能夠保持原子性和一致性而設計的一種算法.
通常,二階段提交協議也被認為是一種一致性協議,用來保證分布式系統數據的一致性.
目前,絕大部分的關系型數據庫都是采用二階段提交協議來完成事務處理的,利用該協議能夠非常方便地完成所有分布式事務參與者的協調,統一決定事務的提交或回滾,從而能夠有效地保證分布式數據一致性,因此二階段提交協議被廣泛的應用在許多分布式系統中.
協議說明
階段一:提交事務請求(投票階段)
- 事務詢問 協調者向所有的參與者發送事務內容,詢問是否可以執行事務提交操作,並開始等待各參與者的響應.
- 執行事務 各參與者節點執行事務操作,並將Undo和Redo信息記入事務日誌中.
- 各參與者向協調者反饋事務詢問的響應 如果參與者成功執行了事務操作,那麽就反饋給協調者Yes響應,表示事務可以執行;如果參與者沒有成功執行事務,那麽就反饋給協調者No響應,表示事務不可以執行.
階段二:執行事務提交(執行階段)
在階段二中, 協調者會根據各參與者的反饋情況來決定最終是否可以進行事務提交的操作,正常情況下,包含以下兩種可能.
執行事務提交
假設協調者從所有的參與者獲得的反饋都是Yes響應,那麽就會執行事務提交.- 發送提交請求 協調者向所有參與者節點發出Commit請求.
- 事務提交反饋事務 參與者接收到Commit請求後,會正式執行事務提交操作,並在完成提交之後釋放在整個事務執行期間占用的事務資源.
- 提交結果 參與者在完成事務提交之後,向協調者發送Ack消息.
- 完成事務 協調者接收到所有參與者反饋的Ack消息後,完成事務.
中斷事務
假如任何一個參與者向協調者反饋了No響應,或者在等待超時之後,協調者尚無法接收到所有參與者的反饋響應,那麽就會中斷事務.
- 發送回滾請求 協調者向所有參與者節點發出Rollback請求.
- 事務回滾 參與者接收到Rollback請求後,會利用其在階段一中記錄的Undo信息來執行事務回滾操作,並在完成回滾之後釋放在整個事務執行期間占用的資源.
- 反饋事務回滾結果 參與者在完成事務回滾之後,向協調者發送Ack消息.
- 中斷事務 協調者接收到所有參與者反饋的Ack消息後,完成事務中斷.
總結
簡單地講,二階段提交將一個事務的處理過程分為了投票和執行兩個階段,其核心是對每個事務都采用先嘗試後提交的處理方式,因此也可以將二階段提交看做一個強一致性的算法.
優點
原理簡單,實現方便
缺點
- 同步阻塞 在二階段提交的執行過程中,所有參與該事務操作的邏輯都處於阻塞狀態,也就是說,各個參與者在等待其他參與者響應的過程中,將無法進行其他任何操作.
- 單點問題 一旦協調者出現問題,那麽整個二階段提交流程將無法運轉,更為嚴重的是,如果協調者是在階段二中出現問題的話,那麽其他參與者將會一直處於事務資源的狀態中,而無法繼續完成事務操作.
- 數據不一致 可能發生只有部分參與者接收到了Commit請求,於是這部分收到了Commit請求的參與者就會進行事務提交,而其他沒有收到Commit請求的參與者則無法進行事務提交,於是整個分布式系統便出現了數據不一致現象.
- 太過保守 二階段提交協議沒有設計較為完善的容錯機制,任意一個節點的失敗都會導致整個事務的失敗.
Distributed--2PC和3PC