eureka與zookeeper的原理是什么

這篇文章主要介紹“eureka與zookeeper的原理是什么”，在日常操作中，相信很多人在eureka與zookeeper的原理是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”eureka與zookeeper的原理是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

 CAP 理論

什么叫 CAP 理論呢？CAP 理論是由 Eric Brewer 教授提出，是分布式系統中的一個重要的概念。具體如下：

C（Consistency）：數據一致性。大家都知道，分布式系統中，數據會有副本。由于網絡或者機器故障等因素，可能有些副本數據寫入正確，有些卻寫入錯誤或者失敗，這樣就導致了數據的不一致了。而滿足數據一致性規則，就是保證所有數據都要同步。

A（Availability）：可用性。我們需要獲取什么數據時，都能夠正常的獲取到想要的數據（當然，允許可接受范圍內的網絡延遲），也就是說，要保證任何時候請求數據都能夠正常響應。

P（Partition Tolerance）：分區容錯性。當網絡通信發生故障時，集群仍然可用，不會因為某個節點掛了或者存在問題，而影響整個系統的正常運作。

對于分布式系統來說，出現網絡分區是不可避免的，因此分區容錯性是必須要具備的，也就是說，CAP三者，P是必須的，是個客觀存在的事實，不可避免，也無法繞過。

1. Zookeeper 的 CP 原則

對于 zookeeper 來說，它是 CP 的。也就是說，zookeeper 是保證數據的一致性的，但是這里還需要注意一點是，zookeeper 它不是強一致的，什么意思呢？

打個比方，現在客戶端 A 提交一個寫操作，zookeeper 在過半數節點操作成功之后就可以返回，但此時，客戶端 B 的讀操作請求的是 A 寫曹操尚未同步到的節點，那么讀取的就不是 A 最新提交的數據了。

那如何保證強一致性呢？我們可以在讀取數據的時候先執行一下 sync 操作，即與 leader 節點先同步一下數據，再去取，這樣才能保證數據的強一致性。

但是 zookeeper 也有個缺陷，剛剛提到了 leader 節點，當 master 節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行 leader 選舉。問題在于，選舉 leader 的時間太長，30 ~ 120s, 且選舉期間整個 zookeeper 集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。

在云部署的環境下，因網絡問題使得 zookeeper 集群失去 master 節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。比如雙十一當天，那就是災難性的。

2. Eureka 的 AP 原則

大規模網絡部署時，失敗是在所難免的，因此我們無法回避這個問題。當向注冊中心查詢服務列表時，我們可以容忍注冊中心返回的是幾分鐘以前的注冊信息，但不能接受服務直接 down 掉不可用。

Eureka 在被設計的時候，就考慮到了這一點，因此在設計時優先保證可用性，這就是 AP 原則。Eureka 各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩余的節點依然可以提供注冊和查詢服務。

而 Eureka 的客戶端在向某個 Eureka 注冊或時如果發現連接失敗，則會自動切換至其它節點，只要有一臺 Eureka 還在，就能保證注冊服務可用（即保證A原則），只不過查到的信息可能不是最新的（不保證C原則）。

正因為應用實例的注冊信息在集群的所有節點間并不是強一致的，所以需要客戶端能夠支持負載均衡以及失敗重試。在 Netflix 的生態中，ribbon 可以提供這個功能。

因此， Eureka 可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像 zookeeper 那樣使整個注冊服務癱瘓。

3. 結果

作為服務注冊中心，最重要的是要保證可用性，可以接收段時間內數據不一致的情況。個人覺得 Eureka 作為單純的服務注冊中心來說要比 zookeeper 更加適合一點。

到此，關于“eureka與zookeeper的原理是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！