關於註冊中心的CAP定理。

C.Consistency 數據一致性

不一樣節點請求或屢次請求。數據要一致。(多個節點數據同步須要時間)
複製代碼

A.Availability 服務可用性

發起請求，必需要有響應(要在規定時間返回結果)
複製代碼

P.Partition tolerance 分區容錯性

大多數分佈式系統都分佈在多個子網絡。由於如今的網絡問題，基本都會出現訪問失敗，因此必定要有分區容錯性。那麼P就必定要有。(分佈式系統都有多個節點，掛掉部分也要繼續可用，若是沒有的話，有些請求就一直返回失敗，直到問題解決。)
複製代碼

CAP定義 。這三個指標不可能同時作到。

CA:
    保證了數據一致性和服務的可用性。 
    由於如今的網絡環境。基本都會出現訪問失敗。因此不可能不要分區容錯性。
    CA架構很難實現。
CP:
    保證了數據的一致性和分區容錯性。
    分區容錯性有了，那麼就須要多個節點，數據同步就須要時間。
    當時間上去了，爲了保證數據的一致性。服務須要時間等待數據同步完成才獲取數據，等待時間太久就會致使服務不可用。就至關於不能實現A。
AP:
    保證了服務的可用性和分區容錯性。
    分區容錯性有了，那麼就須要多個節點。須要保證服務可用性，就須要快速響應。
    要快速響應，就不能等待數據同步完成才響應。
    因此就會致使數據非一致性，至關於不能實現C。
複製代碼

在保證了分區容錯性P的狀況下。 C和A是衝突。

要保證數據一致性。那麼就須要時間。須要時間。服務可用性就不能知足了。
要保證服務可用性，那麼就須要儘快返回。要速度快，就表示數據來不及同步。因此就不能保證數據一致性。
複製代碼

CP: Zookeeper,Consul,etcd 若是你要保證數據一致性，那麼就用CP的。

AP: Eureka 若是你要保證服務可用性。那就用AP的