前言
最近在面試的時候，被問到了這個問題，作答的不是很好，在此進行整理和學習，希望能夠幫助大家。
CAP理論
在了解eureka和zookeeper區別之前，我們先來了解一下這個知識，cap理論。
1998年的加州大學的計算機科學家 Eric Brewer 提出，分布式有三個指標。Consistency，Availability，Partition tolerance。簡稱即為CAP。Eric 提出 CAP 不能全部達到，這就是CAP定理。
接下來我們分別說下cap。
C
Consistency，一致性的意思。
一致性就是說，我們讀寫數據必須是一摸一樣的。
比如一條數據，分別存在兩個服務器中，server1和server2。
我們此時將數據a通過server1修改為數據b。此時如果我們訪問server1訪問的應該是b。
當我們訪問server2的時候，如果返回的還是未修改的a，那么則不符合一致性，如果返回的是b，則符合數據的一致性。
A
Availability，可用性的意思。
這個比較好理解，就是說，只要我對服務器，發送請求，服務器必須對我進行相應，保證服務器一直是可用的。
P
Partition tolerance，分區容錯的意思。
一般來說，分布式系統是分布在多個位置的。比如我們的一台服務器在北京，一台在上海。可能由於天氣等原因的影響。造成了兩條服務器直接不能互相通信，數據不能進行同步。這就是分區容錯。我們認為，分區容錯是不可避免的。也就是說 P 是必然存在的。
為什么CAP只能達到 CP 或者 AP？
由以上我們得知，P是必然存在的。
如果我們保證了CP，即一致性與分布容錯。當我們通過一個服務器修改數據后，該服務器會向另一個服務器發送請求，將數據進行同步，但此時，該數據應處於鎖定狀態，不可再次修改，這樣，如果此時我們想服務器發送請求，則得不到相應，這樣就不能A，高可用。
如果我們保證了AP，那么我們不能對服務器進行鎖定，任何時候都要得到相應，那么數據的一致性就不好說了。
eureka和zookeeper的cap理論
eureka是基於ap的。zookeeper是基於cp的。
Eureka的實現
eureka的架構實現圖如下：
eureka的基本原理
上圖是來自eureka的官方架構圖，這是基於集群配置的eureka；
- 處於不同節點的eureka通過Replicate進行數據同步
- Application Service為服務提供者
- Application Client為服務消費者
- Make Remote Call完成一次服務調用
服務啟動后向Eureka注冊，Eureka Server會將注冊信息向其他Eureka Server進行同步，當服務消費者要調用服務提供者，則向服務注冊中心獲取服務提供者地址，然后會將服務提供者地址緩存在本地，下次再調用時，則直接從本地緩存中取，完成一次調用。
當服務注冊中心Eureka Server檢測到服務提供者因為宕機、網絡原因不可用時，則在服務注冊中心將服務置為DOWN狀態，並把當前服務提供者狀態向訂閱者發布，訂閱過的服務消費者更新本地緩存。
服務提供者在啟動后，周期性（默認30秒）向Eureka Server發送心跳，以證明當前服務是可用狀態。Eureka Server在一定的時間（默認90秒）未收到客戶端的心跳，則認為服務宕機，注銷該實例。
eureka的自我保護機制
在默認配置中，Eureka Server在默認90s沒有得到客戶端的心跳，則注銷該實例，但是往往因為微服務跨進程調用，網絡通信往往會面臨着各種問題，比如微服務狀態正常，但是因為網絡分區故障時，Eureka Server注銷服務實例則會讓大部分微服務不可用，這很危險，因為服務明明沒有問題。
為了解決這個問題，Eureka 有自我保護機制，通過在Eureka Server配置如下參數，可啟動保護機制。
eureka.server.enable-self-preservation=true
它的原理是，當Eureka Server節點在短時間內丟失過多的客戶端時（可能發送了網絡故障），那么這個節點將進入自我保護模式，不再注銷任何微服務，當網絡故障回復后，該節點會自動退出自我保護模式。
eureka保證ap
eureka優先保證可用性。在Eureka平台中，如果某台服務器宕機，Eureka不會有類似於ZooKeeper的選舉leader的過程；客戶端請求會自動切換 到新的Eureka節點；當宕機的服務器重新恢復后，Eureka會再次將其納入到服務器集群管理之中；而對於它來說，所有要做的無非是同步一些新的服務 注冊信息而已。所以，再也不用擔心有“掉隊”的服務器恢復以后，會從Eureka服務器集群中剔除出去的風險了。Eureka甚至被設計用來應付范圍更廣 的網絡分割故障，並實現“0”宕機維護需求。當網絡分割故障發生時，每個Eureka節點，會持續的對外提供服務（注：ZooKeeper不會）：接收新 的服務注冊同時將它們提供給下游的服務發現請求。這樣一來，就可以實現在同一個子網中（same side of partition），新發布的服務仍然可以被發現與訪問。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩余的節點依然可以提供注冊和查詢服務。而Eureka的客戶端在向某個Eureka注冊或時如果發現連接失敗，則會自動切換至其它節點，只要有一台Eureka還在，就能保證注冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此之外，Eureka還有一種自我保護機制，如果在15分鍾內超過85%的節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：
- Eureka不再從注冊列表中移除因為長時間沒收到心跳而應該過期的服務
- Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
- 當網絡穩定時，當前實例新的注冊信息會被同步到其它節點中
Eureka還有客戶端緩存功能（注：Eureka分為客戶端程序與服務器端程序兩個部分，客戶端程序負責向外提供注冊與發現服務接口）。 所以即便Eureka集群中所有節點都失效，或者發生網絡分割故障導致客戶端不能訪問任何一台Eureka服務器；Eureka服務的消費者仍然可以通過 Eureka客戶端緩存來獲取現有的服務注冊信息。甚至最極端的環境下，所有正常的Eureka節點都不對請求產生相應，也沒有更好的服務器解決方案來解 決這種問題時；得益於Eureka的客戶端緩存技術，消費者服務仍然可以通過Eureka客戶端查詢與獲取注冊服務信息。
zookeeper保證cp
作為一個分布式協同服務，ZooKeeper非常好，但是對於Service發現服務來說就不合適了；因為對於Service發現服務來說就算是 返回了包含不實的信息的結果也比什么都不返回要好；再者，對於Service發現服務而言，寧可返回某服務5分鍾之前在哪幾個服務器上可用的信息，也不能 因為暫時的網絡故障而找不到可用的服務器，而不返回任何結果。所以說，用ZooKeeper來做Service發現服務是肯定錯誤的。
當向注冊中心查詢服務列表時，我們可以容忍注冊中心返回的是幾分鍾以前的注冊信息，但不能接受服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集群失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。
eureka和zookeeper的區別總結
Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。Eureka作為單純的服務注冊中心來說要比zookeeper更加“專業”，因為注冊服務更重要的是可用性，我們可以接受短期內達不到一致性的狀況。