分佈式事務，兩階段提交協議，三階段提交協議

一 分佈式中的CAP怎麼理解

1 CAP

C（Consistency）一致性   每一次讀取都會讓你獲得最新的寫入結果

A （Availability）可用性    每一個節點(若是沒有失敗)，總能執行查詢(讀取和寫入)操做

P （Partition Tolerance）分區容忍性   即便節點之間的鏈接關閉，其餘兩個屬性也會獲得保證

CAP理論認爲，任何聯網的共享數據系統智能實現三個屬性中的兩個，可是能夠經過明確處理分區，優化一致性和可用性，從而實現三者之間的某種權衡

2 zookeeper提供的一致性服務

不少文章和博客裏提到，zookeeper是一種提供強一致性的服務，在分區容錯性和可用性上作了必定折中，這和CAP理論是吻合的。但實際上zookeeper提供的只是單調一致性。

緣由：
　　1. 假設有2n+1個server，在同步流程中，leader向follower同步數據，當同步完成的follower數量大於 n+1時同步流程結束，系統可接受client的鏈接請求。若是client鏈接的並不是同步完成的follower，那麼獲得的並不是最新數據，但能夠保證單調性。
　　2. follower接收寫請求後，轉發給leader處理；leader完成兩階段提交的機制。向全部server發起提案，當提案得到超過半數（n+1）的server認同後，將對整個集羣進行同步，超過半數（n+1）的server同步完成後，該寫請求完成。若是client鏈接的並不是同步完成follower，那麼獲得的並不是最新數據，但能夠保證單調性。

用分佈式系統的CAP原則來分析Zookeeper：
（1）C: Zookeeper保證了最終一致性,在十幾秒能夠Sync到各個節點.
（2）A: Zookeeper保證了可用性,數據老是可用的,沒有鎖.而且有一大半的節點所擁有的數據是最新的,實時的. 若是想保證取得是數據必定是最新的,須要手工調用Sync()
（2）P: 有2點須要分析的.
    ① 節點多了會致使寫數據延時很是大,由於須要多個節點同步.
    ② 節點多了Leader選舉很是耗時, 就會放大網絡的問題. 能夠經過引入 observer節點緩解這個問題.

 

 

二 分佈式一致性

1 引言

在分佈式系統中，爲了保證數據的高可用,一般咱們會將數據保留多個副本(replica), 這些副本會放置在不一樣的物理機器上。爲了對用戶提供正確的curd等語意，咱們須要保證這些放置在不一樣無力機器上的副本是一致的

爲了解決這種分佈式一致性問題，提出了不少典型的協議和算法，比較著名的是二階段提交協議，三階段提交協議和paxos算法。

 

2 分佈式事務

在分佈式系統中，各個節點之間在物理上相互獨立，經過網絡進行溝通和協調。因爲存在事務機制，能夠保證每一個獨立節點上的數據操做能夠知足ACID。可是，相互獨立的節點之間沒法準確地知道其餘節點的事務執行狀況。因此從理論上來說，兩臺機器沒法達到一致的狀態。若是想讓分佈式部署的多臺機器中的數據保持一致性，那麼就要保證在全部節點數據的寫操做，要麼所有都執行，要麼所有都不執行。可是，一臺機器在執行本地事務的時候沒法知道其餘機器中的本地事務的執行結果，因此它也就不知道本次事務到底應該commit仍是rollback。因此，常規的解決辦法就是引入一個"協調者"的組件來統一調度全部分佈式節點的執行。

 

三 2PC（Two-phaseCommit）

1 二階段提交

二階段提交的算法思路能夠歸納爲: 參與者將操做成敗通知協調者，再由協調者根據全部參與者的反饋情報決定各參與者是否要提交操做仍是停止操做。

二階段是指:  第一階段 - 請求階段(表決階段)     第二階段 - 提交階段(執行階段)

(1) 請求階段(表決)：

事務協調者通知每一個參與者準備提交或取消事務，而後進入表決過程，參與者要麼在本地執行事務，寫本地的redo和undo日誌，但不提交，到達一種"萬事俱備，只欠東風"的狀態。請求階段，參與者將告知協調者本身的決策: 贊成(事務參與者本地做業執行成功)或取消（本地做業執行故障）

(2) 提交階段(執行):

在該階段，寫調整將基於第一個階段的投票結果進行決策: 提交或取消

當且僅當全部的參與者贊成提交事務，協調者才通知全部的參與者提交事務，不然協調者將通知全部的參與者取消事務

參與者在接收到協調者發來的消息後將執行響應的操做

 

2 兩階段提交的缺點

1.同步阻塞問題。執行過程當中，全部參與節點都是事務阻塞型的。
當參與者佔有公共資源時，其餘第三方節點訪問公共資源不得不處於阻塞狀態。

2.單點故障。因爲協調者的重要性，一旦協調者發生故障。
參與者會一直阻塞下去。尤爲在第二階段，協調者發生故障，那麼全部的參與者還都處於鎖定事務資源的狀態中，而沒法繼續完成事務操做。（若是是協調者掛掉，能夠從新選舉一個協調者，可是沒法解決由於協調者宕機致使的參與者處於阻塞狀態的問題）

3.數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求以後，發生了局部網絡異常或者在發送commit請求過程當中協調者發生了故障，這回致使只有一部分參與者接受到了commit請求。
而在這部分參與者接到commit請求以後就會執行commit操做。可是其餘部分未接到commit請求的機器則沒法執行事務提交。因而整個分佈式系統便出現了數據不一致性的現象。

 

3 兩階段提交沒法解決的問題

當協調者出錯，同時參與者也出錯時，兩階段沒法保證事務執行的完整性。
考慮協調者在發出commit消息以後宕機，而惟一接收到這條消息的參與者同時也宕機了。
那麼即便協調者經過選舉協議產生了新的協調者，這條事務的狀態也是不肯定的，沒人知道事務是否被已經提交。

 

四 3PC（Three-phaseCommit）

1 三階段提交

三階段提交協議在協調者和參與者中都引入超時機制，而且把兩階段提交協議的第一個階段分紅了兩步: 詢問，而後再鎖資源，最後真正提交。

2 三階段的執行

(1) canCommit階段

3PC的canCommit階段其實和2PC的準備階段很像。協調者向參與者發送commit請求，參與者若是能夠提交就返回yes響應，不然返回no響應

(2) preCommit階段

協調者根據參與者canCommit階段的響應來決定是否能夠繼續事務的preCommit操做。根據響應狀況，有下面兩種可能:

a) 協調者從全部參與者獲得的反饋都是yes:

那麼進行事務的預執行，協調者向全部參與者發送preCommit請求，並進入prepared階段。參與澤和接收到preCommit請求後會執行事務操做，並將undo和redo信息記錄到事務日誌中。若是一個參與者成功地執行了事務操做，則返回ACK響應，同時開始等待最終指令

b)  協調者從全部參與者獲得的反饋有一個是No或是等待超時以後協調者都沒收到響應:

那麼就要中斷事務，協調者向全部的參與者發送abort請求。參與者在收到來自協調者的abort請求，或超時後仍未收到協調者請求，執行事務中斷。

(3) doCommit階段

協調者根據參與者preCommit階段的響應來決定是否能夠繼續事務的doCommit操做。根據響應狀況，有下面兩種可能:

a) 協調者從參與者獲得了ACK的反饋:

協調者接收到參與者發送的ACK響應，那麼它將從預提交狀態進入到提交狀態，並向全部參與者發送doCommit請求。參與者接收到doCommit請求後，執行正式的事務提交，並在完成事務提交以後釋放全部事務資源，並向協調者發送haveCommitted的ACK響應。那麼協調者收到這個ACK響應以後，完成任務。

b) 協調者從參與者沒有獲得ACK的反饋, 也多是接收者發送的不是ACK響應，也多是響應超時:

執行事務中斷。

 

五 2PC vs 3PC

1 2PC和3PC

對於協調者(Coordinator)和參與者(Cohort)都設置了超時機制（在2PC中，只有協調者擁有超時機制，即若是在必定時間內沒有收到cohort的消息則默認失敗）。
在2PC的準備階段和提交階段之間，插入預提交階段，使3PC擁有CanCommit、PreCommit、DoCommit三個階段。
PreCommit是一個緩衝，保證了在最後提交階段以前各參與節點的狀態是一致的。

維基百科：

三階段提交是「非阻塞」協議。
三階段提交在兩階段提交的第一階段與第二階段之間插入了一個準備階段，
使得原先在兩階段提交中，參與者在投票以後，因爲協調者發生崩潰或錯誤，
而致使參與者處於沒法知曉是否提交或者停止的「不肯定狀態」所產生的可能至關長的延時的問題得以解決。 舉例來講，假設有一個決策小組由一個主持人負責與多位組員以電話聯絡方式協調是否經過一個提案，以兩階段提交來講，主持人收到一個提案請求，打電話跟每一個組員詢問是否經過並統計回覆，而後將最後決定打電話通知各組員。
要是主持人在跟第一位組員通完電話後失憶，而第一位組員在得知結果並執行後老人癡呆，那麼即便從新選出主持人，也沒人知道最後的提案決定是什麼，也許是經過，也許是駁回，無論你們選擇哪種決定，都有可能與第一位組員已執行過的真實決定不一致，老闆就會不開心認爲決策小組溝通有問題而解僱。
三階段提交便是引入了另外一個步驟，主持人打電話跟組員通知請準備經過提案，以免沒人知道真實決定而形成決定不一致的失業危機。
爲何可以解決二階段提交的問題呢？
回到剛剛提到的情況，在主持人通知完第一位組員請準備經過後兩人意外失憶，即便沒人知道全體在第一階段的決定爲什麼，全體決策組員仍能夠從新協調過程或直接否決，不會有不一致決定而失業。
那麼當主持人通知徹底體組員請準備經過並獲得你們的再次肯定後進入第三階段，
當主持人通知第一位組員請經過提案後兩人意外失憶，這時候其餘組員再從新選出主持人後，
仍能夠知道目前至少是處於準備經過提案階段，表示第一階段你們都已經決定要經過了，此時即可以直接經過。

2 三階段提交協議的缺點

若是進入PreCommit後，Coordinator發出的是abort請求，假設只有一個Cohort收到並進行了abort操做，
而其餘對於系統狀態未知的Cohort會根據3PC選擇繼續Commit，此時系統狀態發生不一致性。

3 替代

目前還有一種重要的算法就是Paxos算法，Zookeeper採用的就是Paxos算法的改進。