2pc：two phase commit二階段提交協議
2pc是在計算機網路以及資料庫領域內，為了使基於分布式系統架構下的所有節點在進行事務的提交時，保持一致性而設計的一種演算法。通常，二階段提交也被稱為是一種協議。
在分布式系統中，每個節點雖然可以知曉自己的操作是否成功，但無法知道其他節點的操作是否成功。當乙個事務跨越多個節點時，為了保持事務的acid特性，需要引入乙個作為協調者的元件來統一掌控所有的節點的操作結果，並最終指示這些節點是否要把操作結果真正的提交。（每個節點也稱為參與者）
其演算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋結果決定所有的參與者是否要提交操作還是終止操作。所有的節點都投票決定是否執行事務操作。
二階段提交協議：把事務的提交過程分為兩個階段來進行處理。
1. 事務詢問。（協調者-->參與者）
事務協調者（事務管理器）向每個事務參與者（資源管理器）詢問，是否準備好了執行事務，並開始等待各個參與者的響應。
2. 執行事務。（參與者）
各個參與者節點執行事務操作，並將undo和redo資訊記入到事務日誌中。【注意：若成功這裡其實每個參與者已經執行了事務操作】
3. 各參與者向協調者反饋事務查詢的統計。（參與者-->協調者）
各個參與者響應協調者發起的詢問。若參與者節點的事務操作實際執行成功，則返回乙個「同意」訊息；如果參與者節點的事務操作實際執行失敗，則返回乙個「終止」訊息。
根據投票結果執行兩種操作：執行事務提交或者中斷事務。
執行事務提交：協調者節點從所有的參與者節點獲得的訊息都為「同意」。
協調者節點向所有的參與者節點發出「正式commit」請求。
參與者節點正式完成操作，釋放在整個事務期間內占用的資源。
參與者節點向協調者節點傳送「完成」訊息。
協調者節點收到所有參與者節點的「完成」訊息後，完成事務。
中斷事務：任一參與者節點在一階段的響應訊息為「終止」，或者一階段詢問超時無法獲取所有參與者節點的響應訊息。
協調者節點向所有的參與者節點發出「回滾操作」請求。
參與者節點利用之前寫入的undo資訊執行回滾操作，並完成操作之後釋放在整個事務期間內占用的資源。
參與者向協調者節點傳送「回滾完成」訊息。
協調者節點收到所有參與者節點反饋的「回滾完成」訊息後，取消事務。
缺點：
同步阻塞、單點問題、資料不一致、過於保守。
同步阻塞：
執行過程中，所有參與節點都是事務阻塞型的。當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。
單點問題：
由於協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那麼所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉乙個協調者，但是無法解決因為協調者宕機導致的參與者處於阻塞狀態的問題）
資料不一致：
在二階段提交階段中，當協調者向參與者傳送commit請求之後，發生了區域性的網路異常或者在傳送commit請求的過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分布式系統便出現了資料部一致性的現象。
過於保守：
二階段提交協議沒有設計較為完善的容錯機制，任意乙個節點的失敗都會導致整個事務的失敗。
參考：
分布式系統一致性演算法：
分布式理論（三）—— 一致性協議之 2pc：
2pc&&3pc：
分布式理論 三 2PC協議
由於base理論需要在一致性和可用性方面做出權衡，因此湧現了很多關於一致性的演算法和協議。其中比較著名的有二階提交協議 2 phase commitment protocol 三階提交協議 3 phase commitment protocol 和paxos演算法。本文要介紹的2pc協議，分為兩個階...
分布式事務2PC協議
two phase commit protocol 在事務處理，資料庫，計算機網路中，兩階段提交 2pc 是一種原子提交協議。它是一種分布式演算法，協調參與分布式原子事務的所有程序，決定是提交事務還是中止 回滾 事務 它是一種協商一致性協議 該協議即使在許多臨時系統故障 包括程序 網路節點 通訊等故...
分布式理論（三） 一致性協議之 2PC
為了使系統盡量能夠達到 cap，於是有了 base 協議，而 base 協議是在可用性和一致性之間做的取捨和妥協。人們往往需要在系統的可用性和資料一致性之間反覆的權衡。於是呢，就產生我們標題中的一致性協議，而且還不止乙個呢。為了解決分布式問題，湧現了很多經典的演算法和協議，最著名的就是二階段提交協議...