分散式系統詳解--基礎知識（CAP）
分散式系統詳解--基礎知識（CAP）
前面呢，文章寫到了 分散式系統詳解--基礎知識（通訊），在RPC中看到通訊為題的重要性，但是分散式系統當中又要牽扯到另外一個地方，就是資料的一致性（Consistency）、可用性（Availability）和容錯性（Partition tolerance）。那這三個問題能夠解決麼，怎麼解決的呢？那我們這篇文章就說一下CAP他們之間的"愛恨情仇~~"。
一、CAP定理圖
那我們詳細來介紹一下CAP。
1.1 CAP理論 的來歷
CAP呢，是按照美國著名科學家 Eric Brewer 在 2000 年提出的理論，當技術架構從集中式架構向分散式架構演進，會遇到 “CAP 定律”的瓶頸。我們可以從上面的圖中看出的是，可用性、一致性和分割槽容錯性，資料處理系統不能同時滿足。那為什麼不能滿足呢？這三個名詞又是具體的代表哪一些含義呢？
二、 CAP-Consistency（一致性）
2.1 一致性定義
在分散式系統中的所有資料備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的資料副本）
2.2 一致性模型
讓我們來看看維基百科上關於一致性模型用於分散式系統的幾個一致性模型的型別。 參考網址 如下 請點選：
一致性模型。https://en.wikipedia.org/wiki/Consistency_model#Relaxed_Memory_Consistency_Models
其實，一致性模型是資料和程序之間的一個約定。一般情況下，一個數據項上執行讀操作時，它期待該操作返回的是該資料在其最後一次操作之後的結果。在沒有全域性時鐘的情況下，精確的定義哪一次操作是最後一次操作是非常困難的。所以就有了一系列的一致性模型。
假設出現以下情況：
- 行X在節點M和N上覆制
- 客戶端A將行X寫入節點M.
- 在一段時間t之後，客戶端B從節點N讀取行X.
一致性模型必須確定客戶端B是否看到來自客戶端A的寫入。
主備份協議示例
當客戶端請求寫入時，寫入請求將轉發到主伺服器。主伺服器向備份傳送請求以執行更新。然後，伺服器從所有備份接收更新確認，並將寫入完成確認傳送給客戶端。任何客戶端都可以在本地讀取上次可用的更新 此協議的權衡是傳送更新請求的客戶端可能需要等待很長時間才能獲得確認才能繼續。可以通過在本地執行更新來解決此問題，然後請求其他備份執行其更新。非阻塞主備份協議不保證所有備份伺服器上的更新一致性。然而，它提高了效能。在主備份協議中，所有程序都將看到相同的寫入操作順序，因為此協議根據全域性唯一時間對所有傳入寫入進行排序。阻塞協議保證程序檢視上次寫操作的結果。
主備份協議（本地寫入）的示例
主備份協議（本地寫入）的示例，要更新資料項，程序首先將其移動到其位置。結果，在該方法中，可以在本地執行連續的寫操作，同時每個程序可以讀取它們的資料項的本地副本。主資料庫完成更新後，更新將轉發到其他副本，並且所有副本都在本地執行更新。這種非阻塞方法可以帶來改進。本地寫協議的圖表描述了基於主協議的本地寫入方法。程序請求資料項x中的寫操作。當前伺服器被視為資料項x的新主要伺服器。執行寫操作，當請求完成時，主伺服器向其他備份伺服器傳送更新請求。
三、 CAP-Availability（可用性）
3.1 可用性定義
每次請求都能獲取到非錯的響應——但是不保證獲取的資料為最新資料。在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。
3.2 可用性舉例
一個一週裡（168小時）有100小時可用的單元的可用性為100/168。可用性的值通常用小數來表示（如0.9998）。在高可用性的應用中，使用一個被稱為幾個九的度量，對應小數點後9的個數。在這個系統中，“五個九”相當於0.99999（或者99.999%）的可用性。
返回結果，是可用性的一個重要指標，他要求系統請求後，返回一個正常相應結果。正常的相應結果通常能夠明確的反映出對請求的處理結果，即成功或失敗。
四、 CAP-Partition tolerance（分割槽容錯性）
分割槽容錯性其實是約束了分散式系統需要具有如下的特性：分散式在遇到任何網路分割槽故障的時候，仍然需要保證對外提供滿足一致性和可用性的服務，除非整個網路均已癱瘓。也就是說，它容忍錯誤的出現，在發生錯誤的情況下可以繼續進行操作。
網路分割槽是指的在分散式系統當中，不同的節點分佈在不同的子網路中，由於出現了一些故障導致自網路之間不能正常的進行連通，但是他們又是各自是正常的。這就導致了一種情況，整個網路變成了若干個孤立的區域。當然值得注意的是組成分散式系統的每個節點的進入和退出可以看作是一個特殊的網路區域。
五、CAP-愛恨情仇（為什麼不能同時保證）
既然是分散式系統，我們來想象兩個節點。如果說至少允許一個節點更新狀態會導致資料不一致，那麼這個時候就會導致“C-一致性”的缺失。如果要保證資料的一致性，那麼將分割槽一側的節點設定為不可用，那麼就會導致“A-可用性”的喪失。那麼如何保證A-C都可以呢？就是兩個節點相互通訊，然而這個時候就會導致P的喪失，而P又是不可或缺的，所以就導致了一個比較尷尬的事件的出現~~
六、CAP延伸版--BASE
架構師Dan Pritchett源於對大規模分散式系統的實踐總結，在ACM上發表文章提出BASE理論，BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用可以採用適合的方式達到最終一致性（Eventual Consitency）。
BASE是指基本可用（Basically Available）、軟狀態（ Soft State）、最終一致性（ Eventual Consistency）。
（1）基本可用（Basically Available）
基本可用是指分散式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。
電商大促時，為了應對訪問量激增，部分使用者可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現。
（2）軟狀態（ Soft State）
軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分散式儲存中一般一份資料至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。mysql replication的非同步複製也是一種體現。
（3）最終一致性（ Eventual Consistency）
最終一致性是指系統中的所有資料副本經過一定時間後，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。
後文BASE參考 分散式系統的BASE理論。
歡迎訂閱關注公眾號（JAVA和人工智慧）
獲取更多免費書籍、資源、視訊資料
文章回顧連結：