分布式CAP定理,為什麼不能同時滿足三個特性

2021-09-25 13:58:03 字數 2152 閱讀 2082

在弄清楚這個問題之前,我們先了解一下什麼是分布式的cap定理。

「all nodes see the same data at the same time」,即更新操作成功並返回客戶端後,所有節點在同一時間的資料完全一致,這就是分布式的一致性。一致性的問題在併發系統中不可避免,對於客戶端來說,一致性指的是併發訪問時更新過的資料如何獲取的問題。從服務端來看,則是更新如何複製分布到整個系統,以保證資料最終一致。

可用性指「reads and writes always succeed」,即服務一直可用,而且是正常響應時間。好的可用性主要是指系統能夠很好的為使用者服務,不出現使用者操作失敗或者訪問超時等使用者體驗不好的情況。

即分布式系統在遇到某節點或網路分割槽故障的時候,仍然能夠對外提供滿足一致性和可用性的服務。

分割槽容錯性要求能夠使應用雖然是乙個分布式系統,而看上去卻好像是在乙個可以運轉正常的整體。比如現在的分布式系統中有某乙個或者幾個機器宕掉了,其他剩下的機器還能夠正常運轉滿足系統需求,對於使用者而言並沒有什麼體驗上的影響。

現在我們就來證明一下,為什麼不能同時滿足三個特性?

假設有兩台伺服器,一台放著應用a和資料庫v,一台放著應用b和資料庫v,他們之間的網路可以互通,也就相當於分布式系統的兩個部分。

在滿足一致性的時候,兩台伺服器(假設為n1,n2)的資料是一樣的,db0=db0。在滿足可用性的時候,使用者不管是請求n1或者n2,都會得到立即響應。在滿足分割槽容錯性的情況下,n1和n2有任何一方宕機,或者網路不通的時候,都不會影響n1和n2彼此之間的正常運作。

圖一中,使用者通過n1中的a應用請求資料更新到伺服器db0,這時n1中的伺服器db0變為db1,通過分布式系統的資料同步更新操作,n2伺服器中的資料庫v0也更新為了db1,這時,使用者通過b向資料庫發起請求得到的資料就是即時更新後的資料db1。

上面是正常運作的情況,但分布式系統中,最大的問題就是網路,現在假設一種極端情況,n1和n2之間的網路斷開了,但我們仍要支援這種網路異常,也就是滿足分割槽容錯性,那麼這樣能不能同時滿足一致性和可用性呢?

假設n1和n2之間通訊的時候網路突然出現故障,有使用者向n1傳送資料更新請求,那n1中的資料db0將被更新為db1,由於網路是斷開的,n2中的資料庫仍舊是db0;

如果這個時候,有使用者向n2傳送資料讀取請求,由於資料還沒有進行同步,應用程式沒辦法立即給使用者返回最新的資料db1,怎麼辦呢?有二種選擇,第一,犧牲資料一致性,響應舊的資料db0給使用者;第二,犧牲可用性,阻塞等待,直到網路連線恢復,資料更新操作完成之後,再給使用者響應最新的資料db1。

上面的過程是比較簡單 (鑑於樓主作圖水平實在太渣,希望各位勿噴,哈哈吐舌頭) ,但也說明了要滿足分割槽容錯性的分布式系統,只能在一致性和可用性兩者中,選擇其中乙個。也就是說分布式系統不可能同時滿足三個特性。這就需要我們在搭建系統時進行取捨了,那麼,怎麼取捨才是更好的策略呢?

ca without p:如果不要求p(不允許分割槽),則c(強一致性)和a(可用性)是可以保證的。但放棄p的同時也就意味著放棄了系統的擴充套件性,也就是分布式節點受限,沒辦法部署子節點,這是違背分布式系統設計的初衷的。

cp without a:如果不要求a(可用),相當於每個請求都需要在server之間強一致,而p(分割槽)會導致同步時間無限延長(也就是等待資料同步完才能正常訪問服務),如此cp也是可以保證的。很多傳統的資料庫分布式事務都屬於這種模式。

ap wihtout c:要高可用並允許分割槽,則需放棄一致性。一旦分割槽發生,節點之間可能會失去聯絡,為了高可用,每個節點只能用本地資料提供服務,而這樣會導致全域性資料的不一致性。現在眾多的nosql都屬於此類,如redis,mongdb等。

現如今,對於多數大型網際網路應用的場景,主機眾多、部署分散,而且現在的集群規模越來越大,節點只會越來越多,所以節點故障、網路故障是常態,因此分割槽容錯性也就成為了乙個分布式系統必然要面對的問題。那麼就只能在c和a之間進行取捨。但對於傳統的專案就可能有所不同,拿銀行的轉賬系統來說,涉及到金錢的對於資料一致性不能做出一絲的讓步,c必須保證,出現網路故障的話,寧可停止服務,可以在a和p之間做取捨。

總而言之,沒有最好的策略,好的系統應該是根據業務場景來進行架構設計的,只有適合的才是最好的。

出處

分布式定理 CAP定理

cap定理指的是,在乙個分布式系統中,只能滿足cap中的兩項。c consistency 一致性 a ailability 可用性 p partition tolerance 分割槽可容錯性 在任意分割槽網路故障的情況下系統仍能繼續執行 網路並不可靠,所以你應要支援分割槽容錯性,並需要在軟體可用性和...

理解分布式CAP定理

概念 c 一致性 指分布式系統中每個節點的資料備份在同一時刻保持一致。a 可用性 在集群中一部分節點故障後,集群整體是否還能響應客戶端的讀寫請求。p 分割槽容忍性 系統不能在一定時間內完成資料的一致性的情況下 例如部分節點宕機 網路狀況等 必須在c和a中做出選擇 分析與取捨 cap三種特性無法同時滿...

分布式系統CAP定理

c 資料一致性 a 服務可用性 p 服務對網路分割槽故障的容錯性這三個特性在任何分布式系統中不能同時滿足,最多同時滿足兩個 zookeeper是個cp的,即任何時刻對zookeeper的訪問請求能得到一致的資料結果,同時系統對網路分割具備容錯性 但是它不能保證每次服務請求的可用性 注 也就是在極端環...