三阶段提交

三阶段提交（），也叫三阶段提交协议（），是在電腦网络及数据库的范畴下，令一个分布式系统内的所有节点能够执行事务的提交的一种分布式算法。三阶段提交是为了解决两阶段提交协议的缺点而设计的。

与两阶段提交不同的是，三阶段提交是一種“非阻塞”的协议。三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段，令原先在两阶段提交中，参与者在投票之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题Distributed Systems: Concepts and Design, G. Coulouris, J, Dollimore, Tim K., Gordon Blair, Fifth edition, Pearson, 2012得以解决。

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

算法原理
在提交阶段，如果协调器和队列成员都发生故障，两阶段提交协议无法可靠地恢复。如果只有协调器发生故障，而没有队列成员收到提交消息，则可以安全地推断没有发生提交。但是，如果协调器和队列成员都发生故障，则发生故障的队列成员可能是第一个收到通知并实际执行了提交的成员。即使选择了新的协调器，它也无法自信地继续操作，直到收到所有队列成员的同意，因此必须阻塞直到所有队列成员响应。

三阶段提交协议通过引入准备提交状态消除了这个问题。如果协调器在发送预提交消息之前失败，则队列将一致认为操作已中止。在所有队列成员都确认他们准备好提交之前，协调器不会发送提交消息。这消除了任何队列成员在所有队列成员都知道这样做的决定之前实际完成事务的可能性（这种模糊性导致两阶段提交协议中需要无限期阻塞）。

 解决方案 
上面介绍的预提交阶段可以帮助系统在提交阶段的参与者或协调者和参与者都失败时进行恢复。当恢复协调者在两阶段提交的提交阶段协调者失败后接管时，新的预提交会派上用场：在查询参与者时，如果它了解到某些节点处于提交阶段，则它会假定崩溃前的上一个协调者已做出提交的决定。因此它可以引导协议提交。类似地，如果参与者说它没有收到PrepareToCommit消息，那么新的协调器甚至可以假设前一个协调器在完成PrepareToCommit阶段之前就已经失败了。因此，它可以安全地假设没有参与者提交更改，从而安全地中止事务。

参考资料

Category:数据管理
Category:事务处理