今天，本文的主角是CAP理論。在我開始闡述自己關於CAP理論的見解之前，首先要宣告一點：CAP理論關注的側重點是資料，不是系統，不是系統，不是系統。

集中式系統與分散式系統

在網際網路行業的發展過程中，很多網站、服務都會經歷由最初簡單的集中式系統，到後來複雜的分散式系統的過程。

那麼，什麼是集中式系統，什麼又是分散式系統呢？

在網路的拓撲結構中，每一臺伺服器都是一個服務節點。而整個應用則包含了多臺伺服器，正是這若干個伺服器節點組成了整個對外服務的應用。

集中式系統與分散式系統

實際的網路結構遠比圖示覆雜，這裡為了更好地講解，進行了簡化處理

如圖所示，集中式系統中資料庫伺服器節點只有一臺，而當資料進行訪問、更新操作時都是同一節點，能夠保證資料的一致性（資料庫本身支援事務，事務也具有ACID特性）。

思考一個問題：有了集中式系統，為什麼又需要分散式系統？

集中式系統的主要優點：

配置簡單、容易維護管理資料不會出現不一致性問題

集中式系統的主要缺點：

單機硬體資源有限，資料儲存有上限問題單機對外服務提供的訪問量有限存在單點故障問題

向上擴容與水平擴容

如今高速發展的網際網路行業，稍具規模的公司資料量最少是上TB級別（不然都不好意思說自己是大型公司）。

對於這麼大的資料量儲存與維護來說，如果使用集中式的單機服務，則意味著需要向上擴容（使用最好的CPU、最大的記憶體、最好的硬碟），而向上擴容也會有一定的上限（舉個例子：伺服器如果使用32位作業系統，系統能夠識別的最大記憶體為4G，即使安裝8G記憶體條，也是浪費。網絡卡也有一定的頻寬上限等等），成本很高（越大的記憶體、越快的固態硬碟價格越高昂）。

沒有什麼問題能難倒這群整天在寫bug的最可愛的人，既然向上擴容存不行，那麼就來個水平擴容。

水平擴容，用一句通俗的話講就是堆積機器。

如果相同的預算，有兩套方案：

向上擴容水平擴容

最終的結果，絕對是水平擴容能夠對外提供的訪問請求量更大。

有了水平擴容就出現了分散式系統，原來業務只需要部署到一臺伺服器節點上，現在則需要部署到多臺節點上。

與集中式系統相比，還拿資料庫還說，分散式系統中資料庫伺服器節點有多臺，進行的資料訪問、更新操作會隨機地落到某一臺節點。為了保證資料在某一臺節點上更新之後，能夠在另外一臺節點上訪問到，就需要進行資料同步操作。

那麼分散式系統的問題又來了，如何同步？同步失敗怎麼辦？

分散式系統的主要優點：

理論上可以無限水平擴容，儲存更多資料可以提供更多服務請求資料備份、容災

分散式系統的主要缺點：

網路拓撲結構複雜，維護管理複雜度高資料需要在不同節點之間進行同步，同時存在同步失敗的風險資料不能在同一時刻在所有節點保持一致，存在不一致性問題

大名鼎鼎的CAP

面對集中式系統與分散式系統的上述問題，2000 年 Eric Brewer 教授提出CAP猜想。2年後，Seth Gilbert 和 Nancy Lynch 從理論上證明了猜想的可能性。從此，CAP 理論正式在學術上成為了分散式計算領域的公認定理，並深深地影響了分散式計算的發展。

一致性（C）：分散式系統中的所有資料節點，在同一時刻是否有同樣的值（等同於所有節點訪問同一份最新的資料副本）。

可用性（A）：保證每個請求不管成功或者失敗都有響應。

分割槽容忍性（P）：各個節點資料不能在一定的時間內達到一致性，就認為出現了分割槽。分割槽容忍性就是在系統中任意資訊的丟失或失敗不會影響系統的繼續運作。

CAP

遺憾的是，網路進行資料傳輸時由於資料一定會存在丟失、延遲問題（P），在分散式系統中無法同時得到這三個特性，而P是一定要選的，那麼存在的選項只剩下兩個了：CP、AP。

CP：滿足一致性和容錯性，捨棄可用性。

也就是說，如果在某一節點對某一條資料進行更新，此時在其他節點有使用者訪問了該資料，使用者的訪問會出現阻塞、錯誤等情況，直到該資料被同步到所有或者大於某些閾值的節點（想想實際生活中使用銀行類APP時的一些情況）。

AP：滿足可用性和容錯性，捨棄一致性。

也就是說，如果在某一節點對某一條資料進行了更新操作，在資料沒有被同步到其他所有節點之前，允許其他使用者訪問某些節點上該資料的舊值（想想實際生活中，搶火車票時，你看到有幾張剩餘的票，但是下單時卻提示沒有多餘票）。

CA：滿足一致性和可用性，捨棄分割槽容錯性。

此種情況就是拋棄了分散式系統，而選擇了集中式系統（單機資料庫就是個很好的例子）。

強一致性與最終一致性

雖然說資料一定會存在丟失、延遲問題，但是該問題也不是時刻存在發生的，在整個網路請求互動中只佔了很小一部分比例。

為了更新提供服務以及使用者體驗，大部分業務不需要絕對嚴格的資料強一致性，只需要做到最終一致性即可。這個時候又出現了另外一個理論BASE，BASE 理論可以看做是對CAP理論的補充。

基本可用（Basically Available）: 當整個系統出現了不可預知的故障，保證核心業務能夠對外提供服務，部分非核心服務可能會進行降級處理。

軟狀態（Soft State）：允許系統中的資料存在中間狀態，並認為該狀態不影響系統的整體可用性，即允許系統在多個不同節點的資料副本存在資料延時。

最終一致性（Eventually Consistent）：系統允許存在中間態，但是需要在一定的時間內透過某些手段達到最終一致性。這個時間期限取決於網路延時、系統負載、資料複製方案設計等等因素。

怎麼選擇

面對分散式系統，又是CAP，又是BASE。在實際的開發過程中，應該怎麼選擇？構建什麼樣的系統呢？

這裡需要提醒一點，還記得文章開始時說過的一句話嗎？CAP關注的是資料。至於如何選擇，要看這些資料對你的重要程度。

假如：現在做的是一個新聞、電商商品搜尋服務，完全可以選擇AP。

因為，使用者對這些資料的變更並不會太敏感，也允許存在一定時間的延遲，只要達到最終一致性即可（日常生活中，當你跟家人同時刷某一款APP時，絕對會發現顯示的內容會存在一定差別，但是會在很短時間內顯示一致）。

假如：現在要做的是一個銀行資金理財賬號系統，則需要謹慎地選擇CP。

因為，此時使用者對這些資料的變更會十分敏感，不允許出現一點差錯，但是有時候也會存在支付中這種中間態（比如今天理財在17:00:00點關閉，我在16:59:59購買理財，也提示我購買成功，但是第二天登入賬號時發現購買成功時間是昨天的17:00:01秒，中間差了一天的收益，這個怎麼算？當然，實際生活中，銀行轉賬時也可能會提示你轉賬會出現一定延遲之類的資訊）。面對CP，很多時候不是嚴格的強一致性，而是最終一致性，要看具體的業務與場景。

總結

業務場景千千變、玩法套路也不斷。但是，這一切都是構建在一定的理論基礎與框架之內。只有掌握了這些理論，在架構設計與實現的時候，才能夠更好的找到一套適合自己的方案。

今天講解了集中式系統、分散式系統、CAP理論、BASE理論，但是有一點需要再次說名一下，這些理論的側重點都是資料。在設計架構時，需要根據資料的重要性，來選擇架構。而不是先設計架構，然後在架構裡面設計方案來滿足資料的要求。