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