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