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集群同樣出去不可用狀態