Eureka與Zookeeper的區別

CAP 理論指出，一個分散式系統不可能同時滿足 C( 一致性 ) 、 A( 可用性 ) 和 P( 分割槽容錯性 ) 。

由於分割槽容錯性在是分散式系統中必須要保證的，因此我們只能在 A 和 C 之間進行權衡，在此 Zookeeper

保證的是 CP, 而 Eureka 則是 AP 。

Zookeeper保證資料一致性和分割槽容錯性

        在ZooKeeper 中，當 master 節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行

leader 選舉，但是問題在於，選舉 leader 需要一定時間 , 且選舉期間整個 ZooKeeper 叢集都是不可用

的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網路問題使得 ZooKeeper 叢集失去

master 節點是大機率事件，雖然服務最終能夠恢復，但是在選舉時間內導致服務註冊長期不可用是難以容忍的。

Eureka保證可用性和分割槽容錯性

        Eureka優先保證可用性， Eureka 各個節點是平等的，某幾個節點掛掉不會影響正常節點的工作， 剩餘的節點依然可以提供註冊和查詢服務。而Eureka 的客戶端在向某個 Eureka 註冊或時如果發現連線 失敗，則會自動切換至其它節點，只要有一臺Eureka 還在，就能保證註冊服務可用 ( 保證可用性 ) ，只不 過查到的資訊可能不是最新的( 不保證強一致性 ) 。

        所以Eureka 在網路故障導致部分節點失去聯絡的情況下，只要有一個節點可用，那麼註冊和查詢服務就 可以正常使用，而不會像zookeeper 那樣使整個註冊服務癱瘓， Eureka 優先保證了可用性。

        總結

Eureka會造成短暫的資料不一致性，這是可以容忍的，但是zookeeper在主伺服器down的時候，要選取新的主伺服器，造成的時間導致服務註冊長期不可用時難以容忍的，所以推薦使用Eureka，再加上Eureka整合Spring Cloud是十分方便的，所以推薦大家使用Eureka作為服務註冊中心。