Spring Cloud：Zookeeper和Eureka的區別在哪？

0. CAP 理論

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

對於分散式系統來說，出現網路分割槽是不可避免的，因此分割槽容錯性是必須要具備的，也就是說，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 更加“專業”一點。