CAP理論被很多人拿來作為分散式系統設計的金律，然而感覺大家對CAP這三個屬性的認識卻存在不少誤區，那麼什麼是CAP理論呢？CAP原本是一個猜想，2000年PODC大會的時候大牛Brewer提出的，他認為在設計一個大規模可擴放的網路服務時候會遇到三個特性：一致性（consistency）、可用性（Availability）、分割槽容錯（partition-tolerance）都需要的情景，然而這是不可能都實現的。之後在2003年的時候，Mit的Gilbert和Lynch就正式的證明了這三個特徵確實是不可以兼得的。
CAP是Consistency、Availablity和Partition-tolerance的縮寫。分別是指：
1）一致性（Consistency）：每次讀操作都能保證返回的是最新資料。也就是說所有的節點資料一致！
2）可用性（Availablity）：任何一個沒有發生故障的節點，會在合理的時間內返回一個正常的結果。也就是說一個或者多個節點失效，不影響服務請求！
3）分割槽容忍性（Partition-torlerance）：當節點間出現網路分割槽，照樣可以提供服務。也就是說節點間的網路連線失效，仍然可以處理請求！
其實，任何一個分散式系統，需要滿足這三個中的兩個。CAP理論指出：CAP三者只能取其二，不可兼得。其實這一點很好理解，理由如下：
1- 首先，單機都只能保證CP。
2- 有兩個或以上節點時，當網路分割槽發生時，叢集中兩個節點不能相互通訊（也就是說不能保證可用性A）。此時如果保證資料的一致性C，那麼必然會有一個節點被標記為不可用的狀態，違反了可用性A的要求，只能保證CP。
3- 反正，如果保證可用性A，即兩個節點可以繼續各自處理請求，那麼由於網路不通不能同步資料，必然又會導致資料的不一致，只能保證AP。
一、單例項
單機系統和顯然，只能保證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。選擇哪種方案，依據就是在特定場景下，究竟哪些特性是更加重要的了。