今天看了一篇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其實在分散式系統中，是優先保證滿足其中兩個特性，而不是傳統意義上的單純只滿足其中兩個特性而捨棄另一個特性。

&n