兩階段提交2PC 和 三階段提交3pc

一、概念

二階段提交2PC(Two phase Commit)是指,在分佈式系統裏,爲了保證所有節點在進行事務提交時保持一致性的一種算法。
2PC,二階段提交協議,即將事務的提交過程分爲兩個階段來進行處理:準備階段和提交階段。事務的發起者稱協調者,事務的執行者稱參與者。

二、背景

在分佈式系統裏,每個節點都可以知曉自己操作的成功或者失敗,卻無法知道其他節點操作的成功或失敗。
當一個事務跨多個節點時,爲了保持事務的原子性與一致性,需要引入一個協調者(Coordinator)來統一掌控所有參與者(Participant)的操作結果,並指示它們是否要把操作結果進行真正的提交(commit)或者回滾(rollback)。

三、思路

2PC顧名思義分爲兩個階段,其實施思路可概括爲:
(1)投票階段(voting phase):參與者將操作結果通知協調者;
(2)提交階段(commit phase):收到參與者的通知後,協調者再向參與者發出通知,根據反饋情況決定各參與者是否要提交還是回滾;

四、缺陷

算法執行過程中,所有節點都處於阻塞狀態,所有節點所持有的資源(例如數據庫數據,本地文件等)都處於封鎖狀態。
典型場景爲:

  • (1)某一個參與者發出通知之前,所有參與者以及協調者都處於阻塞狀態;

  • (2)在協調者發出通知之前,所有參與者都處於阻塞狀態;

另外,如有協調者或者某個參與者出現了崩潰,爲了避免整個算法處於一個完全阻塞狀態,往往需要藉助超時機制來將算法繼續向前推進,故此時算法的效率比較低。
總的來說,2PC是一種比較保守的算法。

五、舉例

甲乙丙丁四人要組織一個會議,需要確定會議時間,不妨設甲是協調者,乙丙丁是參與者。

投票階段:

  • (1)甲發郵件給乙丙丁,週二十點開會是否有時間;
  • (2)甲回覆有時間;
  • (3)乙回覆有時間;
  • (4)丙遲遲不回覆,此時對於這個活動,甲乙丙均處於阻塞狀態,算法無法繼續進行;
  • (5)丙回覆有時間(或者沒有時間);
    提交階段:
  • (1)協調者甲將收集到的結果反饋給乙丙丁(什麼時候反饋,以及反饋結果如何,在此例中取決與丙的時間與決定);
  • (2)乙收到;
  • (3)丙收到;
  • (4)丁收到;

六、結論

2PC的缺陷

  • 1、同步阻塞:最大的問題即同步阻塞,即:所有參與事務的邏輯均處於阻塞狀態。
  • 2、單點:協調者存在單點問題,如果協調者出現故障,參與者將一直處於鎖定狀態。
  • 3、腦裂:在階段2中,如果只有部分參與者接收並執行了Commit請求,會導致節點數據不一致。
    由於2PC存在如上同步阻塞、單點、腦裂問題,因此又出現了2PC的改進方案,即3PC。

3PC

3PC,三階段提交協議,是2PC的改進版本,即將事務的提交過程分爲CanCommit、PreCommit、do Commit三個階段來進行處理。

階段1:CanCommit
  1、協調者向所有參與者發出包含事務內容的CanCommit請求,詢問是否可以提交事務,並等待所有參與者答覆。
  2、參與者收到CanCommit請求後,如果認爲可以執行事務操作,則反饋YES並進入預備狀態,否則反饋NO。

階段2:PreCommit

此階段分兩種情況:
  1、所有參與者均反饋YES,即執行事務預提交。
  2、任何一個參與者反饋NO,或者等待超時後協調者尚無法收到所有參與者的反饋,即中斷事務。

事務預提交:(所有參與者均反饋YES時)
  1、協調者向所有參與者發出PreCommit請求,進入準備階段。
  2、參與者收到PreCommit請求後,執行事務操作,將Undo和Redo信息記入事務日誌中(但不提交事務)。
  3、各參與者向協調者反饋Ack響應或No響應,並等待最終指令。

中斷事務:(任何一個參與者反饋NO,或者等待超時後協調者尚無法收到所有參與者的反饋時)
  1、協調者向所有參與者發出abort請求。
  2、無論收到協調者發出的abort請求,或者在等待協調者請求過程中出現超時,參與者均會中斷事務。

階段3:do Commit

此階段也存在兩種情況:
  1、所有參與者均反饋Ack響應,即執行真正的事務提交。
  2、任何一個參與者反饋NO,或者等待超時後協調者尚無法收到所有參與者的反饋,即中斷事務。

提交事務:(所有參與者均反饋Ack響應時)
  1、如果協調者處於工作狀態,則向所有參與者發出do Commit請求。
  2、參與者收到do Commit請求後,會正式執行事務提交,並釋放整個事務期間佔用的資源。
  3、各參與者向協調者反饋Ack完成的消息。
  4、協調者收到所有參與者反饋的Ack消息後,即完成事務提交。

中斷事務:(任何一個參與者反饋NO,或者等待超時後協調者尚無法收到所有參與者的反饋時)
  1、如果協調者處於工作狀態,向所有參與者發出abort請求。
  2、參與者使用階段1中的Undo信息執行回滾操作,並釋放整個事務期間佔用的資源。
  3、各參與者向協調者反饋Ack完成的消息。
  4、協調者收到所有參與者反饋的Ack消息後,即完成事務中斷。

注意:進入階段三後,無論協調者出現問題,或者協調者與參與者網絡出現問題,都會導致參與者無法接收到協調者發出的do Commit請求或abort請求。此時,參與者都會在等待超時之後,繼續執行事務提交。

附示意圖如下:

image.png

3PC的優點和缺陷

優點:降低了阻塞範圍,在等待超時後協調者或參與者會中斷事務。避免了協調者單點問題,階段3中協調者出現問題時,參與者會繼續提交事務。

缺陷:腦裂問題依然存在,即在參與者收到PreCommit請求後等待最終指令,如果此時協調者無法與參與者正常通信,會導致參與者繼續提交事務,造成數據不一致。

後記

無論2PC或3PC,均無法徹底解決分佈式一致性問題。
  解決一致性問題,唯有Paxos 。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章