分散式理論:2pc與3pc
阿新 • • 發佈：2019-02-05
分散式系統中，人們為了保障多個節點在進行全域性事務操作的一致性，提出了很多分散式演算法，其中比較著名的有二階提交協議（Two Phase Commitment Protocol）、三階提交協議（Three Phase Commitment Protocol）和Paxos演算法，本文主要講述2pc和3pc演算法，paxos演算法會留到下一篇部落格中。
2pc演算法：
二階段提交演算法顧名思義，主要由兩個階段組成，分別是事務的投票階段和提交執行階段。
階段一：投票請求階段
1、事務詢問 協調者向所有參與者傳送事務內容,詢問是否可以提交事務內容，並等待各參與者的響應。- 所有參與者反饋YES，協調者向參與者節點發出commit請求。
- 參與者收到請求後正式執行提交操作並在完成提交之後釋放在整個事務執行期間佔用的事務資源。
- 參與者執行後反饋Ack訊息。
- 協調者接收到Ack訊息後完成事務
總結：2pc是強一致性演算法，優點是實現簡單，缺點也很明顯，其中最大的問題是同步阻塞，在第二階段開始，協調者等待參與者返回的過程中，一旦某個參與者不能及時返回，整個系統會阻塞，同時還有一個問題就是如果協調者在發出commit請求後某個參與者crash或者網路斷開，那麼就會出現資料不一致的情況。接下來介紹3pc演算法：
3PC演算法：
3pc是2pc的改進版本，主要是給協調者和參與者都引入了超時機制，同時在第一階段和第二階段過程中加
入了一個準備階段，保障了資料的一致性。
階段一：canCommit 協調者向參與者傳送canCommit訊息和事務資訊,參與者收到後，會判別自己是否可以執行該事務,如果可以執行就返回 yes,不可以則返回no.如果協調者收到任何一個no或者參與者超時，事務終止,同時會通知參與者事務終止，只有在超時 時間內收到所有yes，才能進入下一階段。（相對於參與者來說，在反饋完第一階段的canCommit後，如果等待協調者傳送preCommit也超時的話也會終止事務） 階段二：preCommit 本階段協調者會發送preCommit訊息給所有參與者，所有參與者收到後會開始執行事務，並記錄undo和redo日誌，返回ACK訊息。 階段三：doCommit 協調者只有在接收到所有ACK訊息後會傳送doCommit，否則會給參與者發出終止訊息，事務回滾。（相對於參 與者來說，只要接受到一個preCommit訊息並返回了ACK，如果此時協調者崩潰或者超時，各個參與者則會繼續完成這 次commit。所以在第三階段，如果是協調者出錯參與者沒錯的情況下，參與者會繼續完成本次提交;如果是協調者沒錯，參與者出錯，則本次事務終止。） 總結：3pc對比2pc來說增強了資料一致性， 同時引入了雙方超時機制，減小了阻塞。但是缺點依舊存在，主要是無法避免網路分割槽（網路分割槽：在網路不好的情況下，高延遲被區分成失敗）問題，因為3pc採用了失敗-停止的模式,所以一旦網路延遲高就會失敗。 參考： https://en.wikipedia.org/wiki/Three-phase_commit_protocol http://www.mamicode.com/info-detail-890945.html 《從Paxos到Zookeeper分散式一致性原理與實踐》