在分佈式領域有一個很著名的CAP定理：C：數據一致性。A：服務可用性。P：分區容錯性（服務對網絡分區故障的容錯性）
1、什麼是Eureka 保證AP
1.Eureka是netflix的一個子模塊，也是核心模塊之一，Eureka是一個基於REST的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。服務註冊與發現對於微服務架構來說是非常重要的，有了服務發現和註冊，只需要使用服務的標識符，就可以訪問到服務，而不需要修改服務，而不需要修改服務調用的配置文件了。
2.Eureka的作用
2.1 Eureka採用了C-S的設計架構。Eureka Server作爲服務註冊功能的服務器，它是服務註冊時中心。
而系統中的其他微服務，使用eureka的客戶端連接到eureka server並維持心跳連接。這樣系統的維護人員就可以通過eureka server來監控系統中各個微服務是否正常運行。SpringCloud的一些其他模塊就可以通過eureka server來發現系統中的其他微服務，並執行相關的邏輯。
2.2 Eureka Server提供服務註冊服務。各個節點啓動後，會在Eureka Server中進行註冊，這樣Eureka server中的服務註冊表中將會存儲所有可用服務節點的信息，服務節點的信息可以在界面中直觀的看到。
2.3 Eureka client是一個java客戶端，用於簡化eureka server的交互，客戶端同時也具備一個內置的，使用輪詢負載算法的負載均衡器。在應用啓動後，將會向Eureka Server發送心跳。如果Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，Eureka Server將會從服務註冊表把這個服務節點移除。
2. 什麼是Zookeeper 保證 CP
ZooKeeper 是一個分佈式的，開放源碼的分佈式應用程序協調服務，它包含一個簡單的原語集，分佈式應用程序可以基於它實現同步服務，配置維護和命名服務等。 Zookeeper是hadoop的一個子項目。在分佈式應用中，由於工程師不能很好地使用鎖機制，以及基於消息的協調機制不適合在 某些應用中使用，因此需要有一種可靠的、可擴展的、分佈式的、可配置的協調機制來統一系統的狀態。
2.1 Zookeeper設計目標
① 簡單的數據結構：共享的樹形結構，類似文件系統，存儲於內存；
② 可以構建集羣：避免單點故障，3-5臺機器就可以組成集羣，超過半數正常工作久能對外提供服務；
③ 順序訪問：對於每個讀請求，zookeeper會分配一個全局唯一的遞增編號，利用這個特性可以實現高級協調服務；
④ 高性能：基於內存操作，服務於非事務請求，適用於讀操作爲主的業務操作。3臺zk集羣能達到13W QPS
2.2 哪些場景需要用到zk？
① 數據發佈訂閱 ② 負載均衡 ③ 命名服務 ④ Master選舉 ⑤ 集羣管理 ⑥ 配置管理 ⑦ 分佈式隊列 ⑧ 分佈式鎖
Eureka和Zookeeper區別？
- 在分佈式領域有一個很著名的CAP定理：C：數據一致性。A：服務可用性。P：分區容錯性（服務對網絡分區故障的容錯性）。
- Zookeeper取CAP的CP注重一致性，在可用性方面不太好，假如master節點故障，剩餘節點會重新leader選舉，選舉leader的時間太長30～120s，選舉期間整個集羣都不可用，這就導致在選舉期間註冊服務癱瘓，漫長選舉導致註冊不可用，不能容忍。
- Eureka看明白了這一點，因此在設計時就優先保證可用性。取CAP的AP，注重可用性。Eureka各個節點都是平等的，只要有一臺Eureka還在就能保證註冊服務可用（保證可用性），只不過可能查詢到的不是最新的。
- eureka的自我保護機制，會導致一個結果就是不會再從註冊列表移除因長時間沒收到心跳而過期的服務。依然能接受新服務的註冊和查詢請求，但不會被同步到其他節點（保證當前節點可用），當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中。也就是，不容易癱瘓。
- Zookeeper有Leader和Follower角色，Eureka各個節點平等。
- Zookeeper採用過
半數存活原則，Eureka採用自我保護機制解決分區問題。 - eureka本質是一個工程，Zookeeper只是一個進程。
- dubbo默認使用zookeeper，spring cloud默認使用eureka。