二階段提交協議，三階段提交協議

其實三者都是為了解決分布式一致性問題而存在的協議和演算法。首先先來了解幾個概念。

協調者（coordinator）：在分布式系統中，當事務操作需要跨越多個分布式節點的時候，為了保持分布式處理的acid特性，需要引入它來統一排程所有節點的執行邏輯。

參與者（participant）：協調者排程的這些節點就是參與者了

一：二階段提交協議

1.投票階段

2.執行階段

2.1如果都是返回yes，則執行事務提交

2.2如果有返回是no，則執行中斷事務

一階段

二階段

那麼二階段提交會有哪些問題呢？

首先，由於投票階段需要等待所有的都給協調者反饋才會進行下乙個階段，那麼顯而易見的出現了同步阻塞的問題。每個參與者都會等待，直到到了下乙個階段。

其次，我們考慮這麼一種情況，如果協調者掛了，是不是都會一直等待？這也就是我們所說的單點問題。

再然後，如果在二階段在協調者傳送commit的時候出現了區域性的網路異常，導致有一部分參與者收到了訊息，一部分參與者並沒有收到訊息，這就導致了資料的不一致。

最後，這種方式其實他過於的保守了。

二：三階段提交

1.cancommit階段

協調者傳送cancommit的請求。參與者返回是否可以的響應。

2.precommit階段

2.1若cancommit階段都是返回的yes則直接precommit，各個參與者記錄預提交的redo和undo日誌。

2.2若有返回為no的參與者，協調者向所有的參與者傳送abort命令。或者等待超時後參與者直接中斷事務。

3.docommit階段

3.1若都成功，則直接返回ack，參與者提交事務，完成整個流程。

3.2若協調者發現其中的參與者有傳送no的，則向所有的參與者傳送abort，參與者接到訊息或者等待超時後中斷任務，進行事務回滾。

仔細的同學可能發現了，如果第三階段我協調者掛了，或者說出現協調者和參與者無法通訊，其他的參與者還是會執行docommit，那不是必定出現資料不一致嘛？是的，這就是三階段提交的缺點，但是相較於二階段提交，它很大程度上減小了參與者的阻塞範圍，並且就算出現單點問題最後參與者還是能達成一致，這是我們希望看到的。

兩階段提交協議和三階段提交協議

jee的xa協議就是根據兩階段提交來保證事務的完整性，並實現分布式服務化的強一致性。兩階段協議提交的流程 準備階段 協調者向參與者發起指令，參與者評估自己的狀態。如果參與者評估指令可以完成，則會寫redo或者undo的日誌，然後鎖定資源，執行操作，但不提交 提交階段 如果每個參與者明確返回準備成功，...

分布式一致性 二階段提交協議，三階段提交協議

分布式系統，這早已不是什麼新鮮的東西了，在分布式系統的架構設計過程中，往往會存在分布式一致性的問題，經過前人的辛苦 提出了二階段提交協議，三階段提交協議，paxos演算法等等，用來解決分布式一致性的問題。今天我就講一下，二階段提交協議和三階段提交協議的過程，以及它們的優缺點。2pc，就是二階段提交協...

三階段提交

由於二階段提交存在很多的問題，我們對其做了一定的改進，也就是三階段提交，過程圖如下 主要有2個優化點 1 引入超時機制。同時在協調者和參與者中都引入超時機制。2 在第一階段和第二階段中插入乙個準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。協調者向參與者傳送commit請求，參與者如果可...