將二階段提交的「提交事務請求」過程分為兩步。
三階段包括：cancommit、precommit、docommit
1、事務詢問：協調者向各參與者傳送包含事務那內容的cancommit請求。詢問是否可以執行事務提交操作。並等待響應。
2、詢問響應：各參與者可以順利執行任務，返回響應yes。並進入預備狀態。否則響應no
根據各參與者的響應決定是否進行事務的precommit操作。包含兩種情況：
事務預提交：參與者全部返回yes
1、 預提交請求：協調者向各參與者傳送precommit請求，並進入prepared階段。
2、事務預提交：參與者接收到precommit請求後，會執行事務操作。並將undo和redo資訊記錄到事務日誌中。
3、反饋響應：反饋給協調者ack響應。並等待最終指令。
中斷事務：任意參與者返回no，或等待超時
1、中斷請求：協調者向各參與者傳送abort請求
2、中斷事務：無論接收到abort請求，或是等待請求超時，參與者都會中斷請求。
該階段進行真正的事務提交。有以下兩者情況
執行提交：
1、提交請求：協調者收到所有參與者的ack響應，將從 「預提交狀態」 變為 「提交狀態」 ，並向各參與者傳送docommit請求
2、事務提交：參與者收到docommit請求，會正式執行事務提交操作，並在完成提交後釋放占用資源。
3、反饋結果：各參與者執行完，向協調者傳送ack訊息
4、完成事務：協調者收到所有的參與者的反饋ack訊息後，完成事務。
中斷事務：任意參與者返回no，或等待超時
1、中斷請求：協調者向參與者節點傳送abort請求
2、事務回滾：參與者收到abort請求後，會利用其在第二階段中記錄的undo資訊來執行事務回滾操作。並釋放占用資源。
3、反饋結果：完成回滾後傳送ack訊息
4、中斷事務：接收到所有的參與者的ack訊息後，中斷事務。
注意： 進入第三階段會存在兩種故障
1、協調者出現問題
2、協調者和參與者之間網路出現問題
無論出現那種情況，最終都會導致參與者無法及時收到來自協調者的docommit或abort請求。對於這種情況，參與者都會在等待超時後，繼續進行事務的提交。
相較於二階段提交，三階段降低了參與者的阻塞範圍，並且能在出現單點故障後繼續打成一致。
去除阻塞的同時，也引入新的問題，那就是在參與者接收到precommit請求後，如果網路出現分割槽，測試協調者和參與者無法通訊。參與者依然會提交事務，導致資料不一致。
分布式事務 二階段提交與三階段提交
一 二階段提交演算法描述 在分布式系統中，事務往往包含有多個參與者的活動，單個參與者上的活動是能夠保證原子性的，而多個參與者之間原子性的保證則需要通過兩階段提交來實現，兩階段提交是分布式事務實現的關鍵。很明顯，兩階段提交保證了分布式事務的原子性，這些子事務要麼都做，要麼都不做。而資料庫的一致性是由資...
分布式事務 二階段提交與三階段提交
一 二階段提交演算法描述 在分布式系統中，事務往往包含有多個參與者的活動，單個參與者上的活動是能夠保證原子性的，而多個參與者之間原子性的保證則需要通過兩階段提交來實現，兩階段提交是分布式事務實現的關鍵。很明顯，兩階段提交保證了分布式事務的原子性，這些子事務要麼都做，要麼都不做。而資料庫的一致性是由資...
分布式事務 二階段提交與三階段提交
一 二階段提交演算法描述 在分布式系統中，事務往往包含有多個參與者的活動，單個參與者上的活動是能夠保證原子性的，而多個參與者之間原子性的保證則需要通過兩階段提交來實現，兩階段提交是分布式事務實現的關鍵。很明顯，兩階段提交保證了分布式事務的原子性，這些子事務要麼都做，要麼都不做。而資料庫的一致性是由資...