關於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一樣直接集群癱瘓