CAP是Consistency、Availablity和Partition-tolerance的縮寫。分別指:
1.一致性(Consistency):每次讀操作都能保證返回的是最新數據;
2.可用性(Availablity):任何一個沒有發生故障的節點,會在合理的時間內返回一個正常的結果;
3.分區容忍性(Partition-tolerance):當節點間出現網絡分區,照樣可以提供服務。
CAP理論指出:CAP三者只能取其二,不可兼得。其實這一點很好理解:
-
有兩個或以上節點時,當網絡分區發生時,集群中兩個節點不能互相通信。此時如果保證數據的一致性C,那么必然會有一個節點被標記為不可用的狀態,違反了可用性A的要求,只能保證CP;
-
反之,如果保證可用性A,即兩個節點可以繼續各自處理請求,那么由于網絡不通不能同步數據,必然又會導致數據的不一致,只能保證AP。
一、單實例
單機系統很顯然,只能保證CP,犧牲了可用性A。單機版的MySQL、Redis、MongoDB等數據庫都是這種模式。
實際中,我們需要一套可用性高的系統,即使部分機器掛掉之后仍然可以繼續提供服務。
二、多副本
相比于單實例,這里多了一個節點去備份數據。
對于讀操作來說,因為可以訪問兩個節點中的任意一個,所以可用性提升。
對于寫操作來說,根據更新策略分為三種情況:
1.同步更新:即寫操作需要等待兩個節點都更新成功才返回。這樣的話如果一旦發生網絡分區故障,寫操作便不可用,犧牲了A;
2.異步更新:即寫操作直接返回,不需要等待節點更新成功,節點異步地去更新數據。
3.這種方式,犧牲了C來保證A。即無法保證數據是否更新成功,還有可能會由于網絡故障等原因,導致數據不一致。
折衷:更新部分節點成功后便返回。
這里,先介紹下類Dynamo系統用于控制分布式存儲系統中的一致性級別的策略——NWR:
當W+R>N時,由于讀寫操作覆蓋到的副本集肯定會有交集,讀操作只要比較副本集數據的修改時間或者版本號即可選出最新的,所以系統是強一致性的;
反之,當W+R<=N時是弱一致性的。
如:(N,W,R)=(1,1,1)為單機系統,是強一致性的;(N,W,R)=(2,1,1)為常見的master-slave模式,是弱一致性的。
舉例:
-
如像Cassandra中的折衷型方案QUORUM,只要超過半數的節點更新成功便返回,讀取時返回多數副本的一致的值。然后,對于不一致的副本,可以通過read repair的方式解決。
read repair:讀取某條數據時,查詢所有副本中的這條數據,比較數據與大多數副本的最新數據是否一致,若否,則進行一致性修復。
其中,W+R>N,故而是強一致性的。
-
又如Redis的master-slave模式,更新成功一個節點即返回,其他節點異步地去備份數據。這種方式只保證了最終一致性。
最終一致性:相比于數據時刻保持一致的強一致性,最終一致性允許某段時間內數據不一致。但是隨著時間的增長,數據最終會到達一致的狀態。
其中,W+R< N,所以只能保證最終一致性。
此外,N越大,數據可靠性越好。但是由于W或R越大,寫或讀開銷越大,性能越差,所以一般需要綜合考慮一致性、可用性和讀寫性能,設置 W、R 都為 N/2 + 1。
其實,折衷方案和異步更新的方式從本質上來說是一樣的,都是損失一定的C來換取A的提高。而且,會產生‘腦裂’的問題——即網絡分區時節點各自處理請求,無法同步數據,當網絡恢復時,導致不一致。
一般的,數據庫都會提供分區恢復的解決方案:
1.從源頭解決:如設定節點通信的超時時間,超時后“少數派”節點不提供服務。這樣便不會出現數據不一致的情況,不過可用性降低;
2.從恢復解決:如在通信恢復時,對不同節點的數據進行比較、合并,這樣可用性得到了保證。但是在恢復完成之前,數據是不一致的,而且可能出現數據沖突。
光這樣還不夠,當數據量較大時,由于一臺機器的資源有限并不能容納所有的數據,我們會想把數據分到好幾臺機器上存儲。
三、分片
相比于單實例,這里多了一個節點去分割數據。
由于所有數據都只有一份,一致性得以保證;節點間不需要通信,分區容忍性也有。
然而,當任意一個節點掛掉,丟失了一部分的數據,系統可用性得不到保證。
綜上,這和單機版的方案一樣,都只能保證CP。
那么,有那些好處呢?
1.某個節點掛掉只會影響部分服務,即服務降級;
2.由于分片了數據,可以均衡負載;
3.數據量增大/減小后可以相應地擴容/縮容。
大多數的數據庫服務都提供了分片的功能。如Redis的slots、Cassandra的partitions、MongoDB的shards等。
基于分片解決了數據量大的問題,可是我們還是希望我們的系統是高可用的,那么,如何犧牲一定的一致性去保證可用性呢?
四、集群
可以看到,上面這種方式綜合了前兩種方式。同上分析,采用不同的數據同步策略,系統的CAP保證各有不同。不過,一般數據庫系統都會提供可選的配置,我們根據不同的場景選擇不同的策略以實現不同的特性。
其實,對于大多數的非金融類互聯網公司,要求并非強一致性,而是可用性和最終一致性的保證。這也是NoSQL流行于互聯網應用的一大原因,相比于強一致性系統的ACID原則,它更加傾向于BASE:
-
Basically Available: 基本可用,即允許分區失敗,出了問題僅服務降級;
-
Eventual Consistency: 最終一致性,允許數據最終一致,而不是時刻一致。
五、總結
基本上,上面討論的幾種方式已經涵蓋了大多數的分布式存儲系統了。我們可以看到,這些個方案總是需要通過犧牲一部分去換取另一部分,總沒法達到100%的CAP。
選擇哪種方案,依據就是在特定場景下,究竟哪些特性是更加重要的了。
核心關注:拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理,全面涵蓋了企業關注ERP管理系統的核心領域,是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處:拓步ERP資訊網http://www.guhuozai8.cn/
本文標題:關于分布式系統的思考(一)
本文網址:http://www.guhuozai8.cn/html/solutions/14019320016.html