CAP理論/AP架構/CP架構

 

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

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屬性)。post

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

相關文章
相關標籤/搜索