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