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 更加適合一點。