Zookeeper和Eureka有哪些區別？
CAP定理
在分布式系統的發展中，影響最大的莫過于CAP定理了，是分布式系統發展的理論基石。
- 2000年，加州大學的計算機科學家 Eric Brewer提出了CAP猜想
- 2002 年，麻省理工學院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了 CAP 猜想，CAP猜想成為了CAP定理
「CAP定理，簡單來說就是分布式系統不可能同時滿足Consistency 一致性、Availability 可用性、Partition Tolerance 分區容錯性三個要素」
Consistency 一致性
一致性的含義為，在節點的任意時刻，訪問任意節點返回的數據是一致的。即Client端寫入一個數據后，Server端將數據同步到整個系統，從而保證系統的數據都相同
Availability 可用性
可用性的含義為，集群能夠對用戶的請求給予響應。
Partition Tolerance 分區容錯性
分區容錯的含義為，當出現分區故障時，系統仍要對外提供服務。分布式系統中，每個服務節點都是不可靠的，當某些節點出現異常時，或者節點之間的通訊產生異常時，整個系統就產生了分區問題，分布式系統中分區問題是客觀存在的。
CAP權衡
CA
系統選擇CA，即不支持分區容錯，只支持一致性和可用性。意味著不允許出現分區異常，網絡一致處于理想狀態。但是分布式系統之間網絡異常是客觀存在的，如果避免了P，只能把分布式系統退回到單實例系統。
CP
因為分布式系統P是客觀存在的，所以我們要在CP和AP之間進行抉擇。
在網絡分區發生時，兩個分布式節點之間無法進行通信，我們對一個節點進行的修改操作將無法同步到另外一個節點，所以數據的「一致性」將無法滿足，因為兩個分布式節點的數據不再保持一致。除非我們犧牲「可用性」，也就是暫停分布式節點服務，在網絡分區發生時，不再提供修改數據的功能，直到網絡狀況完全恢復正常再繼續對外提供服務
「當選擇CP時，相當于放棄系統的可用性，換取一致性」。zookeeper是選擇了CP的系統
在zookeeper集群中，有如下三種角色
| 角色 | 作用 |
|---|---|
| Leader | 事務請求的唯一調度者和處理者 （事務請求為除查詢之外的請求） |
| Follower | 處理非事務請求，參與Leader選舉投票 |
| Observer | 處理非事務請求，不參與選舉投票 |
在Leader服務器失效時，會重新從Follower服務器中選舉一個新的服務器作為Leader服務器。「在重新選舉Leader服務器的過程中，事務請求會被掛起，選舉完Leader服務器之后才會執行這些請求」。即為了保證一致性，放棄了系統的可用性
AP
「當選擇AP時，相當于放棄系統一致性，換取可用性」。eureka是選擇了AP的系統
和zookeeper集群中有三種角色不同的是，eureka集群中每個節點扮演相同的角色，他們通過互相注冊的方式來感知對方的存在，當有注冊信息時，他們會同步給集群內的其他節點。
下面我從源碼角度分析一下eureka是如何放棄一致性來保證可用性的(放心，不會放源碼的，說一下大概思路。源碼也比較簡單，有興趣的可以看我寫的博客https://blog.csdn.net/zzti_erlie/article/details/104088914)
eureka注冊中心的信息保存在AbstractInstanceRegistry類的成員變量中
- // AbstractInstanceRegistry
- private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry
- = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();
就是一個雙層map，這個雙層map也很好理解。最外層是服務名，里面是一個具體的實例名
當有服務往eureka上注冊時，注冊信息會被保存在map中，同時會把信息同步給其他的節點。此時有可能有些節點不可用了，或者網絡故障，并沒有收到信息，此時集群節點內的信息可能是不一致的。
當客戶端從某個eureka節點獲取信息失敗，或者注冊失敗，會自動切換到另一個eureka節點。只要有一臺eureka節點可用，就能保證注冊服務可用。
Zookeeper和Eureka的區別
最后總結一下兩者的區別
| Zookeeper | Eureka | |
|---|---|---|
| 設計原則 | CP | AP |
| 優點 | 數據最終一致 | 服務高可用 |
| 缺點 | 選舉leader過程中集群不可用 | 服務節點間的數據可能不一致 |
| 適用場景 | 對數據一致性要求較高 | 對注冊中心服務可用性要求較高 |
本文轉載自微信公眾號「Java識堂」，可以通過以下二維碼關注。轉載本文請聯系Java識堂公眾號。
