在討論常見架構前，先簡單了解下CAP理論：
CAP是Consistency、Availablity和Partition-tolerance的縮寫。分別指：
1.一致性（Consistency）：每次讀操作都能保證返回的是最新數據；
2.可用性（Availablity）：任何一個沒有發生故障的節點，會在合理的時間內返回一個正常的結果；
3.分區容忍性（Partition-tolerance）：當節點間出現網絡分區，照樣可以提供服務。
CAP理論指出：CAP三者只能取其二，不可兼得。其實這一點很好理解：
- 首先，單機系統都只能保證CP；
- 有兩個或以上節點時，當網絡分區發生時，集群中兩個節點不能互相通信。此時如果保證數據的一致性C，那么必然會有一個節點被標記為不可用的狀態，違反了可用性A的要求，只能保證CP；
- 反之，如果保證可用性A，即兩個節點可以繼續各自處理請求，那么由于網絡不通不能同步數據，必然又會導致數據的不一致，只能保證AP。
一、單實例
單機系統很顯然，只能保證CP，犧牲了可用性A。單機版的MySQL、Redis、MongoDB等數據庫都是這種模式。
實際中，我們需要一套可用性高的系統，即使部分機器掛掉之后仍然可以繼續提供服務。
二、多副本
相比于單實例，這里多了一個節點去備份數據。
對于讀操作來說，因為可以訪問兩個節點中的任意一個，所以可用性提升。
對于寫操作來說，根據更新策略分為三種情況：
1.同步更新：即寫操作需要等待兩個節點都更新成功才返回。這樣的話如果一旦發生網絡分區故障，寫操作便不可用，犧牲了A；
2.異步更新：即寫操作直接返回，不需要等待節點更新成功，節點異步地去更新數據。
3.這種方式，犧牲了C來保證A。即無法保證數據是否更新成功，還有可能會由于網絡故障等原因，導致數據不一致。
折衷：更新部分節點成功后便返回。
這里，先介紹下類Dynamo系統用于控制分布式存儲系統中的一致性級別的策略——NWR：
- N：同一份數據的副本個數
- W：寫操作需要確保成功的副本個數
- R：讀操作需要讀取的副本個數
當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： 基本可用，即允許分區失敗，出了問題僅服務降級；
- Soft-state： 軟狀態，即允許異步；
- Eventual Consistency： 最終一致性，允許數據最終一致，而不是時刻一致。
五、總結
基本上，上面討論的幾種方式已經涵蓋了大多數的分布式存儲系統了。我們可以看到，這些個方案總是需要通過犧牲一部分去換取另一部分，總沒法達到100%的CAP。
選擇哪種方案，依據就是在特定場景下，究竟哪些特性是更加重要的了。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：關于分布式系統的思考（一）
本文網址：http://www.guhuozai8.cn/html/solutions/14019320016.html
相關文章
