分散式系統學習：二階段提交
CAP理論
在學習分散式的相關知識點前，一定要先掌握CAP定理：
-
C(onsistency) 一致性：分散式環境中，CAP關注的粒度是資料，而不是系統，而資料往往存在於多個副本之中，一致性是指多個副本之間，在同一時刻能否有同樣的值（內容和組織上的資料）
-
A(vailability) 可用性：系統提供的服務必須一直處於可用的狀態。即使叢集中一部分節點故障。換句話說就是使用者在容忍的時間範圍內返回使用者期望的結果
-
P(artition-resiliene) 分割槽容錯性：系統在遇到節點故障，或者網路分割槽時（斷網），依然能對外提供一致性和可用性的服務，在分散式系統架構中，通常由多個節點組成，由於節點通訊往往依賴網路，網路在現實中不是100%可靠的，所以分割槽容錯是分散式的一個
“最基本要求”，所以一般我們常見的CAP架構只有 AP和CP。
CAP 不能同時滿足
一致性、可用性以及分割槽容錯性在度量上也應該有一個評定範圍，最簡單的以可用性來說，當有多少佔比滿足出現響應超時可以被認定為是不可滿足可用性，而不是一出現超時就認為不可用。
CAP並沒有考慮資料同步的耗時，所以在現實中的分散式系統理論上無法保證任何時刻的絕對 “一致性”；不同業務吸引對上述耗時的敏感度是不同的
雖然CAP理論定義的是三個要素只能取兩個，但放到實際的分散式環境中來考慮，我們會發現必須選擇P（分割槽容忍）要素，因為既然網路是不可靠的，所以分割槽是一個必然出現的現象。
假如我們選擇CA的架構：當網路故障時，為了滿足一致性C，分散式系統協議規定必須禁止寫入，當有寫入時，會出現error,但因為可用性A的要求，分散式可用只能出現 no error 或 timeout error, 因此從現實中不可能現在CA架構的。
兩階段提交協議2PC
二階段提交( Two-phaseCommit )是指，在計算機網路以及資料庫領域內，為了使基於分散式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種演算法( Algorithm )。 通常，二階段提交也被稱為是一種協議( Protocol )。在分散式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。 當一個事務跨越多個節點時，為了保持事務的 ACID 特性，需要引入一個作為協調者的元件來統一掌控所有節點(稱作參與者)的操作結果並最終指示這些節點是否要把操作結果進行真正的提交(比如將更新後的資料寫入磁碟等等)。因此，二階段提交的演算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。
概況來說，兩階段提交是需要參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情況決定參與者是否需要提交操作還是中止操作。
兩階段提交（2PC）基於CP系統的思路，是分散式情況下強一致性（當修改操作成功後，當讀取改資料副本的時候，一定能讀到最新修改的資料）的演算法；它是用來保證分散式系統事務的協議。
兩階段是哪兩個階段？
一、Prepare(投票、準備)階段
該階段的主要目的在於檢測分散式叢集中的各個參與者節點是否能夠正常的執行事務，具體步驟如下：
1.協調者向所有的參與者傳送事務執行請求，並等待參與者反饋事務執行結果 2.事務參與者收到請求之後，執行事務但不提交，並記錄事務日誌；為了保證接下來能提交，每個參與者必須將事務中所發生改變的物件已經自己的狀態儲存到持久化儲存中 3.參與者將自己事務執行情況反饋給協調者，同時阻塞等待協調者的後續指令
二、Accept(提交、執行)階段
一個參與者在它事務提交前，必須保證能執行提交協議中它自己的那一部分，即使參與者出現故障而不會中途換掉
在經過第一階段協調者的檢測階段之後，各個參與者會回覆自己事務的執行情況，這時候存在三種可能性：
1.所有的參與者都回復能夠正常執行事務 2.一個或多個參與者回覆事務執行失敗 3.協調者等待超時
對於第二、三種情況，協調者均認為參與者無法成功執行事務，即事務失敗，為了整個叢集資料的一致性，所以要向各個參與者傳送事務回滾通知
1.協調者向各個參與者傳送事務 rollback 通知，請求回滾事務 2.參與者收到事務回滾通知之後，執行 rollback 操作，然後釋放佔有的資源 3.參與者向協調者返回事務 rollback 結果資訊
兩階段提交的工作流程如圖：
兩階段提交協議的問題
-
協議是事務阻塞型的：2PC提交執行過程中，所有的參與者都需要聽從協調者的統一排程，期間處於阻塞狀態而不能從事其它操作
-
資料不一致性、網路容錯能力差：這個時候，我們需要引入超時機制或互相輪休的機制降低問題的嚴重性
-
協調者單點故障：協調者在執行提交階段宕機，所有的參與者處於鎖定事務資源的狀態，無法完成事務操作。
正是這些問題，兩階段無法解決以下問題：
協調者發出commit訊息後宕機，而唯一接收這訊息的參與者同時也宕機，那麼協調者即系通過選舉或其它恢復方案產生新的可以協調者，這事務的狀態也是不確定的。