分布式系統中的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 - 滿足可用性，磁區容忍性的系統，通常可能對一致性要求低一些，