京東面試官讓你談談zookeeper和eureka哪個更好使？-創(chuàng)新互聯(lián)

成都創(chuàng)新互聯(lián)從2013年創(chuàng)立，先為清豐等服務建站，清豐等地企業(yè)，進行企業(yè)商務咨詢服務。為清豐企業(yè)網站制作PC+手機+微官網三網同步一站式服務解決您的所有建站問題。

閱讀文本大概需要 5 分鐘。

大家都說今年是互聯(lián)網寒冬，但是前段時間有個讀者很高興的跟我聊天說他去京東了。我問他都問了什么問題？他說問了很多微服務相關的，其中有一個問題就是：同樣是注冊中心，你覺得 zookeeper 和 eureka 哪個更好？

剛好最近也在看微服務相關的東西，索性就針對這個問題，簡單總結一下 zookeeper 和 eureka 之間的區(qū)別，希望讀者能夠從中得到有用的東西。

0. CAP 理論

在總結兩者的區(qū)別之前，我們先來看一個 CAP 理論。什么叫 CAP 理論呢？CAP 理論是由 Eric Brewer 教授提出，是分布式系統(tǒng)中的一個重要的概念。CAP 具體如下：

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

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

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

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

1. Zookeeper 的 CP 原則

對于 zookeeper 來說，它是 CP 的。也就是說，zookeeper 是保證數(shù)據的一致性的，但是這里還需要注意一點是，zookeeper 它不是強一致的，什么意思呢？打個比方，現(xiàn)在客戶端 A 提交一個寫操作，zookeeper 在過半數(shù)節(jié)點操作成功之后就可以返回，但此時，客戶端 B 的讀操作請求的是 A 寫操作尚未同步到的節(jié)點，那么讀取的就不是 A 最新提交的數(shù)據了。

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

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

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

2. Eureka 的 AP 原則

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

Eureka 在被設計的時候，就考慮到了這一點，因此在設計時優(yōu)先保證可用性，這就是 AP 原則。Eureka 各個節(jié)點都是平等的，幾個節(jié)點掛掉不會影響正常節(jié)點的工作，剩余的節(jié)點依然可以提供注冊和查詢服務。而 Eureka 的客戶端在向某個 Eureka 注冊或時如果發(fā)現(xiàn)連接失敗，則會自動切換至其它節(jié)點，只要有一臺 Eureka 還在，就能保證注冊服務可用（即保證A原則），只不過查到的信息可能不是最新的（不保證C原則）。

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

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

3. 元芳，你怎么看？

作為服務注冊中心，最重要的是要保證可用性，可以接受短時間內數(shù)據不一致的情況。個人覺得 Eureka 作為單純的服務注冊中心來說要比 zookeeper 更加“專業(yè)”一點。

不過 eureka2.x 分支不再維護，但是 eureka1.x 官方還在維護，目前最新 RELEASE 版本是 1.9.9，所以并不是像網上說的 eureka 涼了啥的。

Eureka 是隨著 Spring Cloud 被人們熟知，但是 Spring Cloud 支持使用 eureka、zookeeper、consul 實現(xiàn)服務發(fā)現(xiàn)的能力。從 eureka 切換成 zookeeper 只需要改個依賴，改幾行配置就可以了。更多的是要多了解它們的原理和區(qū)別。

元芳，你怎么看？

網站欄目：京東面試官讓你談談zookeeper和eureka哪個更好使？-創(chuàng)新互聯(lián)
本文鏈接：http://www.muchs.cn/article34/hgdse.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、網站設計公司、做網站、網站排名、全網營銷推廣、電子商務

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)