一.CPA原則
CAP原則又稱CAP定理，指的是在一個分佈式系統中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。
一致性（C）：在分佈式系統的所有數據備份，在同一時刻是否同樣的值（等同於所有節點訪問同一份最新的數據副本））
可用性（A）：在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求。（對數據跟新具備高可用）
分區容忍性（P）：以實際效果而言，分區相當於對通信的時限要求，系統如果不能在時限內達成數據的一致性，就以爲發生了分區的情況，必須在A和C之間做出選擇
CAP原則的精髓之處就是要麼AP,要麼AC，要麼CP，但是不存在CAP。如果在某個分佈式系統中數據無副本，那麼系統必然滿足一致性條件，以爲只有獨一數據，不會出現數據不一致的情況，此時C和P兩者兼備，但是如果系統發生網絡分區狀況或者宕機，必然導致某些數據不可以訪問，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統，但是CAP不可同時滿足 。因此在進行分佈式架構設計時，必須做出取捨。當前一般是通過分佈式緩存中各節點的最終一致性來提高系統的性能，通過使用多節點之間的數據異步複製技術來實現集羣化的數據一致性。
二.eureka和zookeeper的對比
Eureka（基於AP來設計的）
a.Eureka 是 Netflix 在線影片公司開源的一個服務註冊與發現的組件，和其他Netflix 公司的服務組件（例如負載均衡、熔斷器、網關等） 一起，被Spring Cloud 社區整合爲Spring Cloud Netflix 模塊，提供相應的JAVA封裝類。
b.在Eureka的實現中優先保證可用性，節點之間相互平等，部分註冊節點的掛掉不會對集羣產生影響（不存在leader.不用選舉），即使只剩下一個節點，也可以正常的提供發現服務。就算是所有的服務註冊節點都掛掉了，Eureka Client（客戶端）也會緩存服務調用信息，等宕機的活過來,就會把最新的一份信息同步給它.。保證了註冊服務可用(保證可用性)。
c.Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現以下幾種情況：
1.ureka Server採用的是Peer to Peer對等通信。這是一種去中心化的架構，無master/slave區分，每一個Peer都是對等的。
2.Eureka仍能接收新服務的註冊和查詢請求，但是不會被同步到其他的節點上
3.網路穩定時，當前實例新的註冊信息會被同步到其他節點上
在默認配置中，Eureka Server在默認90s內沒有接收到客戶的心跳，則註銷該實例，但是因爲微服務跨進程調用，網絡通信往往存在各種問題，比如微服務狀態正常，但是因爲網絡分區故障時，Eureka Server註銷服務實例則會讓大部分微服務不可用，這很危險，因爲服務明明沒有問題。
所以在配置Eureka時配置如下參數，可啓動保護機制：
eureka.server.enable-self-preservation=true（當Eureka Server節點在短時間內丟失過多客戶端時，那麼這個節點將進入自我保護模式，不在註銷任何微服務。網絡穩定後自動退出自我保護模式）
zookeeper（Zookeeper是基於CP來設計的）
在zookeeper裏面，若主機掛掉了，則zk集羣整體不對外提供服務了，需要選一個新leader的出來（120s作用）才能繼續對外提供服務！不保證高可用。
Eureka基於AP， 不是很注重數據的一致性！注重服務的可用性，即使所有機器都掛了，也能拿到本地緩存的數據。
Zookeeper基於CP， 注重數據的一致性。