對比zookeeper
回顧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、AP、CP
CAP理論的核心
- 一個分布式系統不可能同時很好的滿足一致性，可用性和磁區容錯性這三個需求
根據CAP原理，將NoSQL資料庫分成了滿足CA原則，滿足CP原則和滿足AP原則三大類： - CA：單點集群，滿足一致性，可用性的系統，通常可擴展性較差
- CP：滿足一致性，磁區容錯性的系統，通常性能不是特別高
- AP：滿足可用性，磁區容錯性的系統，通常可能對一致性要求低一些
作為服務注冊中心，Eureka比Zookeeper好在哪里?
著名的CAP理論指出，一個分布式系統不可能同時滿足C（一致性）、A（可用性）、P（容錯性），
由于磁區容錯性P在分布式系統中是必須要保證的，因此我們只能在A和C之間進行權衡，
- Zookeeper保證的是CP；
- Eureka保證的是AP；
當向注冊中心查詢服務串列時，我們可以容忍注冊中心回傳的是幾分鐘以前的注冊資訊，但不能接受服 務直接down掉不可用，也就是說，服務注冊功能對可用性的要求要高于一致性，但是zk會出現這樣一種 情況，當master節點因為網路故障與其他節點失去聯系時，剩余節點會重新進行leader選舉，問題在 于，選舉leader的時間太長，30~120s，且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注 冊服務癱瘓，在云部署的環境下，因為網路問題使得zk集群失去master節點是較大概率會發生的事件， 雖然服務終能夠恢復，但是漫長的選舉時間導致的注冊長期不可用是不能容忍的，
Eureka保證的是AP Eureka看明白了這一點，因此在設計時就優先保證可用性，Eureka各個節點都是平等的，幾個節點掛 掉不會影響正常節點的作業，剩余的節點依然可以提供注冊和查詢服務，而Eureka的客戶端在向某個 Eureka注冊時，如果發現連接失敗，則會自動切換至其他節點，只要有一臺Eureka還在，就能保住注冊 服務的可用性，只不過查到的資訊可能不是新的，除此之外，Eureka還有一種自我保護機制，如果在 15分鐘內超過85%的節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現了網路故障，此 時會出現以下幾種情況：
- Eureka不再從注冊串列中移除因為長時間沒收到心跳而應該過期的服務
- Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其他節點上（即保證當前節點依 然可用）
- 當網路穩定時，當前實體新的注冊資訊會被同步到其他節點中
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/248415.html
標籤：其他