Zookeeper在設計的時候遵循的是CP原則，即一致性,Zookeeper會出現這樣一種情況，當master節點因為網絡故障與其他節點失去聯系時剩余節點會重新進行leader選舉，問題在于，選舉leader的時間太長：30~120s，且選舉期間整個Zookeeper集群是不可用的，這就導致在選舉期間注冊服務處于癱瘓狀態，在云部署的環境下，因網絡環境使Zookeeper集群失去master節點是較大概率發生的事情，雖然服務能夠最終恢復，但是漫長的選舉時間導致長期的服務注冊不可用是不能容忍的。

?Eureka在設計的時候遵循的是AP原則，即可用性。Eureka各個節點（服務)是平等的， 沒有主從之分，幾個節點down掉不會影響正常工作，剩余的節點（服務） 依然可以提供注冊與查詢服務，而Eureka的客戶端在向某個Eureka注冊或發現連接失敗，則會自動切換到其他節點，也就是說，只要有一臺Eureka還在，就能注冊可用（保證可用性）， 只不過查詢到的信息不是最新的（不保證強一致），除此之外，Eureka還有自我保護機制，如果在15分鐘內超過85%節點都沒有正常心跳，那么eureka就認為客戶端與注冊中心出現了網絡故障，此時會出現一下情況:

1: Eureka 不再從注冊列表中移除因為長時間沒有收到心跳而過期的服務。

2：Eureka 仍然能夠接收新服務的注冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點可用）

3： 當網絡穩定后，當前實例新的注冊信息會被同步到其它節點中

?

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的eureka对比Zookeeper：的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。