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

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

既然叫兩階段提交，肯定是分為兩個階段。

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

第一階段

順利的情況下

事務協調者的節點會首先向所有的參與者節點發送 Prepare(預備) 請求。

在接到 Prepare(預備) 請求之后，每一個參與者節點會各自執行與事務有關的數據更新，寫入Undo Log和Redo Log。

參與者執行成功，暫時不提交事務，向事務協調節點返回 done(完成) 消息。

進入第二階段

出錯時

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

事務協調者的節點會首先向所有的參與者節點發送 Prepare(預備) 請求。

在接到 Prepare(預備) 請求之后，每一個參與者節點會各自執行與事務有關的數據更新，寫入Undo Log和Redo Log。

參與者執行失敗，返回失敗消息。

協調者中斷事務

中斷事物

任何一個參與者向協調者反饋了 No 響應，或者在等待超時之后，協調者尚無法接收到所有參與者的反饋響應，那么就會中斷事物。

發送回滾請求。協調者向所有參與者節點發出 Rollback 請求。

事物回滾。參與者收到Rollback請求之后，會利用其在階段一種記錄的 Undo 信息來執行事務回滾操作，并在完成回滾之后釋放在整個事物執行期間占用的資源。

反饋事物回滾結果。參與者在完成事物回滾之后，向協調者發送 Ack 消息。

中斷事務

第二階段

在XA分布式事務的第二階段，如果事務協調節點在之前所收到都是正向返回，那么它將會向所有事務參與者發出Commit請求。

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

當事務協調者接收到所有事務參與者的“完成”反饋，整個分布式事務完成。

缺點

兩階段提交涉及多次節點間的網絡通信，通信時間長！且在整個過程中，所有節點都處于阻塞狀態，所有節點所持有的資源(例如數據庫數據，本地文件等)都處于鎖定狀態

單點故障。由于協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那么所有的參與者還都處于鎖定事務資源的狀態中，而無法繼續完成事務操作。(如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者宕機導致的參與者處于阻塞狀態的問題)

數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求之后，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。于是整個分布式系統便出現了數據不一致性的現象。

總結

以上是生活随笔為你收集整理的oracle二阶段事物,分布式事务 两阶段提交 (2PC)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。