JavaEE進階知識學習-----SpringCloud（五）Eureka和Zookeeper區別

Eureka和Zookeeper區別

遵循原則不一樣

Eureka遵循AP原則，Zookeeper遵循CP原則，C：強一致性，A：可用性，P：分區容錯性

著名的CAP理論中提出，一個分佈式系統不可能同時知足C(一致性)A(可用性)P(分區容錯性)，因爲分區容錯性p是分佈式系統中必須保證，所以只能在A和C之間權衡

Zookeeper保證CP

在Zookeeper中存在一種狀況下，當master節點由於網絡故障與其餘節點失去聯繫時，剩餘節點會從新進行leader選舉，可是，選舉leader的時間太長，且選舉過程當中這個Zookeeper集羣是不可用的，這就致使在選舉期間註冊服務癱瘓，在雲部署的環境中，由於網絡問題使得Zookeeper集羣失去master節點的可能性較大，雖然服務最終可以恢復，可是在漫長的選舉時間致使的註冊時間不可用是不能容忍的，當咱們向註冊中心查詢註冊列表時，能夠忍受註冊中心返回的是幾分鐘之前的註冊信息，可是不能接收服務直接down不可用，也就是說，服務註冊對可用性的要求高於一致性。

Eureka保證AP

Eureka知道Zookeeper的不足，因此設計最初就保證可用性，Eureka各個節點都是平等的，幾個節點的掛點不會影響其餘正常節點的工做，剩餘的節點仍然能夠提供註冊和查詢服務，只不過不能保證查詢的信息是最新的，除此以外，Eureka還有一種自我保護機制，當過多的節點沒有正常的心跳時，那麼Eureka就會認爲客戶端出現了網絡故障，此時Eureka會

• Eureka不會從註冊表中移除由於長時間沒有收到心跳而應該過時的服務
• Eureka仍然可以接受新服務的註冊和查詢請求，可是不會同步到其餘節點上（保證當前節點可用）
• 當網絡穩定時，當前實例新的註冊信息會被同步到其餘節點上