兩階段提交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請求。此時，參與者都會在等待超時之後，繼續執行事務提交。

附示意圖如下：

3PC的優點和缺陷

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

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

後記

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