為了解決分布式一致性問題，在長期的探索研究過程中，湧現出了一大批經典的一致性 協議和演算法，其中最著名的就是二階段提交協議、三階段提交協議和 paxos演算法了。
顧名思義，二階段提交協議是將事務的提交過程分成了兩個階段來進行處理，其執行流程如下。
階段一:提交事務請求
1.事務詢問。
協調者向所有的參與者傳送事務內容，詢問是否可以執行事務提交操作，並開始等待各參與者的響應
2.執行事務。
各參與者節點執行事務操作，並將undo和redo資訊記入事務日誌中。
3.各參與者向協調者反饋事務詢問的響應
如果參與者成功執行了事務操作，那麼就反饋給協調者yes響應，表示事務可以執行;如果參與者沒有成功執行事務，那麼就反饋給協調者no響應，表示事務不可以執行。
由於上面講述的內容在形式上近似是協調者組織各參與者對一次事務操作的投票表態過程，因此二階段提交協議的階段一也被稱為「投票階段」，即各參與者投票表明是否要繼續執行接下去的事務提交操作.
階段二:執行事務提交
在階段二中，協調者會根據各參與者的反饋情況來決定最終是否可以進行事務提交操作，
正常情況下，包含以下兩種可能。
執行事務提交
假如協調者從所有的參與者獲得的反饋都是yes響應，那麼就會執行事務提交。
1.傳送提交請求
協調者向所有參與者節點發出 commit請求。
2.事務提交。
參與者接收到 commit請求後，會正式執行事務提交操作，並在完成提交之後釋放在整個事務執行期間占用的事務資源。
3.反饋事務提交結果。
參與者在完成事務提交之後，向協調者傳送ack訊息。
4.完成事務。
協調者接收到所有參與者反饋的ack訊息後，完成事務。
中斷事務
假如任何乙個參與者向協調者反饋了no響應，或者在等待超時之後，協調者尚無法接收到所有參與者的反饋響應，那麼就會中斷事務。
1.傳送回滾請求。
協調者向所有參與者節點發出 rollback請求。
2.事務回滾。
參與者接收到 rollback請求後，會利用其在階段一中記錄的undo資訊來執行事務回滾操作，並在完成回滾之後釋放在整個事務執行期間占用的資源
3.反饋事務回滾結果。
參與者在完成事務回滾之後，向協調者傳送ack訊息。
4.中斷事務
協調者接收到所有參與者反饋的ack訊息後，完成事務中斷。
以上就是二階段提交過程中，前後兩個階段分別進行的處理邏輯。簡單地講，二階段提交將乙個事務的處理過程分為了投票和執行兩個階段，其核心是對每個事務都採用先嘗試後提交的處理方式，因此也可以將二階段提交看作乙個強一致性的演算法.
優缺點
二階段提交協議的優點:原理簡單，實現方便。
階段提交協議的缺點:同步阻塞、單點問題、腦裂、太過保守
同步阻塞
二階段提交協議存在的最明顯也是最大的乙個問題就是同步阻塞，這會極大地限制分布式系統的效能。在二階段提交的執行過程中，所有參與該事務操作的邏輯都處於阻塞狀態，也就是說，各個參與者在等待其他參與者響應的過程中，將無法進行其他任何操作。
單點問題
在上面的講解過程中，相信讀者可以看出，協調者的角色在整個二階段提交協議起到了非常重要的作用。一旦協調者出現問題，那麼整個二階段提交流程將無法運轉，更為嚴重的是，如果協調者是在階段二**現問題的話，那麼其他參與者將會直處於鎖定事務資源的狀態中，而無法繼續完成事務操作。
資料不一致
在二階段提交協議的階段二，即執行事務提交的時候，當協調者向所有的參與者傳送 commit請求之後，發生了區域性網路異常或者是協調者在尚未傳送完 commit請求之前自身發生了崩潰，導致最終只有部分參與者收到了 commit請求。於是，這部分收到了 commit請求的參與者就會進行事務的提交，而其他沒有收到 commit請求的參與者則無法進行事務提交，於是整個分布式系統便出現了資料不一致性現象。
太過保守
如果在協調者指示參與者進行事務提交詢問的過程中，參與者出現故障而導致協調者始終無法獲取到所有參與者的響應資訊的話，這時協調者只能依靠其自身的超時機制來判斷是否需要中斷事務，這樣的策略顯得比較保守。換句話說，二階段提交協議沒有設計較為完善的容錯機制，任意乙個節點的失敗都會導致整個事務的失敗。
3pc，是 three-phase commit的縮寫，即三階段提交，是2pc的改進版，其將二階段提交協議的「提交事務請求」過程一分為二，形成了由 can commit、 pre commit和 do commit三個階段組成的事務處理協議.
階段一: can commit
1.事務詢問。
協調者向所有的參與者傳送乙個包含事務內容的 can commit請求，詢問是否可以執行事務提交操作，並開始等待各參與者的響應。
2.各參與者向協調者反饋事務詢問的響應。
參與者在接收到來自協調者的 can commit請求後，正常情況下，如果其自身認為可以順利執行事務，那麼會反饋yes響應，並進入預備狀態，否則反饋no響應。
階段二: pre commit
在階段二中，協調者會根據各參與者的反饋情況來決定是否可以進行事務的 precommit操作，正常情況下，包含兩種可能。
執行事務預提交
假如協調者從所有的參與者獲得的反饋都是yes響應，那麼就會執行事務預提交。
1.傳送預提交請求。
協調者向所有參與者節點發出 pre commit的請求，並進入 prepared階段。
2.事務預提交。
參與者接收到 pre commit請求後，會執行事務操作，並將undo和redo資訊記錄到事務日誌中。
3.各參與者向協調者反饋事務執行的響應
如果參與者成功執行了事務操作，那麼就會反饋給協調者ack響應，同時等待最終的指令:提交（ commit）或中止（ abort）。
中斷事務
假如任何乙個參與者向協調者反饋了no響應，或者在等待超時之後，協調者尚無法接收到所有參與者的反饋響應，那麼就會中斷事務。
1.傳送中斷請求。
協調者向所有參與者節點發出 abort請求
2.中斷事務
無論是收到來自協調者的 abort請求，或者是在等待協調者請求過程**現超時，參與者都會中斷事務
階段三: docommit
該階段將進行真正的事務提交，會存在以下兩種可能的情況。
執行提交
1.傳送提交請求
進入這一階段，假設協調者處於正常工作狀態，並且它接收到了來自所有參與者的ack響應，那麼它將從「預提交」狀態轉換到「提交」狀態，並向所有的參與者傳送 docommit請求
2.事務提交
參與者接收到 docommit請求後，會正式執行事務提交操作，並在完成提交之後釋放在整個事務執行期間占用的事務資源。
3.反饋事務提交結果。
參與者在完成事務提交之後，向協調者傳送ack訊息
4.完成事務
協調者接收到所有參與者反饋的ack訊息後，完成事務。
中斷事務
進入這一階段，假設協調者處於正常工作狀態，並且有任意乙個參與者向協調者反饋了no響應，或者在等待超時之後，協調者尚無法接收到所有參與者的反饋響應，那麼就會中斷事務。
1.傳送中斷請求
協調者向所有的參與者節點傳送abot請求。
2.事務回滾。
參與者接收到 abort請求後，會利用其在階段二中記錄的undo資訊來執行事務回滾操作，並在完成回滾之後釋放在整個事務執行期間占用的資源。
3…反饋事務回滾結果。
參與者在完成事務回滾之後，向協調者傳送ack訊息
4.中斷事務
協調者接收到所有參與者反饋的ack訊息後，中斷事務。
需要注意的是，一旦進入階段三，可能會存在以下兩種故障。
與兩階段提交不同的是，三階段提交有兩個改動點。
1、引入超時機制。同時在協調者和參與者中都引入超時機制。
2、在第一階段和第二階段中插入乙個準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。
相對於2pc，3pc主要解決的單點故障問題，並減少阻塞，因為一旦參與者無法及時收到來自協調者的資訊之後，他會預設執行commit。而不會一直持有事務資源並處於阻塞狀態。但是這種機制也會導致資料一致性問題，因為，由於網路原因，協調者傳送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時之後執行了commit操作。這樣就和其他接到abort命令並執行回滾的參與者之間存在資料不一致的情況。
兩階段提交協議：
第一階段，準備階段：協調者向參與者發起指令，參與者評估自己的狀態，如果參與者評估指令可以完成，則會寫redo或者undo日誌，然後鎖定資源，執行操作，但並不提交；
第二階段：如果每個參與者明確返回 都準備成功，則協調者向參與者發生提交指令，參與者釋放鎖定的資源，如果任何乙個參與者明確返回準備失敗，則協調者會發生終止指令，參與者取消已經變更的事務，釋放鎖定的資源。
兩階段提交方案應用很廣泛，幾乎所有的商業oltp資料庫都支援xa協議，但是兩階段提交方案鎖定資源時間長，對於效能影響很大，基本不適合於解決微服務事務問題。
兩階段提交協議弊端(缺點)：如果協調者宕機，參與者沒有協調者指揮，則會一直阻塞。
三階段提交協議：
增加了乙個詢問階段(在兩階段提交協議之前增加了一詢問階段)，詢問階段可以確保盡可能早的發現無法執行的操作而需要終止的行為，但是它並不能發現所有的這種行為，只會減少這種情況的發生；在準備階段以後，協調者和參與者執行的任務中都增加了超時，一旦超時，協調者和參與者都繼續提交事務，預設為成功，這也是根據概率統計上超時後預設成功的正確性最大。
超時，終止提交，進行回滾。
三階段提交協議與兩階段提交協議相比，具有如上的優點，但是一旦發生超時，系統仍然會發生不一致，只不過這種情況很少見罷了，好處就是至少不會阻塞和永遠鎖定資源。
一致性協議
節點在進行事務處理過程中保持原子性和一致性而設計的一種演算法。1.事務詢問。2.執行事務。3.各參與者向協調者反饋事務詢問的響應。理解 類似協調者組織各參與者對一次事務操作進行投票表態的過程。假如參與者全部反饋yes 1.傳送提交請求 2.事務提交 3.反饋事務提交結果 4.完成事務。假如任何乙個參...
一致性協議
在分布式系統中，每乙個機器節點雖然都能夠明確地知道自己在進行事務操作過程中的結果是成功或失敗，但卻無也直接獲取到其他分布式節點的操作結果。因此，當乙個事務操作需要跨越多個分布式節點的時候，為了保持事務處理的acid特性，就需要引人乙個稱為 協調者 的元件來統一排程所有分布式節點的執行邏輯，這些被排程...
一致性協議
在分布式系統中，當乙個事務操作需要跨越多個分布式節點的時候，為了保持事務acid的特徵，就需要引入乙個稱為 協調者 coordinator 的元件來統一排程所有分布式節點的執行邏輯，這些被排程的節點則稱為 參與者 participant 協調者負責參與者的行為，並最終決定這些參與者是否要把事務真正提...