三階段提交

三階段提交（英語：Three-phase commit），也叫三階段提交協議（英語：Three-phase commit protocol），是在電腦網絡及資料庫的範疇下，令一個分布式系統內的所有節點能夠執行事務的提交的一種分布式算法。三階段提交是為了解決兩階段提交協議的缺點而設計的。

與兩階段提交不同的是，三階段提交是一種「非阻塞」的協議。三階段提交在兩階段提交的第一階段與第二階段之間插入了一個準備階段，令原先在兩階段提交中，參與者在投票之後，由於協調者發生崩潰或錯誤，而導致參與者處於無法知曉是否提交或者中止的「不確定狀態」所產生的可能相當長的延時的問題得以解決。

舉例來說，假設有一個決策小組由一個主持人負責與多位組員以電話聯絡方式協調是否通過一個提案，以兩階段提交來說，主持人收到一個提案請求，打電話跟每個組員詢問是否通過並統計回覆，然後將最後決定打電話通知各組員。要是主持人在跟第一位組員通完電話後失憶，而第一位組員在得知結果並執行後老人痴呆，那麼即使重新選出主持人，也沒人知道最後的提案決定是什麼，也許是通過，也許是駁回，不管大家選擇哪一種決定，都有可能與第一位組員已執行過的真實決定不一致，老闆就會認為決策小組溝通有問題而解僱。三階段提交即是引入了另一個步驟，主持人打電話跟組員通知請準備通過提案，以避免沒人知道真實決定而造成決定不一致的失業危機。而三階段提交為什麼能夠解決二階段提交的問題呢？回到剛剛提到的狀況，在主持人通知完第一位組員請準備通過後兩人意外失憶，即使沒人知道全體在第一階段的決定為何，全體決策組員仍可以重新協調過程或直接否決，不會因出現不一致決定而失業。那麼當主持人通知完全體組員請準備通過並得到大家的再次確定後進入第三階段，當主持人通知第一位組員請通過提案後兩人意外失憶，這時候其他組員再重新選出主持人後，仍可以知道目前至少是處於準備通過提案階段，表示第一階段大家都已經決定要通過了，此時便可以直接通過。

算法原理

在提交階段，如果協調器和隊列成員都發生故障，兩階段提交協議無法可靠地恢復。如果只有協調器發生故障，而沒有隊列成員收到提交消息，則可以安全地推斷沒有發生提交。但是，如果協調器和隊列成員都發生故障，則發生故障的隊列成員可能是第一個收到通知並實際執行了提交的成員。即使選擇了新的協調器，它也無法自信地繼續操作，直到收到所有隊列成員的同意，因此必須阻塞直到所有隊列成員響應。

三階段提交協議通過引入準備提交狀態消除了這個問題。如果協調器在發送預提交消息之前失敗，則隊列將一致認為操作已中止。在所有隊列成員都確認他們準備好提交之前，協調器不會發送提交消息。這消除了任何隊列成員在所有隊列成員都知道這樣做的決定之前實際完成事務的可能性（這種模糊性導致兩階段提交協議中需要無限期阻塞）。

解決方案

上面介紹的預提交階段可以幫助系統在提交階段的參與者或協調者和參與者都失敗時進行恢復。當恢復協調者在兩階段提交的提交階段協調者失敗後接管時，新的預提交會派上用場：在查詢參與者時，如果它了解到某些節點處於提交階段，則它會假定崩潰前的上一個協調者已做出提交的決定。因此它可以引導協議提交。類似地，如果參與者說它沒有收到PrepareToCommit消息，那麼新的協調器甚至可以假設前一個協調器在完成PrepareToCommit階段之前就已經失敗了。因此，它可以安全地假設沒有參與者提交更改，從而安全地中止事務。