分散式系統中的CAP理論
一、什麼是分散式系統
拿一個最簡單的例子，就比如說我們的圖書管理系統。之前的系統包含了所有的功能，比如使用者註冊登入、管理員功能、圖書借閱管理等。這叫做集中式系統。也就是一個人幹了好幾件事。
後來隨著功能的增多，使用者量也越來越大。集中式系統維護太麻煩，拓展性也不好。於是就考慮著把這些功能分開。通俗的理解就是原本需要一個人乾的事，現在分給n個人幹，各自幹各自的，最終取得和一個人乾的效果一樣。
稍微正規一點的定義就是：一個業務分拆多個子業務，部署在不同的伺服器上。 然後通過一定的通訊協定，能夠讓這些子業務之間相互通訊。
既然分給了n個人，那就涉及到這些人的溝通交流共同作業問題。想要去解決這些問題，就需要先聊聊分散式系統中的CAP理論。千萬不要被這個看起來高大上的概念迷惑住。
二、簡單的概述一下
CAP理論指的是一個分散式系統最多隻能同時滿足一致性（Consistency）、可用性（Availability）和分割區容錯性（Partition tolerance）這三項中的兩項。拿一個網上的圖來看看。
這張圖不知道你之前看到過沒，如果你看過書或者是視訊，這張圖應該被列舉了好幾遍了。下面我不準備直接上來就對每一個特性進行概述。我們先從案例出發逐步過渡。
1、一個小例子
首先我們看一張圖。
現在網路中有兩個節點N1和N2，他們之間網路可以連通，N1中有一個應用程式A，和一個資料庫V，N2也有一個應用程式B2和一個資料庫V。現在，A和B是分散式系統的兩個部分，V是分散式系統的兩個子資料庫。
現在問題來了。突然有兩個使用者小明和小華分別同時存取了N1和N2。我們理想中的操作是下面這樣的。
（1）小明存取N1節點，小華存取N2節點。同時存取的。
（2）小明把N1節點的資料V0變成了V1。
（2）N1節點一看自己的資料有變化，立馬執行M操作，告訴了N2節點。
（4）小華讀取到的就是最新的資料。也是正確的資料。
上面這是一種最理想的情景。它滿足了CAP理論的三個特性。現在我們看看如何來理解滿足的這三個特性。
2、Consistency 一致性
一致性指的是所有節點在同一時間的資料完全一致。就好比剛剛舉得例子中，小明和小華讀取的都是正確的資料，對他們使用者來說，就好像是操作了同一個資料庫的同一個資料一樣。
因此對於一致性，也可以分為從使用者端和伺服器端兩個不同的視角來理解。
（1）使用者端
從使用者端來看，一致性主要指的是多並行存取時更新過的資料如何獲取的問題。也就是小明和小華同時存取，如何獲取更新的最新的資料。
（2）伺服器端
從伺服器端來看，則是更新如何分佈到整個系統，以保證資料最終一致。也就是N1節點和N2節點如何通訊保持資料的一致。
對於一致性，一致的程度不同大體可以分為強、弱、最終一致性三類。
（1）強一致性
對於關係型資料庫，要求更新過的資料能被後續的存取都能看到，這是強一致性。比如小明更新V0到V1，那麼小華讀取的時候也應該是V1。
（2）弱一致性
如果能容忍後續的部分或者全部存取不到，則是弱一致性。比如小明更新VO到V1，可以容忍那麼小華讀取的時候是V0。
（3）最終一致性
如果經過一段時間後要求能存取到更新後的資料，則是最終一致性。比如小明更新VO到V1，可以使得小華在一段時間之後讀取的時候是V0。
3、可用性
可用性指服務一直可用，而且是正常響應時間。就好比剛剛的N1和N2節點，不管什麼時候存取，都可以正常的獲取資料值。而不會出現問題。好的可用性主要是指系統能夠很好的為使用者服務，不出現使用者操作失敗或者存取超時等使用者體驗不好的情況。
對於可用性來說就比較好理解了。
4、分割區容錯性
分割區容錯性指在遇到某節點或網路分割區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。就好比是N1節點和N2節點出現故障，但是依然可以很好地對外提供服務。
這個分割區容錯性也是很好理解。
在經過上面的分析中，在理想情況下，沒有出現任何錯誤的時候，這三條應該都是滿足的。但是天有不測風雲。系統總是會出現各種各樣的問題。下面來分析一下為什麼說CAP理論只能滿足兩條。
三、驗證CAP理論
既然系統總是會有錯誤，那我們就來看看可能會出現什麼錯誤。
N1節點更新了V0到V1，想在也想把這個訊息通過M操作告訴N1節點，卻發生了網路故障。這時候小明和小華都要同時存取這個資料，怎麼辦呢？現在我們依然想要我們的系統具有CAP三個特性，我們分析一下會發生什麼。
（1）系統網路發生了故障，但是系統依然可以存取，因此具有容錯性。
（2）小明在存取節點N1的時候更改了V0到V1，想要小華存取節點N2的V資料庫的時候是V1，因此需要等網路故障恢復，將N2節點的資料庫進行更新才可以。
（3）在網路故障恢復的這段時間內，想要系統滿足可用性，是不可能的。因為可用性要求隨時隨地存取系統都是正確有效的。這就出現了矛盾。
正是這個矛盾所以CAP三個特性肯定不能同時滿足。既然不能滿足，那我們就進行取捨。
有兩種選擇：
（1）犧牲資料一致性，也就是小明看到的衣服數量是10，買了一件應該是9了。但是小華看到的依然是10。
（2）犧牲可用性，也就是小明看到的衣服數量是10，買了一件應該是9了。但是小華想要獲取的最新的資料的話，那就一直等待阻塞，一直到網路故障恢復。
現在你可以看到了CAP三個特性肯定是不能同時滿足的，但是可以滿足其中兩個。
四、CAP特性的取捨
我們分析一下既然可以滿足兩個，那麼捨棄哪一個比較好呢？
（1）滿足CA捨棄P，也就是滿足一致性和可用性，捨棄容錯性。但是這也就意味著你的系統不是分散式的了，因為涉及分散式的想法就是把功能分開，部署到不同的機器上。
（2）滿足CP捨棄A，也就是滿足一致性和容錯性，捨棄可用性。如果你的系統允許有段時間的存取失效等問題，這個是可以滿足的。就好比多個人並行買票，後臺網路出現故障，你買的時候系統就崩潰了。
（3）滿足AP捨棄C，也就是滿足可用性和容錯性，捨棄一致性。這也就是意味著你的系統在並行存取的時候可能會出現資料不一致的情況。
實時證明，大多數都是犧牲了一致性。像12306還有淘寶網，就好比是你買火車票，本來你看到的是還有一張票，其實在這個時刻已經被買走了，你填好了資訊準備買的時候發現系統提示你沒票了。這就是犧牲了一致性。
但是不是說犧牲一致性一定是最好的。就好比mysql中的事務機制，張三給李四轉了100塊錢，這時候必須保證張三的賬戶上少了100，李四的賬戶多了100。因此需要資料的一致性，而且什麼時候轉錢都可以，也需要可用性。但是可以轉錢失敗是可以允許的。
五、CAP三進二
在分散式系統中，講究C:Consistency(強一致性)、A:Availability(可用性)、P:Partition tolerance(分割區容錯性)
CAP的證明基於非同步網路，非同步網路也是反映了真實網路中情況的模型。真實的網路系統中，節點之間不可能保持 同步，即便是時鐘也不可能保持同步，所有的節點依靠獲得的訊息來進行本地計算和通訊。這個概念其實是相當強 的，意味著任何超時判斷也是不可能的，因為沒有共同的時間標準。之後我們會擴充套件CAP的證明到弱一點的非同步網 絡中，這個網路中時鐘不完全一致，但是時鐘執行的步調是一致的，這種系統是允許節點做超時判斷的。
CAP的證明很簡單，假設兩個節點集{G1, G2}，由於網路分片導致G1和G2之間所有的通訊都斷開了，如果不滿足 P，則整個網路不可用，如果在G1中寫，在G2中讀剛寫的資料， G2中返回的值不可能G1中的寫值。由於A的要 求，G2一定要返回這次讀請求，由於P的存在，導致C一定是不可滿足的。
CAP理論就是說在分散式儲存系統中，最多隻能實現上面的兩點。 而由於當前的網路硬體肯定會出現延遲丟包等問 題，所以
分割區容忍性是我們必須需要實現的。
所以我們只能在一致性和可用性之間進行權衡，沒有任何分散式系統能同時保證這三點。
C:強一致性 A:高可用性 P:分散式容忍性
CA 傳統Oracle資料庫
AP 大多數網站架構的選擇
CP Redis、Mongodb
注意:分散式架構的時候必須做出取捨。 一致性和可用性之間取一個平衡。大多數web應用，其實並不需要 強一致性。
因此犧牲C換取P，這是目前分散式資料庫產品的方向
一致性與可用性的決擇
資料庫事務一致性需求 很多web實時系統並不要求嚴格的資料庫事務，對讀一致性的要求很低， 有些場合對寫一 致性要求並不高。允許實現最終一致性。
資料庫的寫實時性和讀實時性需求 對關聯式資料庫來說，插入一條資料之後立刻查詢，是肯定可以讀出來這條資料 的，但是對於很多web應用來說，並不要求這麼高的實時性，比方說發一條訊息之 後，過幾秒乃至十幾秒之後，我 的訂閱者才看到這條動態是完全可以接受的。對複雜的SQL查詢，特別是多表關聯查詢的需求 任何巨量資料量的web系統，都非常忌諱多個大表的關聯查詢，以 及複雜的資料分析型別的報表查詢，特別是SNS型別的網站，從需求以及產品設計角 度，就避免了這種情況的產 生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
CAP理論的核心是:一個分散式系統不可能同時很好的滿足一致性，可用性和分割區容錯性這三個需求， 最多隻能同 時較好的滿足兩個。 因此，根據 CAP 原理將 NoSQL 資料庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類:
CA - 單點叢集，滿足一致性，可用性的系統，通常在可延伸性上不太強大。
CP - 滿足一致性，分割區容忍必的系統，通常效能不是特別高。
AP - 滿足可用性，分割區容忍性的系統，通常可能對一致性要求低一些。