京東面試官讓你談談 zookeeper 和 eureka 哪個更好使?
閱讀文字大概需要 5 分鐘。
大家都說今年是網際網路寒冬,但是前段時間有個讀者很高興的跟我聊天說他去京東了。我問他都問了什麼問題?他說問了很多微服務相關的,其中有一個問題就是:同樣是註冊中心,你覺得 zookeeper 和 eureka 哪個更好?
剛好最近也在看微服務相關的東西,索性就針對這個問題,簡單總結一下 zookeeper 和 eureka 之間的區別,希望讀者能夠從中得到有用的東西。
0. CAP 理論
在總結兩者的區別之前,我們先來看一個 CAP 理論。什麼叫 CAP 理論呢?CAP 理論是由 Eric Brewer 教授提出,是分散式系統中的一個重要的概念。CAP 具體如下:
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 更加“專業”一點。
不過 eureka2.x 分支不再維護,但是 eureka1.x 官方還在維護,目前最新 RELEASE 版本是 1.9.9,所以並不是像網上說的 eureka 涼了啥的。
Eureka 是隨著 Spring Cloud 被人們熟知,但是 Spring Cloud 支援使用 eureka、zookeeper、consul 實現服務發現的能力。從 eureka 切換成 zookeeper 只需要改個依賴,改幾行配置就可以了。更多的是要多瞭解它們的原理和區別。
元芳,你怎麼看?
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31558358/viewspace-2564424/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 面試官:談談你對mysql索引的認識?面試MySql索引
- 【搞定面試官】談談你對JDK中Executor的理解?面試JDK
- 面試官:談談你對JVM垃圾收集器的瞭解面試JVM
- 面試官:來談談限流-RateLimiter原始碼分析面試MIT原始碼
- 京東被約談整改的原因 京東被約談整改怎麼回事?
- 面試官:談談你對JVM垃圾收集器演算法的瞭解面試JVM演算法
- 從一個面試官的角度談軟體工程師的面試面試軟體工程工程師
- 面試官說:來談談限流-從概念到實現,一問你就懵逼了?面試
- 面試——談談你對Java 平臺的理解面試Java
- 【搞定Jvm面試】 面試官:談談 JVM 類載入過程是怎樣的?JVM面試
- 面試官:談談你對SpringAOP的瞭解?請加上這些內容,絕對加分!面試Spring
- 面試官:談談Redis快取和MySQL資料一致性問題面試Redis快取MySql
- 【Java 容器面試題】談談你對HashMap 的理解Java面試題HashMap
- scrapy分散式淺談+京東示例分散式
- 阿里測試面試官:你來我這個公司面試,你先把理想放一放,我們直接先談工資!阿里面試
- 【手把手帶你配 webpack】第二步, 面試官-談談你對模組化的理解Web面試
- 面試——談談你對Java 物件導向思想的理解面試Java物件
- 面試官:來談談Vue3的provide和inject實現多級傳遞的原理面試VueIDE
- 月薪不同的三人去面試,面試官問道:各自談談對 binder 的理解?面試
- 面試題:你有沒有搞混查詢快取和Buffer Pool?談談看!面試題快取
- ZooKeeper淺談
- 面試官:談一下你對DDD的理解?我:馬什麼梅?面試
- 讓你更好使用 Typescript 的11個技巧TypeScript
- 面試官:談談你對Mysql資料庫讀寫分離的瞭解,並且有哪些注意事項?面試MySql資料庫
- 面試時這些“談薪技巧”,讓你的薪資提高3成面試
- 淺談LocalCache | 京東雲技術團隊
- JAVA面試題 請談談你對Sychronized關鍵字的理解?Java面試題Zed
- Java高頻面試題:談談你對MySQL索引的瞭解Java面試題MySql索引
- 【面試普通人VS高手系列】談談你對Seata的理解面試
- 面試官:如果讓你寫個分散式配置中心,就問你慌不慌面試分散式
- 談談OKHttp的幾道面試題HTTP面試題
- 談談面試知識點準備面試
- 作為面試官的一點點感悟,談談技術人的成長之路面試
- 面試官:Zookeeper叢集怎麼搭建?面試
- 【大廠面試06期】談一談你對Redis持久化的理解?面試Redis持久化
- 面試精選01-談談你對Abp中模組的理解面試
- 談談這幾個常見的多執行緒面試題執行緒面試題
- 談談前端效能最佳化-面試版前端面試