由於二階段提交存在很多的問題，我們對其做了一定的改進，也就是三階段提交，過程圖如下：
主要有2個優化點：
1 引入超時機制。同時在協調者和參與者中都引入超時機制。
2 在第一階段和第二階段中插入乙個準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。
協調者向參與者傳送commit請求，參與者如果可以提交就返回yes響應，否則返回no響應。
協調者根據參與者的反應情況來決定是否可以進行事務的precommit操作。根據響應情況，有以下兩種可能。
假如協調者從所有的參與者獲得的反饋都是yes響應，那麼就會執行事務的預執行。
1.傳送預提交請求 協調者向參與者傳送precommit請求，並進入prepared階段。假如有任何乙個參與者向協調者傳送了no響應，或者等待超時之後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。2.事務預提交 參與者接收到precommit請求後，會執行事務操作，並將undo和redo資訊記錄到事務日誌中。
3.響應反饋 如果參與者成功的執行了事務操作，則返回ack響應，同時開始等待最終指令。
1.傳送中斷請求 協調者向所有參與者傳送abort請求。該階段進行真正的事務提交，也可以分為以下兩種情況。2.中斷事務 參與者收到來自協調者的abort請求之後（或超時之後，仍未收到協調者的請求），執行事務的中斷。
執行提交
1.傳送提交請求協調接收到參與者傳送的ack響應，那麼他將從預提交狀態進入到提交狀態。並向所有參與者傳送docommit請求。中斷事務協調者沒有接收到參與者傳送的ack響應（可能是接受者傳送的不是ack響應，也可能響應超時），那麼就會執行中斷事務。2.事務提交參與者接收到docommit請求之後，執行正式的事務提交。並在完成事務提交之後釋放所有事務資源。
3.響應反饋事務提交完之後，向協調者傳送ack響應。
4.完成事務協調者接收到所有參與者的ack響應之後，完成事務。
1.傳送中斷請求協調者向所有參與者傳送abort請求2.事務回滾參與者接收到abort請求之後，利用其在階段二記錄的undo資訊來執行事務的回滾操作，並在完成回滾之後釋放所有的事務資源。
3.反饋結果參與者完成事務回滾之後，向協調者傳送ack訊息
4.中斷事務協調者接收到參與者反饋的ack訊息之後，執行事務的中斷。
在docommit階段，如果參與者無法及時接收到來自協調者的docommit或者rebort請求時，會在等待超時之後，會繼續進行事務的提交。（其實這個應該是基於概率來決定的，當進入第三階段時，說明參與者在第二階段已經收到了precommit請求，那麼協調者產生precommit請求的前提條件是他在第二階段開始之前，收到所有參與者的cancommit響應都是yes。（一旦參與者收到了precommit，意味他知道大家其實都同意修改了）所以，一句話概括就是，當進入第三階段時，由於網路超時等原因，雖然參與者沒有收到commit或者abort響應，但是他有理由相信：成功提交的機率很大。 ）相對於2pc，3pc主要解決的單點故障問題，並減少阻塞，因為一旦參與者無法及時收到來自協調者的資訊之後，他會預設執行commit。而不會一直持有事務資源並處於阻塞狀態。但是這種機制也會導致資料一致性問題，因為，由於網路原因，協調者傳送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時之後執行了commit操作。這樣就和其他接到abort命令並執行回滾的參與者之間存在資料不一致的情況。 二階段提交協議，三階段提交協議
其實三者都是為了解決分布式一致性問題而存在的協議和演算法。首先先來了解幾個概念。協調者 coordinator 在分布式系統中，當事務操作需要跨越多個分布式節點的時候，為了保持分布式處理的acid特性，需要引入它來統一排程所有節點的執行邏輯。參與者 participant 協調者排程的這些節點就是參...
兩階段與三階段提交協議
首先了解一下為什麼要使用多階段提交協議這個東西。在分布式系統中，我們會存在乙個方法對多個庫進行插入或更新。但是每個節點只能知曉自己的操作是成功或失敗，卻無法知道其他節點的成功和失敗。這樣的話就會導致資料的不一致性。當乙個事務跨越了多個節點時，為了保持資料的一致性，所以就引進了兩階段提交協議這個東西。...
兩階段提交協議和三階段提交協議
jee的xa協議就是根據兩階段提交來保證事務的完整性，並實現分布式服務化的強一致性。兩階段協議提交的流程 準備階段 協調者向參與者發起指令，參與者評估自己的狀態。如果參與者評估指令可以完成，則會寫redo或者undo的日誌，然後鎖定資源，執行操作，但不提交 提交階段 如果每個參與者明確返回準備成功，...