分散式事務 三階段提交 (3PC)
阿新 • • 發佈:2019-12-31
三階段提交 (3PC)是在兩階段提交 (2PC)的基礎上進行優化。
主要涉及兩個方面
- 引入超時機制:在協調者和參與者中引入超時機制
- 細分階段:把兩階段提交協議的第一個階段再次細分成詢問階段、和預備階段
過程
整個事務分為 CanCommit、PreCommit、DoCommit 三個階段。
CanCommit 階段
-
事務詢問:協調者向參與者傳送CanCommit請求。詢問是否可以執行事務提交操作。然後開始等待參與者的響應;
-
響應反饋:參與者接到CanCommit請求之後,正常情況下,如果其自身認為可以順利執行事務,則返回Yes響應,並進入預備狀態。否則反饋No;
PreCommit 階段
協調者根據參與者的反應情況來決定是否可以進行事務的PreCommit操作。根據響應情況,有以下兩種可能:
情況1:
假如協調者從所有的參與者獲得的反饋都是Yes響應,那麼就會執行事務的預執行
- 傳送預提交請求:協調者向參與者傳送PreCommit請求,並進入Prepared階段
- 事務預提交:參與者接收到PreCommit請求後,會執行事務操作,並將undo和redo資訊記錄到事務日誌中
- 響應反饋:如果參與者成功的執行了事務操作,則返回ACK響應,同時開始等待最終指令
情況2:
假如有任何一個參與者向協調者傳送了No響應,或者等待超時之後,協調者都沒有接到參與者的響應,那麼就執行事務的中斷。
- 傳送中斷請求:協調者向所有參與者傳送abort請求
- 中斷事務:參與者收到來自協調者的abort請求之後(或超時之後,仍未收到協調者的請求),執行事務的中斷
doCommit 階段
該階段進行真正的事務提交,分為以下兩種情況:
情況1:
接收到所有參與者傳送的ACK響應,執行提交
- 傳送提交請求:協調接收到參與者傳送的ACK響應,那麼他將從預提交狀態進入到提交狀態。並向所有參與者傳送doCommit請求
- 事務提交:參與者接收到doCommit請求之後,執行正式的事務提交。並在完成事務提交之後釋放所有事務資源
- 響應反饋:事務提交完之後,向協調者傳送Ack響應
- 完成事務:協調者接收到所有參與者的ack響應之後完成事務
情況2:
協調者沒有接收到參與者傳送的ACK響應,中斷事務
- 傳送中斷請求:協調者向所有參與者傳送abort請求
- 事務回滾:參與者接收到abort請求之後,利用其在階段二記錄的undo資訊來執行事務的回滾操作,並在完成回滾之後釋放所有的事務資源
- 反饋結果:參與者完成事務回滾之後,向協調者傳送ACK訊息
- 中斷事務:協調者接收到參與者反饋的ACK訊息之後,執行事務的中斷
2PC與3PC的區別
相對於2PC,3PC主要解決的單點故障問題,並減少阻塞,因為一旦參與者無法及時收到來自協調者的資訊之後,他會預設執行commit。而不會一直持有事務資源並處於阻塞狀態。但是這種機制也會導致資料一致性問題,因為,由於網路原因,協調者傳送的abort響應沒有及時被參與者接收到,那麼參與者在等待超時之後執行了commit操作。這樣就和其他接到abort命令並執行回滾的參與者之間存在資料不一致的情況。
缺點
- 依然沒有解決資料不一致問題
- 依然涉及多次節點間的網路通訊,通訊時間長