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原則，犧牲了一致性，但是保證了可用性