本文屬於【夯實Spring Cloud】系列文章，該系列旨在用通俗易懂的語言，帶大家瞭解和學習Spring Cloud技術，希望能給讀者帶來一些乾貨。系列目錄如下：
【夯實Spring Cloud】Dubbo沉睡5年，Spring Cloud開始崛起！
【夯實Spring Cloud】Spring Cloud中基於maven的分佈式項目框架的搭建
【夯實Spring Cloud】Spring Cloud中的Eureka服務註冊與發現詳解
【夯實Spring Cloud】Spring Cloud中如何完善Eureka中的服務信息
【夯實Spring Cloud】Spring Cloud中使用Eureka集羣搭建高可用服務註冊中心
【夯實Spring Cloud】Spring Cloud中的Eureka和Zookeeper的區別在哪？
【夯實Spring Cloud】Spring Cloud中使用Ribbon實現負載均衡詳解（正在寫……）
【夯實Spring Cloud】Spring Cloud中使用Feign實現負載均衡詳解（正在寫……）
【夯實Srping Cloud】Spring Cloud中使用Hystrix實現斷路器原理詳解（正在寫……）
【夯實Spring Cloud】Spring Cloud中使用Zuul實現路由網關詳解（正在寫……）
【夯實Spring Cloud】Spring Cloud分佈式配置中心詳解（正在寫……）
【夯實Spring Cloud】未完待續
該系列上面幾篇文章主要對 Spring Cloud 中 Eureka 的服務註冊與發現做了詳細的介紹，針對於註冊中心，zookeeper 用的也比較多，所以這篇文章主要來總結一下 Eureka 和 zookeeper 之間的區別。
1. CAP 理論
在總結兩者的區別之前，我們先來看一個 CAP 理論。什麼叫 CAP 理論呢？CAP 理論是由 Eric Brewer 教授提出，是分佈式系統中的一個重要的概念。具體如下：
C（Consistency）：數據一致性。大家都知道，分佈式系統中，數據會有副本。由於網絡或者機器故障等因素，可能有些副本數據寫入正確，有些卻寫入錯誤或者失敗，這樣就導致了數據的不一致了。而滿足數據一致性規則，就是保證所有數據都要同步。
A（Availability）：可用性。我們需要獲取什麼數據時，都能夠正常的獲取到想要的數據（當然，允許可接受範圍內的網絡延遲），也就是說，要保證任何時候請求數據都能夠正常響應。
P（Partition Tolerance）：分區容錯性。當網絡通信發生故障時，集羣仍然可用，不會因爲某個節點掛了或者存在問題，而影響整個系統的正常運作。
對於分佈式系統來說，出現網絡分區是不可避免的，因此分區容錯性是必須要具備的，也就是說，CAP三者，P是必須的，是個客觀存在的事實，不可避免，也無法繞過。
2. zookeeper 的 CP 原則
對於 zookeeper 來書，它是 CP 的。也就是說，zookeeper 是保證數據的一致性的，但是這裏還需要注意一點是，zookeeper 它不是強一致的，什麼意思呢？打個比方，現在客戶端 A 提交一個寫操作，zookeeper 在過半數節點操作成功之後就可以返回，但此時，客戶端 B 的讀操作請求的是 A 寫曹操尚未同步到的節點，那麼讀取的就不是 A 最新提交的數據了。
那如何保證強一致性呢？我們可以在讀取數據的時候先執行一下 sync 操作，即與 leader 節點先同步一下數據，再去取，這樣才能保證數據的強一致性。
但是 zookeeper 也有個缺陷，剛剛提到了 leader 節點，當 master 節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新進行 leader 選舉。問題在於，選舉 leader 的時間太長，30 ~ 120s, 且選舉期間整個 zookeeper 集羣都是不可用的，這就導致在選舉期間註冊服務癱瘓。
在雲部署的環境下，因網絡問題使得 zookeeper 集羣失去 master 節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。比如雙十一當天，那就是災難性的。
3. eureka 的 AP 原則
大規模網絡部署時，失敗是在所難免的，因此我們無法迴避這個問題。當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息，但不能接受服務直接 down 掉不可用。
Eureka 在被設計的時候，就考慮到了這一點，因此在設計時優先保證可用性，這就是 AP 原則。Eureka 各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而 Eureka 的客戶端在向某個 Eureka 註冊或時如果發現連接失敗，則會自動切換至其它節點，只要有一臺 Eureka 還在，就能保證註冊服務可用（即保證A原則），只不過查到的信息可能不是最新的（不保證B原則）。
正因爲應用實例的註冊信息在集羣的所有節點間並不是強一致的，所以需要客戶端能夠支持負載均衡以及失敗重試。在 Netflix 的生態中，ribbon 可以提供這個功能。
因此， Eureka 可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像 zookeeper 那樣使整個註冊服務癱瘓。
作爲服務註冊中心，最重要的是要保證可用性，可以接收段時間內數據不一致的情況。個人覺得 Eureka 作爲單純的服務註冊中心來說要比 zookeeper 更加“專業”一點。
更多優質文章請關注我的微信公衆號【程序員私房菜】，回覆“資源”和“架構”可以領取優質的視頻學習資源。
