CAP理論/AP架構/CP架構

 

 

原文地址：https://blog.csdn.net/u013058742/article/details/83541905 

簡書裏的文章：Spring Cloud Eureka簡介及與Zookeeper對比，明顯的區別可能就是Zookeeper爲CP設計，而Eureka爲AP設計，可是對CAP/AP/CP很不理解，因而查閱資料，作一個簡單的瞭解。

Eureka服務治理機制與Dubbo服務治理機制的比較

Feature	Eureka	Zookeeper
服務健康檢查	可配支持	(弱)長鏈接，keepalive
CAP	AP	CP
watch支持（客戶端觀察到服務提供者變化）	支持 long polling/大部分增量	支持
自我保護	支持	-
客戶端緩存	支持	-
自身集羣的監控	metrics	-

Eureka支持健康檢查，自我保護等

Zookeeper爲CP設計，Eureka爲AP設計。做爲服務發現產品，可用性優先級較高，一致性的特色並不重要，寧肯返回錯誤的數據，也比不反回結果要好得多。

服務列表變動Zookeeper服務端會有通知，Eureka則經過長輪詢來實現，Eureka將來會實現watch機制

CAP理論提出就是針對分佈式數據庫環境的，因此，P這個屬性是必須具有的。
P就是在分佈式環境中，因爲網絡的問題可能致使某個節點和其它節點失去聯繫，這時候就造成了P(partition)，也就是因爲網絡問題，將系統的成員隔離成了2個區域，互相沒法知道對方的狀態，這在分佈式環境下是很是常見的。
由於P是必須的，那麼咱們須要選擇的就是A和C。
你們知道，在分佈式環境下，爲了保證系統可用性，一般都採起了複製的方式，避免一個節點損壞，致使系統不可用。那麼就出現了每一個節點上的數據出現了不少個副本的狀況，而數據從一個節點複製到另外的節點時須要時間和要求網絡暢通的，因此，當P發生時，也就是沒法向某個節點複製數據時，這時候你有兩個選擇：
選擇可用性 A(Availability)，此時，那個失去聯繫的節點依然能夠向系統提供服務，不過它的數據就不能保證是同步的了（失去了C屬性）。
選擇一致性C(Consistency)，爲了保證數據庫的一致性，咱們必須等待失去聯繫的節點恢復過來，在這個過程當中，那個節點是不容許對外提供服務的，這時候系統處於不可用狀態(失去了A屬性)。

最多見的例子是讀寫分離，某個節點負責寫入數據，而後將數據同步到其它節點，其它節點提供讀取的服務，當兩個節點出現通訊問題時，你就面臨着選擇A（繼續提供服務，可是數據不保證準確），C（用戶處於等待狀態，一直等到數據同步完成）。