分佈式事務 三階段提交 (3PC)

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

缺點

• 依然沒有解決數據不一致問題
• 依然涉及屢次節點間的網絡通訊，通訊時間長