2PC、3PC
二階段提交協議(2PC)、三階段提交協議(3PC)都是為了解決分布式一致性問題。
??在分布式系統中為了保證事務處理的ACID特性,引入了協調者組件來同一調度所有分布式節點的執行邏輯,被調度的分布式節點稱為參與者,協調者負責調度參與者的行為,并決定這些參與者是否提交事務。
??
2PC
二階段提交協議將事務的提交過程分成兩個階段來處理:
第一個階段是提交事務請求:
- 首先協調者向所有參與者發送事務內容,詢問是否可以執行事務提交操作,并等待參與者的響應。
- 參與者執行事務操作,并將 undo 和 redo 信息記入事務日志中。
- 如果參與者成功執行了事務操作,就反饋給協調者 yes 響應,表示事務可以執行,否則反饋 no 響應,表示事務不可以執行。
第二個階段是執行事務提交:
-
協調者根據參與者的反饋情況來決定是否進行事務提交操作, 如果所有參與者反饋的都是 yes 響應,就會執行事務提交:
- 首先協調者向所有參與者發出 commit 請求。
- 參與者收到 commit 請求后,執行事務提交操作。
- 參與者完成事務提交后,釋放事務執行期間占用的資源,并向協調者發送 ack 消息。
- 協調者收到所有參與者反饋的 ack 消息后,完成事務提交。
-
如果有一個參與者反饋的是 no 響應,或者等待超時后,協調者依然沒有接收到所有參與者的響應,就會中斷事務:
- 協調者向所有參與者發出回滾請求。
- 參與者收到回滾請求后,利用第一階段中記錄的 undo 信息來執行事務回滾操作。
- 參與者完成事務回滾后,釋放事務執行期間占用的資源,并向協調者發送 ack 消息。
- 協調者收到所有參與者反饋的 ack 消息后,完成事務中斷。
優點:原理簡單,實現方便。
缺點:
3PC
3PC 是 2PC 的改進版,它將 2PC 的提交事務請求過程分為
第一個階段是 CanCommit:
- 協調者向所有參與者發送包含事務內容的 canCommit 請求,詢問是否可以執行事務提交操作,并等待參與者的響應。
- 參與者收到請求后,如果認為自己可以執行事務,就反饋 yes 響應,進入預備狀態,否則反饋 no 響應。
第二個階段是 PreCommit:
-
協調者根據參與者的反饋情況來決定是否進行事務的 PreCommit 操作,如果所有參與者反饋的都是 yes 響應,就會執行事務預提交:
- 協調者向所有參與者發出 PreCommit 請求,并進入準備階段。
- 參與者收到 PreCommit 請求后,會執行事務操作,并將 undo 和 redo 信息記錄到事務日志中。
- 參與者完成事務操作后,向協調者發送 ack 消息,并等待最終的指令:提交或中斷。
-
如果有一個參與者反饋的是 no 響應,或者等待超時后,協調者依然沒有接收到所有參與者的響應,就會中斷事務:
- 協調者向所有參與者發出中斷請求。
- 參與者收到中止請求或者超時后,都會中斷事務。
第三個階段是 doCommit:
-
該階段進行真正的事務提交,存在兩種情況,第一種情況是執行提交:
- 也就是協調者收到了所有參與者的 ack 響應,它從預提交狀態轉換為提交狀態,并向所有參與者發送 doCommit 請求。
- 參與者收到 doCommit 請求后,正式執行事務提交操作。
- 參與者完成事務提交后,釋放事務執行期間占用的資源,并向協調者發送 ack 消息。
- 協調者收到所有參與者反饋的 ack 消息后,完成事務。
-
第二種情況是中斷事務,也就是如果有一個參與者反饋的是 no 響應,或者等待超時后協調者依然沒有接收到所有參與者的響應,就會中斷事務:
- 協調者向所有參與者發送中斷請求。
- 參與者收到中斷請求后,利用第二階段中記錄的 undo 信息來執行事務回滾操作。
- 參與者完成事務回滾后,釋放事務執行期間占用的資源,并向協調者發送 ack 消息。
- 協調者收到所有參與者反饋的 ack 消息后,完成事務中斷。
優點:和 2PC 相比,3PC 最大的優點是降低了參與者的阻塞范圍,并且能夠在出現單點故障后繼續達成一致。
缺點:在參與者收到 PreCommit 消息后,如果網絡出現分區,協調者和參與者無法正常通信,而參與者依然會進行事務的提交,這會導致數據不一致。
總結
- 上一篇: 如何为BLE 设备实现OTA DFU 空
- 下一篇: HadoopYarn设置Fair Sch