關於CAP理論，可以去看看阮一峰的文章[http://www.ruanyifeng.com/blog/2018/07/cap.html]
C(一致性)A(可用性)P(分區容錯性)

ZooKeeper：
zookeeper保證了cp(一致性、分區容錯性)，但是作為服務註冊中心，我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息。但是服務中心卻必須保證可用性，
即服務註冊中心對於高可用性的需求高於一致性。對於可用性，zookeeper有一個leader選舉方案。當master主節點宕機與其他節點失去聯系時，其他節點會重
新進行Leader選舉，選出新的master節點。然而選舉耗時過長，一般為30~120S，並且整個選舉期間，整個zookeeper集群是無法使用的。

Eureka：
eureka保證了ap(可用性、分區容錯性)，eureka每一個節點都是平等的，幾個節點宕機不會影響正常節點的工作。剩余的正常節點依舊可以提供服務註冊和查詢。
並且，當客戶端向某節點註冊服務時，註冊失敗或者超時，則會自動切換到其他節點。只要有一臺eureka節點還正常工作，就能保證註冊服務的可用。但是對於服
務信息的同步則不能保證一致性(不能保證強一致性，但是最終一致)。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內85%的節點都沒有正常心跳(不可用)
那麽Eureka就認為客戶端與註冊中心之間出現了網絡故障，此時會出現以下幾種情況：
1、Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務
2、Eureka仍然能夠接收新服務的註冊和查詢請求，但是不會被同步到其他節點上(保證當前節點的可用性)
3、當網絡穩定後，當前實例新註冊的服務會被同步到其他節點

因此,Eureka能夠保證註冊中心的高可用性，而不會像zookeeper一樣直接集群癱瘓

Springcloud 的Eureka和ZooKeeper比較