Zookeeper_CAP原則

CAP原則

簡單介紹CAP

• 想要進行分佈式事務控制，CAP理論是咱們必需要知道的；

CAP原則：也叫CAP定理，指的是在一個分佈式系統中，一致性、可用性、分區容錯性三者不可兼得

• 一致性（Consistency）

  分佈式系統中的全部主機在同一時刻是否能夠保證具備徹底相同的數據備份，若具備，則該分佈式系統具備一致性

• 可用性（Availability）

  在集羣中，部分節點發生故障後，是否會影響對客戶端讀寫請求的響應，注意，若在短期內會影響，其也不具備這裏說說的"可用性"

• 分區容錯性（Partition tolerance

  分佈式系統中的一臺主機稱爲一個分區，分佈式系統中各個主機沒法保證數據的一致性，即不具備一致性是一種錯誤；分佈式系統沒法及時響應客戶端請求，即不具備可用性也是一種錯誤；對於分佈式系統，必需要具備對這些錯誤的"包容性",即容錯性，這是必須得

• 爲何不能面面俱到

上面已經說明，分區容錯性是分佈式系統必須考慮的，此外，當咱們想要保證高可用的時候，無非就是增長不少的節點，高可用的確是知足了，但帶來的問題是，這麼多的節點之間的數據同步是一個不少的消耗，極其容易形成數據不一致，當咱們強調一致性的時候，節點越少，數據同步的消耗就小，但帶來的節點少卻又形成服務的可用性差，因此一致性和可用性是不可兼顧的，他們處於一個對立面；

• CAP的組合

CA ：不是分佈式架構，就使用這種，關係數據庫按照CA進行設計 ，放棄分區容錯性，由於沒有分區呀！！

AP：增強可用性和分區容錯性,放棄當即一致性（強一致性），追求最終一致性，好比Eureka

• 好比微信提現，提示兩個小時到帳，而不是立刻到帳

CP：強調強一致性和分區容錯性，放棄可用性，好比Zookeeper,master在宕機後選舉Leader期間不提供服務

• 好比跨行轉帳，就是當即到帳，你這邊轉出，那邊收進，方認爲一個事務纔算完成

簡單說說：先說結論，在分佈式系統中AP運用的最多，由於他放棄的是強一致性，追求的是最終一致性，性價比最高，好比12小時內退款，微信2小時內提現到帳，只要在用戶的可接受範圍內，保證一致性便可

三二原則

對於分佈式系統，在CAP原則中分區容錯性P是必須保證的，但其並不能同時保證一致性和可用性，由於如今的分分佈式系統在知足一致性的前提下，會犧牲可用性，在知足了可用性的前提下，會犧牲一致性，因此CAP原則對於一個分佈式系統來講，只可能知足兩項，要麼CP，要麼AP，這就是CAP的三二原則

ZK與CP的緣分

ZK遵循的是CP原則，即一致性和分區容錯性，犧牲了可用性，具體犧牲在哪裏呢？

當Leader宕機之後，集羣機器立刻會進去到新的Leader選舉中，可是選舉時長在30s — 120s之間，這個選取Leader期間，是不提供服務的，不知足可用性，因此犧牲了可用性

通過上面的簡單講解，會射門選舉時長會長達半分鐘到2分鐘呢？

固然是爲了保證一致性，爲了保證集羣中各個節點數據的一致性，ZK作了兩類數據同步，初始化同步和更新同步。

• 1：當新的Leader選舉出來後，各個Follower須要將新的Leader的數據同步到本身的緩存中，這就是初始化同步

• 2：當Leader數據被客戶端修改後，其會向Follower發出廣播，而後各個Follwer會竹筒去同步更新的數據，這是更新同步

不管是初始化同步仍是更新同步，ZK集羣爲了保證數據的一致性，若發現超過半數的Follower同步超時，則其會再次進行同步，而這個過程當中ZK集羣一樣出去不可用狀態

因爲ZK採用的是CP原則，因此其可用性下降，這是其致命的問題，Spring Cloud集成的Eureka採用的就是AP原則，犧牲了一致性，可是保證了可用性