CAP概述
C: Consistency 一致性
A: Availability 可用性
P:Partition Tolerance分區容錯性
CAP理論的核心是:一個分布式系統不可能同時很好的滿足一致性,可用性和分區容錯性這三個需求,最多只能同時較好的滿足兩個。
CAP的定義
1、C: Consistency 一致性
對於一致性,可以分為從客戶端和服務端兩個不同的視角。從客戶端來看,一致性主要指的是多並發訪問時更新過的數據如何獲取的問題。從服務端來看,則是更新如何復制分布到整個系統,以保證數據最終一致。一致性是因為有並發讀寫才有的問題,因此在理解一致性的問題時,一定要注意結合考慮並發讀寫的場景。
從客戶端角度,多進程並發訪問時,更新過的數據在不同進程如何獲取的不同策略,決定了不同的一致性。對於關系型數據庫,要求更新過的數據能被后續的訪問都能看到,這是強一致性。如果能容忍后續的部分或者全部訪問不到,則是弱一致性。如果經過一段時間后要求能訪問到更新后的數據,則是最終一致性。
2、A: Availability 可用性
對於一個可用性的分布式系統,每一個非故障的節點必須對每一個請求作出響應。也就是,該系統使用的任何算法必須最終終止。當同時要求分區容忍性時,這是一個很強的定義:即使是嚴重的網絡錯誤,每個請求必須終止。
好的可用性主要是指系統能夠很好的為用戶服務,不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。可用性通常情況下可用性和分布式數據冗余,負載均衡等有着很大的關聯。
3、P:Partition Tolerance分區容錯性
分區容錯性和擴展性緊密相關。在分布式應用中,可能因為一些分布式的原因導致系統無法正常運轉。好的分區容錯性要求能夠使應用雖然是一個分布式系統,而看上去卻好像是在一個可以運轉正常的整體。比如現在的分布式系統中有某一個或者幾個機器宕掉了,其他剩下的機器還能夠正常運轉滿足系統需求,或者是機器之間有網絡異常,將分布式系統分隔未獨立的幾個部分,各個部分還能維持分布式系統的運作,這樣就具有好的分區容錯性。
CAP原理的證明
如上圖,是我們證明CAP的基本場景,網絡中有兩個節點N1和N2,可以簡單的理解N1和N2分別是兩台計算機,他們之間網絡可以連通,N1中有一個應用程序A,和一個數據庫V,N2也有一個應用程序B2和一個數據庫V。現在,A和B是分布式系統的兩個部分,V是分布式系統的數據存儲的兩個子數據庫。
在滿足一致性的時候,N1和N2中的數據是一樣的,V0=V0。在滿足可用性的時候,用戶不管是請求N1或者N2,都會得到立即響應。在滿足分區容錯性的情況下,N1和N2有任何一方宕機,或者網絡不通的時候,都不會影響N1和N2彼此之間的正常運作。
如上圖,是分布式系統正常運轉的流程,用戶向N1機器請求數據更新,程序A更新數據庫Vo為V1,分布式系統將數據進行同步操作M,將V1同步的N2中V0,使得N2中的數據V0也更新為V1,N2中的數據再響應N2的請求。
這里,可以定義N1和N2的數據庫V之間的數據是否一樣為一致性;外部對N1和N2的請求響應為可用行;N1和N2之間的網絡環境為分區容錯性。這是正常運作的場景,也是理想的場景,然而現實是殘酷的,當錯誤發生的時候,一致性和可用性還有分區容錯性,是否能同時滿足,還是說要進行取舍呢?
作為一個分布式系統,它和單機系統的最大區別,就在於網絡,現在假設一種極端情況,N1和N2之間的網絡斷開了,我們要支持這種網絡異常,相當於要滿足分區容錯性,能不能同時滿足一致性和響應性呢?還是說要對他們進行取舍。
假設在N1和N2之間網絡斷開的時候,有用戶向N1發送數據更新請求,那N1中的數據V0將被更新為V1,由於網絡是斷開的,所以分布式系統同步操作M,所以N2中的數據依舊是V0;這個時候,有用戶向N2發送數據讀取請求,由於數據還沒有進行同步,應用程序沒辦法立即給用戶返回最新的數據V1,怎么辦呢?有二種選擇,第一,犧牲數據一致性,響應舊的數據V0給用戶;第二,犧牲可用性,阻塞等待,直到網絡連接恢復,數據更新操作M完成之后,再給用戶響應最新的數據V1。
這個過程,證明了要滿足分區容錯性的分布式系統,只能在一致性和可用性兩者中,選擇其中一個。
CAP實踐中的取舍
1、滿足一致性,可用性的系統,通常在可擴展性上不太強大,例如下面的產品:
Traditional RDBMSs like Postgres,MySQL, etc (relational)
Vertica (column-oriented)
Aster Data (relational)
Greenplum (relational)
2、滿足一致性,分區容忍必的系統,通常用戶操作響應上不太穩定,例如下面的產品:
BigTable (column-oriented/tabular)
Hypertable (column-oriented/tabular)
HBase (column-oriented/tabular)
MongoDB (document-oriented)
Terrastore (document-oriented)
Redis (key-value)
Scalaris (key-value)
MemcacheDB (key-value)
Berkeley DB (key-value)
3、滿足可用性,分區容忍性的系統,通常可能對一致性要求低一些,例如下面的產品:
Dynamo (key-value)
Voldemort (key-value)
Tokyo Cabinet (key-value)
KAI (key-value)
Cassandra (column-oriented/tabular)
CouchDB (document-oriented)
SimpleDB (document-oriented)
Riak (document-oriented)
參考資料: