ookeeper與Eureka區別
CPA理論:一個分布式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由於分區容錯性在是分布式系統中必須要保證的，因此我們只能在A和C之間進行權衡。在此Zookeeper保證的是CP, 而Eureka則是AP。
Consistency(一致性), 數據一致更新，所有數據變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容忍性) 可靠性
1、“C”是指一致性，即當一個Process（過程）修改了某個數據后，其他Process讀取這是數據是，得到的是更新后的數據，但並不是所有系統都 可以做到這一點。例如，在一些並非嚴格要求一致性的系統中，后來的Process得到的數據可能還是修改之前的數據，或者需要等待一定時間后才能得到修改 之后的數據，這被成為“弱一致性”，最經典的應用就是DNS系統。當用戶修改了DNS配置后，往往不會馬上在全網更新，必定會有一個延遲，這個延遲被稱為 “不一致窗口”，它的長度取決於系統的負載、冗余的個數等因素。但對於某些系統而言，一旦寫入，后面讀取的一定是修改后的數據，如銀行賬戶信息，這被稱為 “強一致性”。
2、“A”是指可用性。即系統總是能夠為用戶提供連續的服務能力。當用戶發出請求是，系統能給出響應（成功或者失敗），而且是立即給出響應，而不是等待其他事情完成才響應。如果需要等待某件事情完成才響應，那么“可用性”就不存在了。
3、“P”是指容錯性。任何一個分布式計算系統都是由多個節點組成的。在正常情況下，節點與節點之間的通信是正常的。但是在某些情況下，節點之間的通信會 斷開，這種斷開成為“Partition”。在分布式計算的實現中，Partition是很常見的，因為節點不可能永遠不出故障，尤其是對於跨物理地區的 海量存儲系統而言，而容錯性則可以保證如果只是系統中的部分節點不可用，那么相關的操作仍舊能夠正常完成。
Zookeeper是保證CP
當向注冊中心查詢服務列表時，我們可以容忍注冊中心返回的是幾分鍾以前的注冊信息，但不能接受服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集群失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。
Eureka是保證AP
Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩余的節點依然可以提供注冊和查詢服務。而Eureka的客戶端在向某個Eureka注冊或時如果發現連接失敗，則會自動切換至其它節點，只要有一台Eureka還在，就能保證注冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此之外，Eureka還有一種自我保護機制，如果在15分鍾內超過85%的節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：
1. Eureka不再從注冊列表中移除因為長時間沒收到心跳而應該過期的服務
2. Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網絡穩定時，當前實例新的注冊信息會被同步到其它節點中
因此， Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。
Eureka 具有自我保護機制，所以可用性比較強，zookeeper 沒有自我保護機制