CAP原則又稱CAP定理,指的是在一個分佈式系統中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分區容錯性)這三個基本需求,最多隻能同時知足其中的2個。算法
選項 | 描述 |
---|---|
Consistency(一致性) | 指數據在多個副本之間可以保持一致的特性(嚴格的一致性) |
Availability(可用性) | 指系統提供的服務必須一直處於可用的狀態,每次請求都能獲取到非錯的響應(不保證獲取的數據爲最新數據) |
Partition tolerance(分區容錯性) | 分佈式系統在遇到任何網絡分區故障的時候,仍然可以對外提供知足一致性和可用性的服務,除非整個網絡環境都發生了故障 |
什麼是分區?數據庫
在分佈式系統中,不一樣的節點分佈在不一樣的子網絡中,因爲一些特殊的緣由,這些子節點之間出現了網絡不通的狀態,但他們的內部子網絡是正常的。從而致使了整個系統的環境被切分紅了若干個孤立的區域,這就是分區。編程
如圖所示,是咱們證實CAP的基本場景,網絡中有兩個節點N1和N2,能夠簡單的理解N1和N2分別是兩臺計算機,他們之間網絡能夠連通,N1中有一個應用程序A,和一個數據庫V,N2也有一個應用程序B和一個數據庫V。如今,A和B是分佈式系統的兩個部分,V是分佈式系統的數據存儲的兩個子數據庫。後端
如圖所示,這是分佈式系統正常運轉的流程,用戶向N1機器請求數據更新,程序A更新數據庫V0爲V1。分佈式系統將數據進行同步操做M,將V1同步的N2中V0,使得N2中的數據V0也更新爲V1,N2中的數據再響應N2的請求。緩存
根據CAP原則定義,系統的一致性、可用性和分區容錯性細分以下:網絡
這是正常運做的場景,也是理想的場景。做爲一個分佈式系統,它和單機系統的最大區別,就在於網絡。如今假設一種極端狀況,N1和N2之間的網絡斷開了,咱們要支持這種網絡異常。至關於要知足分區容錯性,能不能同時知足一致性和可用性呢?仍是說要對他們進行取捨?多線程
假設在N1和N2之間網絡斷開的時候,有用戶向N1發送數據更新請求,那N1中的數據V0將被更新爲V1。因爲網絡是斷開的,因此分佈式系統同步操做M,因此N2中的數據依舊是V0。這個時候,有用戶向N2發送數據讀取請求,因爲數據尚未進行同步,應用程序沒辦法當即給用戶返回最新的數據V1,怎麼辦呢?架構
這裏有兩種選擇:框架
這個過程,證實了要知足分區容錯性的分佈式系統,只能在一致性和可用性二者中,選擇其中一個。異步
經過CAP理論,咱們知道沒法同時知足一致性、可用性和分區容錯性這三個特性,那要捨棄哪一個呢?
若是不要求P(不容許分區),則C(強一致性)和A(可用性)是能夠保證的。但其實分區不是你想不想的問題,而是始終會存在,所以CA的系統更多的是容許分區後各子系統依然保持CA。
若是不要求A(可用),至關於每一個請求都須要在Server之間強一致,而P(分區)會致使同步時間無限延長,如此CP也是能夠保證的。不少傳統的數據庫分佈式事務都屬於這種模式。
要高可用並容許分區,則需放棄一致性。一旦分區發生,節點之間可能會失去聯繫,爲了高可用,每一個節點只能用本地數據提供服務,而這樣會致使全局數據的不一致性。如今衆多的NoSQL都屬於此類。
對於多數大型互聯網應用的場景,主機衆多、部署分散。並且如今的集羣規模愈來愈大,因此節點故障、網絡故障是常態。這種應用通常要保證服務可用性達到N個9,即保證P和A,只有捨棄C(退而求其次保證最終一致性)。雖然某些地方會影響客戶體驗,但沒達到形成用戶流程的嚴重程度。
對於涉及到錢財這樣不能有一絲讓步的場景,C必須保證。網絡發生故障寧肯中止服務,這是保證CA,捨棄P。貌似這幾年國內銀行業發生了不下10起事故,但影響面不大,報到也很少,廣大羣衆知道的少。還有一種是保證CP,捨棄A,例如網絡故障時只讀不寫。
孰優孰劣,沒有定論,只能根據場景定奪,適合的纔是最好的。
歡迎掃碼關注公衆號: 零壹技術棧
本賬號將持續分享後端技術乾貨,包括虛擬機基礎,多線程編程,高性能框架,異步、緩存和消息中間件,分佈式和微服務,架構學習和進階等學習資料和文章。