分散式設計理論之CAP

什麼是分散式系統

拿一個最簡單的例子，就比如說我們的圖書管理系統。之前的系統包含了所有功能，比如使用者註冊登入、管理員功能、圖書借閱管理等。這叫做集中式系統。也就是一個人幹了好幾件事。

後來隨著功能的增多，使用者量也越來越大。集中式系統維護太麻煩，擴充性也不好。於是就考慮著把這些功能分開。通俗的理解就是原本需要一個人乾的事，現在分給n個人幹，各自幹各自的，最終取得和一個人乾的效果一樣。

稍微正規一點的定義就是：一個業務分拆多個子業務，部署在不同的伺服器上。然後透過一定的通訊協議，能夠讓這些子業務之間相互通訊。

既然分給了n個人，那就涉及到這些人的溝通交流協作問題。想要去解決這些問題，就需要先聊聊分散式系統中的CAP理論。千萬不要被這個看起來高大上的概念迷惑住。

CAP是什麼

CAP定理（CAP theorem）,又被稱作布魯爾定理（Brewer’s theorem）,指的是在一個分散式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分割槽容錯性）這三個基本需求，最多隻能同時滿足其中的2個。

CAP的每個單項含義：

• Consistency（一致性）：指資料在多個副本之間能夠保持一致的特性,一般特指寫操作之後的讀操作，必須返回該值。舉例來說，某條記錄是 v0，使用者向 G1 伺服器發起了一個寫操作，將其改為 v1，那麼後續讀取出來的值應該是v1而不是v0。
• Availability（可用性）：指系統提供的服務必須一直處於可用的狀態，每次請求都能獲取到非錯的響應，但是不保證獲取的資料是最新的資料。
• Partition tolerance（分割槽容錯性）：分散式系統在遇到任何網路分割槽故障的時候，仍然能夠對外提供滿足一致性和可用性的服務，除非整個網路環境都發生了故障。

理解CAP理論的最簡單方式是想象兩個節點分處分割槽兩側:允許至少一個節點更新狀態會導致資料不一致，即喪失了C性質。如果為了保證資料一致性，將分割槽一側的節點設定為不可用，那麼又喪失了A性質。除非兩個節點可以互相通訊，才能既保證C又保證A，這又會導致喪失P性質。

論證CAP定理

通常來說，分割槽容錯是無法避免的，因此可以認CA的P總是成立。CAP定理告訴我們，剩下的C和A無法同時做到，下面是一個詳細的推論過程來展示CA之間的矛盾。

網路中有兩個節點N1和N2，可以簡單的理解N1和N2分別是兩臺計算機，他們之間網路可以連通，N1中有一個應用程式A，和一個資料庫V，N2也有一個應用程式B和一個資料庫V。現在，A和B是分散式系統的兩個部分，V是分散式系統資料儲存的兩個子資料庫。

• 在滿足一致性的時候，N1和N2中的資料是一樣的，V0=V0。
• 在滿足可用性的時候，使用者不管是請求N1或者N2，都會得到立即響應。
• 在滿足分割槽容錯性的情況下，N1和N2有任何一方當機，或者網路不通的時候，都不會影響N1和N2彼此之間的正常運作。

此時假設使用者向N1機器請求資料更新，程式A更新資料庫V0為V1。分散式系統將資料進行同步操作M，將V1同步到N2中V0，使得N2中的資料V0也更新為V1，N2中的資料再響應N2的請求。

根據CAP原則定義，系統的一致性、可用性和分割槽容錯性細分如下：

• 一致性：N1和N2的資料庫V之間的資料是否完全一樣。
• 可用性：N1和N2對外部的請求能否做出正常的響應。
• 分割槽容錯性：N1和N2之間的網路是否互通。

這是正常運作的場景，也是理想的場景。作為一個分散式系統，它和單機系統的最大區別，就在於網路。現在假設一種極端情況，N1和N2之間的網路斷開了，我們要支援這種網路異常。相當於要滿足分割槽容錯性，能不能同時滿足一致性和可用性呢？還是說要對他們進行取捨？

假設在N1和N2之間網路斷開的時候，有使用者向N1傳送資料更新請求，那N1中的資料V0將被更新為V1。由於網路是斷開的，所以分散式系統同步操作M無法進行，所以N2中的資料依舊是V0。這個時候，有使用者向N2傳送資料讀取請求，由於資料還沒有進行同步，應用程式沒辦法立即給使用者返回最新的資料V1，怎麼辦呢？這裡就有兩種選擇：

• 犧牲資料一致性，保證可用性。響應舊的資料V0給使用者。
• 犧牲可用性，保證資料一致性。阻塞等待，直到網路連線恢復，資料更新操作M完成之後，再給使用者響應最新的資料V1。

CAP原理的應用

網際網路場景：

對於多數大型網際網路應用的場景，主機眾多、部署分散，而且現在的叢集規模越來越大，所以節點故障、網路故障是常態，而且要保證服務可用性達到N個9，即保證P和A，捨棄C（退而求其次保證最終一致性）。雖然某些地方會影響客戶體驗，但沒達到造成使用者流失的嚴重程度。

對於涉及到錢財這樣不能有一絲讓步的場景，C必須保證。網路發生故障寧可停止服務（或者只讀不寫），這是保證CA，捨棄P

資料庫領域：

依據CAP理論，從應用的需求不同，我們選型資料庫時，可以從三方面考慮：

• 考慮CA，這就是傳統上的關係型資料庫(RMDB)
• 考慮CP，主要是一些Key-value資料庫，典型代表為google的Big Table
• 考慮AP，主要是一些面向文件的適用於分散式系統的資料庫，如SimpleDB

下面是一張流傳非常廣泛的圖，它展示了按照CAP中三選二對資料庫系統的分類：