今天看了一篇eureka對比zookeeper的文章，對zookeeper滿足CAP中的CP，eureka滿足AP產生了一點疑問，故寫此篇文章進行一些探討。
首先我們來看看CAP的定義
Consistency
中文叫做"一致性"。意思是，寫操作之后的讀操作，必須返回該值。舉例來說，某條記錄是 v0，用戶向 G1 發起一個寫操作，將其改為 v1，接下來，用戶的讀操作就會得到 v1。這就叫一致性。
Availability
中文叫做"可用性"，意思是只要收到用戶的請求，服務器就必須給出回應。用戶可以選擇向 G1 或 G2 發起讀操作。不管是哪台服務器，只要收到請求，就必須告訴用戶，到底是 v0 還是 v1，否則就不滿足可用性。
Partition tolerance:
中文叫做"分區容錯"，大多數分布式系統都分布在多個子網絡。每個子網絡就叫做一個區（partition）。分區容錯的意思是，區間通信可能失敗。比如，一台服務器放在中國，另一台服務器放在美國，這就是兩個區，它們之間可能無法通信。
即在一個分布式系統中，只能滿足其中的兩個，且在一般情況下，都是要滿足分區容錯性的。
eureka的AP特性
eureka既然說滿足AP特性，是否說明eureka是一個不滿足一致性的注冊中心呢，這樣一來作為一個注冊中心中間件肯定是無法接受的，所以我們來細究下。
Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩余的節點依然可以提供注冊和查詢服務。而Eureka的客戶端在向某個Eureka注冊或時如果發現連接失敗，則會自動切換至其它節點，只要有一台Eureka還在，就能保證注冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)，其中說明了，eureka是不滿足強一致性，但還是會保證最終一致性，所以可以得出一個結論，eureka不是不滿足一致性，只是在同等情況下，eureka會首先保證可用性，在一定程度內再去進行一致性的同步。
zookeeper的CP特性
同樣我們來看zookeeper，zookeeper在選舉leader時，會停止服務，直到選舉成功之后才會再次對外提供服務，這個時候就說明了服務不可用，但是在選舉成功之后，因為一主多從的結構，zookeeper在這時還是一個高可用注冊中心，只是在優先保證一致性的前提下，zookeeper才會顧及到可用性。
總結
所以這里從zk的CP和eureka的AP探討得出一個結果，CAP其實在分布式系統中，是優先保證滿足其中兩個特性，而不是傳統意義上的單純只滿足其中兩個特性而舍棄另一個特性。