CAP原則以及Eureka與Zookeeper比較
ACID原則和CAP原則
RDBMS(Mysql，Oracle，sqlServer)=>ACID原則
NoSql(Redis,mongdb)=>CAP原則
ACID原則
- A(Atomicity) 原子性
- C(Consistency) 一致性
- I(Isolation) 隔離性
- D(Durability) 永續性
CAP原則
- C(Consistency) 一致性
- A(Availability) 可用性
- P(Partition tolerance) 分割槽容錯性
CAP原則三進二：CA,CP,AP
CAP理論核心：
- 一個分散式系統不可能同時很好的滿足一致性，可用性，分割槽容錯性這三個需求
- 根據CAP原理，將NoSQL資料庫分成了滿足CA原則，CP原則，AP原則三大類
CA:單點叢集，滿足一致性，可用性的系統，通常可擴充套件性較差
CP:滿足一致性，分割槽容錯性的系統，通常效能不是特別高
AP:滿足可用性，分割槽容錯性的系統，通常可能對一致性要求低一些
Eureka與Zookeeper比較
由於分割槽容錯性P在分散式系統中時必須要保證的，因此我們只能在A和C之間進行權衡
-
Zookeeper保證的是CP
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接收伺服器宕機不可用，也就是說，服務註冊功能對可用性的要求要高於一致性。但是Zookeeper會出現這樣一種情況，當master節點即主節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行主節點選舉。由於選舉主節點的事件會很長（30s~120s），且選舉期間整個Zookeeper叢集都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因為網路問題使得Zookeeper叢集失去master節點是比較大概率會發生的事件，雖然服務最終能夠恢復，但是漫長的選舉時間導致註冊服務功能長期不可用是不能容忍的。 -
Eureka保證的是AP
Eureka避免了這一點，在設計之初就優先保證可用性，Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供服務註冊和查詢服務，而Eureka客戶端在向某個Eureka註冊時，如果發現連線失敗，則會自動切換至其他節點，只要有一臺Eureka存在，就能保證註冊的可用性，只不過查到的資訊可能不是最新的。
除此之外，Eureka還有一種自我保護機制 https://www.cnblogs.com/Liuyunsan/p/15656846.html ，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況
- Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務
- Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會同步到其他節點上（優先保證當前節點可用）
- 當網路穩定時，當前例項新的註冊資訊會被同步到其他節點中
因此，Eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況，而不會像Zookeeper那樣使整個註冊服務癱瘓