分佈式事務 兩階段提交 (2PC)

兩階段提交（2PC） 是 Oracle Tuxedo 系統提出的 XA 分佈式事務協議的其中一種實現方式。

XA協議中有兩個重要角色：事務協調者和事務參與者

既然叫兩階段提交，確定是分爲兩個階段。

Java 生態下可使用atomikos來快速實現兩階段提交的分佈式事務。

第一階段

順利的狀況下

1. 事務協調者的節點會首先向全部的參與者節點發送 Prepare(預備) 請求。
2. 在接到 Prepare(預備) 請求以後，每個參與者節點會各自執行與事務有關的數據更新，寫入Undo Log和Redo Log。
3. 參與者執行成功，暫時不提交事務，向事務協調節點返回 done(完成) 消息。
4. 進入第二階段

出錯時

在XA的第一階段，若是某個事務參與者反饋失敗消息，說明該節點的本地事務執行不成功，必須回滾。

1. 事務協調者的節點會首先向全部的參與者節點發送 Prepare(預備) 請求。
2. 在接到 Prepare(預備) 請求以後，每個參與者節點會各自執行與事務有關的數據更新，寫入Undo Log和Redo Log。
3. 參與者執行失敗，返回失敗消息。
4. 協調者中斷事務

中斷事物

任何一個參與者向協調者反饋了 No 響應，或者在等待超時以後，協調者尚沒法接收到全部參與者的反饋響應，那麼就會中斷事物。

1. 發送回滾請求。協調者向全部參與者節點發出 Rollback 請求。
2. 事物回滾。參與者收到Rollback請求以後，會利用其在階段一種記錄的 Undo 信息來執行事務回滾操做，並在完成回滾以後釋放在整個事物執行期間佔用的資源。
3. 反饋事物回滾結果。參與者在完成事物回滾以後，向協調者發送 Ack 消息。
4. 中斷事務

第二階段

在XA分佈式事務的第二階段，若是事務協調節點在以前所收到都是正向返回，那麼它將會向全部事務參與者發出Commit請求。

接到Commit請求以後，事務參與者節點會各自進行本地的事務提交，並釋放鎖資源。當本地事務完成提交後，將會向事務協調者返回「完成」消息。

當事務協調者接收到全部事務參與者的「完成」反饋，整個分佈式事務完成。

缺點

1. 兩階段提交涉及屢次節點間的網絡通訊，通訊時間長！且在整個過程當中，全部節點都處於阻塞狀態，全部節點所持有的資源（例如數據庫數據，本地文件等）都處於鎖定狀態

2. 單點故障。因爲協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤爲在第二階段，協調者發生故障，那麼全部的參與者還都處於鎖定事務資源的狀態中，而沒法繼續完成事務操做。（若是是協調者掛掉，能夠從新選舉一個協調者，可是沒法解決由於協調者宕機致使的參與者處於阻塞狀態的問題）

3. 數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求以後，發生了局部網絡異常或者在發送commit請求過程當中協調者發生了故障，這回致使只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求以後就會執行commit操做。可是其餘部分未接到commit請求的機器則沒法執行事務提交。因而整個分佈式系統便出現了數據不一致性的現象。