三階段提交 (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命令並執行回滾的參與者之間存在資料不一致的情況。

缺點

• 依然沒有解決資料不一致問題
• 依然涉及多次節點間的網路通訊，通訊時間長