CAP理論被很多人拿來作為分布式系統設計的金律，然而感覺大家對CAP這三個屬性的認識卻存在不少誤區，那麽什麽是CAP理論呢？CAP原本是一個猜想，2000年PODC大會的時候大牛Brewer提出的，他認為在設計一個大規模可擴放的網絡服務時候會遇到三個特性：一致性（consistency）、可用性（Availability）、分區容錯（partition-tolerance）都需要的情景，然而這是不可能都實現的。之後在2003年的時候，Mit的Gilbert和Lynch就正式的證明了這三個特征確實是不可以兼得的。

CAP是Consistency、Availablity和Partition-tolerance的縮寫

其實，任何一個分布式系統，需要滿足這三個中的兩個。CAP理論指出：CAP三者只能取其二，不可兼得。其實這一點很好理解，理由如下：
1- 首先，單機都只能保證CP。
2- 有兩個或以上節點時，當網絡分區發生時，集群中兩個節點不能相互通信（也就是說不能保證可用性A）。此時如果保證數據的一致性C，那麽必然會有一個節點被標記為不可用的狀態，違反了可用性A的要求，只能保證CP。
3-

一、單實例
單機系統和顯然，只能保證CP，犧牲了可用性A。單機版的MySQL，Redis，MongoDB等數據庫都是這種模式。

實際中，我們需要一套可用性高的系統，即使部分機器掛掉之後仍然可以繼續提供服務。

二、多副本

相比於單實例，這裏多了一個節點去備份數據。
對於讀操作來說，因為可以訪問兩個節點中的任意一個，所以可用性提升。

對於寫操作來說，根據更新策略分為三種情況：
1）同步更新：即寫操作需要等待兩個節點都更新成功才返回。這樣的話如果一旦發生網絡分區故障，寫操作便不可用，犧牲了A。
2）異步更新：即寫操作直接返回，不需要等待節點更新成功，節點異步地去更新數據（FastDFS文件系統的存儲節點就是用這種方式，寫完一份數據之後立即返回結果，副本數據由同步線程寫入其他同group的節點）。這種方式，犧牲了C來保證A，即無法保證數據是否更新成功，還有可能會由於網絡故障等原因，導致數據不一致。
3）折衷：更新部分節點成功後便返回。

三、分片

相比於單實例，這裏多了一個節點去分割數據。
由於所有數據只有一份，一致性得以保證；節點間不需要通信，分區容忍性也有。
然而，當任意一個節點掛掉，丟失了一部分的數據，系統可用性得不到保證。

綜上，這和單機版的方案一樣，都只能保證CP。

那麽，有哪些好處呢？
1）某個節點掛掉只會影響部分服務，即服務降級；
2）由於分片了數據，可以均衡負載；
3）數據量增大/減小後可以相應的擴容/縮容。

大多數的數據庫服務都提供了分片的功能。如Redis的slots，Cassandra的patitions，MongoDB的shards等。
基於分片解決了數據量大的問題，可是我們還是希望我們的系統是高可用的，那麽，如何犧牲一定的一致性去保證可用性呢？

四、集群

可以看到，上面這種方式綜合了前兩種方式。同上分析，采用不同的數據同步策略，系統CAP保證各有不同。不過，一般數據庫系統都會提供可選的配置，我們根據不同的場景選擇不同的特性。
其實，對於大多數的非金融類互聯網公司，要求並非強一致性，而是可用性和最終一致性的保證。這也是NoSQL流行於互聯網應用的一大原因，相比於強一致性系統的ACID原則，它更加傾向於BASE：
- Basically Available：基本可用性，即允許分區失敗，除了問題僅服務降級；
- Soft-state：軟狀態，即允許異步；
- Eventual Consistency：最終一致性，允許數據最終一致性，而不是時刻一直。

五、總結
基本上，上面討論的幾種方式已經涵蓋了大多數的分布式存儲系統了。
其實對於大規模分布式系統來說，CAP是非常穩固的，可以擴展的地方也不多。
它很大程度上限制了大規模計算的能力，通過一些設計方式來繞過CAP管轄的區域或許是下一步大規模系統設計的關鍵。
可以看到，這些個方案總是需要通過犧牲一部分去換取另一部分，總沒法達到100%的CAP。選擇哪種方案，依據就是在特定場景下，究竟哪些特性是更加重要的了。

Linux下分布式系統以及CAP理論分析