CAP是Consistency、Availablity和Partition Tolerance的縮寫。一般的分散式系統最多滿足其中兩條。而Partition Tolerance是分散式系統的關鍵，因此都會保留此特性。

Eureka是基於AP原則構建的，而ZooKeeper是基於CP原則構建的。這些可以從他們的特性中得到體現。

ZK有一個Leader，而且在Leader無法使用的時候通過Paxos（ZAB）演算法選舉出一個新的Leader。這個Leader的目的就是保證寫資訊的時候只向這個Leader寫入，Leader會同步資訊到Followers。這個過程就可以保證資料的一致性。

對比下ZK，Eureka不用選舉一個Leader。每個Eureka伺服器單獨儲存服務註冊地址，Eureka也沒有Leader的概念。這也因此產生了無法保證每個Eureka伺服器都儲存一直資料的特性。當Eureka與註冊者心跳無法保持的時候，依然儲存註冊列表的資訊很長一段時間。當然了，客戶端中必須用有效的機制遮蔽壞掉的伺服器，這個Spring Cloud中的體現是Ribbon。

Eureka因為沒有選舉過程來選舉Leader，因此寫的資訊可以獨立進行。因此有可能出現數據信息不一致的情況。但是當網路出現問題的時候，每臺伺服器也可以完成獨立的服務。當然了，一些客戶端的負載平衡和Fail Over機制需要來輔助完成額外的功能。相較之下，ZK因為基於CP原則，能保證很好的資料一致性，但是可用性支援力度不高。而在一個內部系統中，主要是服務的註冊與發現，而不是配置（檔案）共享，因此Eureka更適用於內部服務的建設。