在分散式系統中，每一個機器節點雖然都能夠明確地知道自己在進行事務操作過程中的結果是成功或失敗，但卻無法直接獲取到其他分散式節點的操作結果。因此，當一個事務操作需要跨越多個分散式節點的時候，為了保持事務處理的ACID特性，就需要引人一個稱為“協調者(Coordinator)”的元件來統一排程所有分散式節點的執行邏輯，這些被排程的分散式節點則被稱為“參與者”( Participant)。協調者負責排程參與者的行為，並最終決定這些參與者是否要把事務真正進行提交。基於這個思想，衍生出了二階段提交和三階段提交兩種協議。

什麼是2pc

2PC，是Two-Phase Commit的縮寫，即二階段提交，是計算機網路尤其是在資料庫領域內，為了使基於分散式系統架構下的所有節點在進行事務處理過程中能夠保持原子性和一致性而設計的一種演算法。通常，二階段提交協議也被認為是一種一致性協議，用來保證分散式系統資料的一致性。目前，絕大部分的關係型資料庫都是採用二階段提交協議來完成分散式事務處理的，利用該協議能夠非常方便地完成所有分散式事務參與者的協調，統一決定事務的提交或回滾，從而能夠有效地保證分散式資料一致性，因此二階段提交協議被廣泛地應用在許多分散式系統中。ZK也是基於2pc處理資料提交的。

協議說明

顧名思義，二階段提交協議是將事務的提交過程分成了兩個階段來進行處理，其執行流程如下。

階段一:提交事務請求

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請求的參與者則無法進行事務提交，於是整個分散式系統便出現了資料不一致性現象。

太過保守

如果在協調者指示參與者進行事務提交詢問的過程中，參與者出現故障而導致協調者始終無法獲取到所有參與者的響應資訊的話，這時協調者只能依靠其自身的超時機制來判斷是否需要中斷事務，這樣的策略顯得比較保守。換句話說，二階段提交協議沒有設計較為完善的容錯機制，任意一個節點的失敗都會導致整個事務的失敗。