傳統關系型數據庫 ACID
A：原子性：事務里面的所有操作，要么全部做完，要么都不做，只要有一個失敗，整個事務都失敗，需要回滾
C：一致性：以轉賬案例為例，假設有五個賬戶，每個賬戶余額是100元，那么五個賬戶總額是500元，如果在這個5個賬戶之間同時發生多個轉賬，無論並發多少個，比如在A與B賬戶之間轉賬5元，在C與D賬戶之間轉賬10元，在B與E之間轉賬15元，五個賬戶總額也應該還是500元，這就是保護性和不變性
I：隔離性：並發的事務之間互不影響
D：持久性：事務一旦提交，數據將永久保存在數據庫上
NoSQL 數據庫 CAP
C：強一致性：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
A：可用性：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
P：分區容錯性：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。（在分布式環境下，這個 p ，一定要實現）
zookeeper 保證 CP
當向注冊中心查詢服務列表時，我們可以容忍注冊中心返回的是幾分鍾以前的信息，但不能就收服務直接 down 掉不可用。也就是說服務注冊的可用性要高於一致性
當時 zk 會出現這么一個情況，當 mastr 節點因網絡故障和其他節點失去聯系時，剩余節點會重新進行選舉。問題在於，選舉時間比較長，30s~120s，且選舉期間，整個 zk 是不可用的。這就導致了在選舉期間，注冊服務的癱瘓。在雲部署的環境下，因網絡問題使 zk 集群時區 master 節點是交大概率會發生的事情，雖然服務能夠最終恢復，但是漫長的選舉時間導致的注冊服務長期不可用是不能容忍的。
Eureka 保證 AP
Eureka 明白這一點，因此在設計時，就優先保證可用性.Eureka 各個節點是平等的，幾個節點掛掉不會影響正常工作，只要有一台 Eureka 存在，就可以保證注冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）。除此之外，Eureka 還有一種自我保護機制，如果在 15 分鍾內超過 85% 的節點沒有正常的心跳，那么 Eureka 就會認為客戶端與注冊中心出現了故障，此時會出現以下幾種情況：
1、Eureka 不再從注冊列表中移出因長時間沒收到心跳而應該過期的服務
2、Eureka 仍然能夠接受新服務的注冊和查詢要求，但是不會被同步到其他節點上（即保證當前節點依然可用）
3、當網絡穩定時，當前實例新的注冊信息會被同步到其他節點中
結論
Eureka 可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像 zookeeper 那樣使整個祖冊服務癱瘓