一、2PC
2PC即兩階段提交協議，是將整個事務流程分為兩個階段，准備階段（Prepare phase）、提交階段（commit phase），2是指兩個階段，P是指准備階段，C是指提交階段
整個事務過程由事務管理器和參與者組成，事務管理器負責 決策整個分布式事務的提交和回滾，事務參與者負責自己本地事務的提交和回滾
在計算機中部分關系數據庫如Oracle、MySQL支持兩階段提交協議，如下圖：
-
准備階段（Prepare phase）：事務管理器給每個參與者發送Prepare消息，每個數據庫參與者在本地執行事 務，並寫本地的Undo/Redo日志，此時事務沒有提交。 （Undo日志是記錄修改前的數據，用於數據庫回滾，Redo日志是記錄修改后的數據，用於提交事務后寫入數 據文件）
-
提交階段（commit phase）：如果事務管理器收到了參與者的執行失敗或者超時消息時，直接給每個參與者 發送回滾(Rollback)消息；否則，發送提交(Commit)消息；參與者根據事務管理器的指令執行提交或者回滾操 作，並釋放事務處理過程中使用的鎖資源。注意:必須在最后階段釋放鎖資源。 下圖展示了2PC的兩個階段，分成功和失敗兩個情況說明：
成功情況：
失敗情況
- 階段一 提交事務請求
-
協調者向所有的參與者節點發送事務內容，詢問是否可以執行事務操作，並等待其他參與者節點的
反饋 -
參與者節點收到協調者的事務操作后，執行操作，但不提交
-
各參與者節點反饋給協調者，事務是否可以執行
- 階段二 事務提交
根據一階段各個參與者節點反饋的ack,如果所有參與者節點反饋ack，則執行事務提交，否則中斷事務
事務提交：
- 協調者向各個參與者節點發送commit請求
- 參與者節點接受到commit請求后，執行事務的提交操作
- 各參與者節點完成事務提交后，向協調者返送提交commit成功確認消息
- 協調者接受各個參與者節點的ack后，完成事務commit
中斷事務：
1、發送回滾請求
2、各個參與者節點回滾事務
3、反饋給協調者事務回滾結果
4、協調者接受各參與者節點ack后回滾事務
二階段提交存在的問題：
-
同步阻塞
二階段提交過程中，所有參與事務操作的節點處於同步阻塞狀態，無法進行其他的操作 -
單點問題
參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那么所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者宕機導致的參與者處於阻塞狀態的問題） -
腦裂導致數據不一致
如果分布式節點出現網絡分區，某些參與者未收到commit提交命令。則出現部分參與者完成數據提
交。未收到commit的命令的參與者則無法進行事務提交，整個分布式系統便出現了數據不一致性現
象。
二、3PC 三階段提交
3PC是2PC的改進版，實質是將2PC中提交事務請求拆分為兩步，形成了CanCommit、PreCommit、
doCommit三個階段的事務一致性協議
階段一 : CanCommit
1、事務詢問
2、各參與者節點向協調者反饋事務詢問的響應
階段二 : PreCommit
根據階段一的反饋結果分為兩種情況
- 執行事務預提交
- 發送預提交請求
協調者向所有參與者節點發送preCommit請求，進入prepared階段 - 事務預提交
各參與者節點接受到preCommit請求后，執行事務操作 - 各參與者節點向協調者反饋事務執行
- 發送預提交請求
- 中斷事務
任意一個參與者節點反饋給協調者響應No時，或者在等待超時（協調者等待參與者）后，協調者還未收到參與者的反
饋，就中斷事務，中斷事務分為兩步：
1）協調者向各個參與者節點發送abort請求
2）參與者收到abort請求，或者等待超時時間后，中斷事務(參與者等待協調者)
階段三 : doCommit
1、執行提交
- 發送提交請求
協調者向所有參與者節點發送doCommit請求 - 事務提交
各參與者節點接受到doCommit請求后，執行事務提交操作 - 反饋事務提交結果
- 事務完成
協調者接受各個參與者反饋的ack后，完成事務
2、中斷事務
- 參與者接受到abort請求后，執行事務回滾
- 參與者完成事務回滾以后，向協調者發送ack
- 協調者接受回滾ack后，回滾事務
3PC相較於2PC而言，解決了協調者掛點后參與者無限阻塞和單點問題，但是仍然無法解決網絡分
區問題