談及分散式，必然談到 CAP， CAP 已經是被說爛了的一個 話題， 繞不開， 逃不掉。  而且， 理解起來 會有些吃力。

分散式的CAP理論告訴我們 “任何一個分散式系統都無法同時滿足 一致性（Consistency）、可用性（Availability）和分割槽容錯性（Partition tolerance），最多隻能同時滿足兩項。”

 

這樣的表述， 仍然是難以理解， 說了跟沒說差不多。看看其他的說明。

 

經典解釋

1、一致性

在分散式環境下，一致性是指資料在多個副本之間能否保持一致的特性。在一致性的需求下，當一個系統在資料一致的狀態下執行更新操作後，應該保證系統的資料仍然處於一直的狀態。

對於一個將資料副本分佈在不同分散式節點上的系統來說，如果對第一個節點的資料進行了更新操作並且更新成功後，卻沒有使得第二個節點上的資料得到相應的更新，於是在對第二個節點的資料進行讀取操作時，獲取的依然是老資料（或稱為髒資料），這就是典型的分散式資料不一致的情況。在分散式系統中，如果能夠做到針對一個數據項的更新操作執行成功後，所有的使用者都可以讀取到其最新的值，那麼這樣的系統就被認為具有強一致性

 
2、可用性

可用性是指系統提供的服務必須一直處於可用的狀態，對於使用者的每一個操作請求總是能夠在有限的時間內返回結果。這裡的重點是"有限時間內"和"返回結果"。

"有限時間內"是指，對於使用者的一個操作請求，系統必須能夠在指定的時間內返回對應的處理結果，如果超過了這個時間範圍，那麼系統就被認為是不可用的。另外，"有限的時間內"是指系統設計之初就設計好的執行指標，通常不同系統之間有很大的不同，無論如何，對於使用者請求，系統必須存在一個合理的響應時間，否則使用者便會對系統感到失望。

"返回結果"是可用性的另一個非常重要的指標，它要求系統在完成對使用者請求的處理後，返回一個正常的響應結果。正常的響應結果通常能夠明確地反映出隊請求的處理結果，即成功或失敗，而不是一個讓使用者感到困惑的返回結果。

 
3、分割槽容錯性

分割槽容錯性約束了一個分散式系統具有如下特性：分散式系統在遇到任何網路分割槽故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網路環境都發生了故障。

網路分割槽是指在分散式系統中，不同的節點分佈在不同的子網路（機房或異地網路）中，由於一些特殊的原因導致這些子網路出現網路不連通的狀況，但各個子網路的內部網路是正常的，從而導致整個系統的網路環境被切分成了若干個孤立的區域。需要注意的是，組成一個分散式系統的每個節點的加入與退出都可以看作是一個特殊的網路分割槽。

既然一個分散式系統無法同時滿足一致性、可用性、分割槽容錯性三個特點，所以我們就需要拋棄一樣：


摘抄至 https:
 
//www.cnblogs.com/szlbm/p/5588543.html

 

一致性（Consistency）
一致性指“all nodes see the same data at the same time”，即更新操作成功並返回客戶端完成後，所有節點在同一時間的資料完全一致。

可用性（Availability）
可用性指“Reads and writes always succeed”，即服務一直可用，而且是正常響應時間。

分割槽容錯性（Partition tolerance）
分割槽容錯性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分散式系統在遇到某節點或網路分割槽故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。


作者：丹之
連結：https://www.jianshu.com/p/f432665d523f

 

我的理解

分散式系統，首先必然是一個多個node （至少是大於1）的 集群系統， 對外提供統一的 服務。

C 是說， 外界 “以相同的方式”  訪問 其中任意 一個 當前仍然存活的 node，得到的 “ 服務 ” （或者說  響應）， 應該都是一樣的。 一般來說是針對這樣一種情況，node1 的某個資料更新了， node1 是否能夠 “ 及時”  更新， 如果是， 那麼就是 一致的（ 或者說“ 強一致性 ”），  否則，就是說，不一致（  或者說， “暫時的不一致”） 。因為我們只討論存活的節點， 那麼 如果有某個node down了， 是不會影響 C 的， 就是說， 不管down掉的node 的資料狀態 是否  最新的， 都不要緊， 因為， 我們已經不考慮它了！！

 特別說明， CAP的P 是指強一致性， 弱一致性，最終一致性， 都算是 不一致。

 

A 是說， 所有的node 應該都是可用的，  能夠 “ 對於使用者的每一個操作請求總是能夠在有限的時間內返回結果 ”， ————  這個無疑是一個非常難以理解的 騷 概念！ 天啊！

 什麼情況下， 會出現不可用呢？  node  宕機了？ cpu 100% ，非常繁忙？  網路問題？  down了？    是不是 只是說 “ 不管發生了什麼，  只要  使用者當前 訪問的 這個node 能夠在 指定時間 響應 就是 可用 ” ？   整個 系統， 都TM 不能用了， 叫做 不滿足A，。。

 

P 是說， 允許某些node 掛掉， 但是，需要整體上， 系統仍然能夠“正常使用”， 這裡的正常使用， 也是個 不好清晰定義的概念 （  一般來說，“正常使用” 是指 仍需要 滿足CA， 這裡似乎有點 概念 輪迴了啊。。 ）。 。 只可意會不可言傳。。。。  其實呢， P 還是比較好理解的， P 就是說， 某些node 掛掉就掛了吧，客戶端訪問其他node的時候， 還是能夠正常 服務就好了！  那麼，  我們可能會問， 要是 客戶端 正在或者 將要 訪問  這個 掛掉的 node 呢？  那好辦， 客戶端 失敗 數次後  （ 這個次數 是應該是 客戶端自定義的。。）， 自己切換到其他node 上去吧！ （ 就是說， 你客戶端， 別TM 吊死在一棵樹上， TM 放聰明點。  否則 就是 你客戶端的責任了！） 那麼， 就是把 責任推給了 客戶端？？ ———— 一般來說， 分散式系統 都允許 掛掉一部分 node， 但是呢， 也不能掛掉了太多node， 否則 系統 可能就無法  有效 保證 A， 或者C 了！   一般來說，  允許 掛掉一部分 node 數，  小於 總節點數的 一半 減 1  。

 

什麼情況是 叫做 不滿足P？  就是說， 不允許 網路故障 或 node 發生錯誤， 如果出現 則就是 不滿足P。——  這TM 的 誰也無法保證啊！！

 

為什麼 會出現這麼個 奇怪的 困惑的 難解 的 理論？  為什麼我們需要它 ？  如何證明？

用數學公式來證明 似乎是 很難的， 我們反正一下吧。

分散式系統為什麼會有不穩定之說？？？     當然， 單節點的時候 可能出現 的問題， 分散式系統 中一樣都會有， 但是 分散式系統中 問題會更多， 多 一些 “分散式相關的問題”。 ———— 簡單說， 最根本的問題， 就是分散式系統中 網路故障，延遲的客觀 存在 的可能性。

首先， 我們需要 假設 分散式系統中 網路 故障 是 有可能發生的。 （ 我們可以假設它 現在隨意的 發生），其實說來說去， 說到根本上， 網路問題是無法避免的。 除非？

然後， 假設 分散式系統中5個節點，  5個節點都TM 正常工作， 網路延遲 都非常小， 不會出現 客戶端 “  先發出的 請求， 後面才到達 ” 的問題。 那麼， CAP 是不是同時都滿足了呢？ 

CAP 理論這個時候是不是 被 打臉了？？

 

NO， 現在來看， 上面的例子， 沒有出現網路問題。 實際情況下， 不能保證 永遠 不出現網路問題， 所以， 上面的情況 是片面的！說句反話， 應該這麼理解， CAP 說的是 在任何情況下， 都要永遠的 同時的保證的一個CAP狀態，是TM 不可能的！  這麼說， 大家， 是不是就 好理解 CAP 了呢？？ 

啊啊

現在就討論網路問題情況下， 為什麼TM 不能 同時保證CAP了呢？ 

首先P，TM 就是無法保證的， 所以證明 無法保證 CAP，—— 無法再繼續證明了。。。

為了保證C， 那麼我們需要保持 存活的節點 的資料是最新的，如果  如果 down掉的 node是master，

 

有一個問題需要 區分， 網路問題（比如 延遲 或者 超時， 或者網路斷開了 等故障） 或 node 問題（比如 node無響應或 down 掉）。node響應慢 可以歸為 網路延遲的一種特例。

前者引起的分散式問題是：  無法通訊 或者 指令 的順序 錯位。 很顯然， 這個情況 可能導致 各個node的資料不一致， 也有可能是 各node 一致， 但是不知道是否一致。  如果排除這個網路問題呢？  node 之間的資料 能夠恢復一致性嗎？

後者引起的分散式問題是： 超時。。 很顯然， 這個情況 可能導致 各個node的資料不一致。 但是如果把這些失敗的node 剔除， 可以保證一致嗎？ 答案是 肯定的。。。 如何證明？

==============================================================================================

前面說了這麼多，我的表述可能也有錯誤， 可能我們還是比較懵逼

 

改寫

我們講CAP理論稍微改寫一下， CAP 描述的是 這麼一個多節點的系統，每個節點儲存相同的資料備份， 現在發生了網路問題， 無論如何， 無法同時保證CAP。—— 也就是說， 這種情況下，我們只能保證C或者A， 而不能同時保證 CA。（不要懷疑， 這樣的表述一定是 無比正確的） C: 所有的節點的資料保持一致， 重點，具體點來說， 就是 進行任意的read操作 返回相同結果！ A: 如何保證每個節點可讀可寫， 重點，具體點來說， 就是 仍然可以進行任意的read，write ！ P: 無論如何，保持系統可用   如何證明？ 其中我們只需也 TM 只能保證 CP 或者AP？（別要問我如何保證P，網路故障已經發生了， 系統需要繼續可用， 不能捨棄啊！ 所以，P 完全沒辦法捨棄， 所以P 是一定要保證的， 而且是 TM “自動” 保證了的，  否則， 整個系統 都不可用， 還玩個毛啊！而且，  必須注意的是， 現在這個網路故障不能恢復的， 否則就TM 是另外一個話題了！）  別要問我如何保證CA，除非單節點才會沒有網路問題，但那TM都不是分散式系統了！  

證明

其實 TM的賊簡單， 一、如果保證CP，那麼必須就得捨棄A，為什麼呢？ 因為不允許 任意的寫，就可以保證C。 這又是為什麼呢？ 兩種方案， 1、所有的節點不允許寫， 這個時候， 當然，所有的節點的資料都是最新而且一致的！ 但不允許寫，就喪失了 A !  2、選擇其中一個分割槽（一般是選擇比較“大” 的分割槽），另外的分割槽 則暫停使用或者丟棄，這樣，只有部分節點 可讀可寫，從某個角度來講， 保證了“當前選擇的分割槽” 的C（當然， 其實當前分割槽的A也是可以保證的）， 但是這樣就喪失了 “被暫停使用的分割槽”的A，（ 同時， 如果非要這麼說的話， “被暫停使用的分割槽” 的 C 也喪失了！ 那是不是可以說， 巨集觀來講， CA 無法同時保證了呢？ 是否CA 都喪失了呢？  ———— 是不是可以說 只能保證區域性性的 CA？ ————  這個時候TM 只能夠保證P， CA 無法保證， CAP 描述的是最多兩項）   二、如果保證AP，那麼必須就得捨棄C，為什麼呢？ 因為允許 任意的寫，那麼TM無法保證所有的節點的資料是一致的啊！  因為網路問題 的存在， 系統的資料無法 “及時” 的從一個節點 複製到 另外一個節點！ （ 否則， 那TM就不算是 網路問題了 ！）所以這個時候無法保證C。 —— 等等， 這裡， 某些同學可能還有疑問，雖然系統發生了網路問題， 但是 外部系統並不知道也不關心啊。 如果外部系統寫的時候， 如果它仍然能夠連線每一個節點，那麼它 依次往每個節點都寫 一份， 這樣就保證了 我們的分散式系統的各節點 的資料 都是一致了啦，  然後隨便怎麼讀， 都是一致的不會出現問題了啊！！ —— 沒錯， 這樣做確實是行得通的， 但TM 這已經是另外的話題了！ CAP 的A 是指 外部只寫入一次！    

總結

談到CAP的時候， 一定要了解其前提條件（ 所有的節點 都有資料備份）， 基本假設（網路問題是一定考慮的， 系統也要一定要可用， 所以P TM 無法不保證）。 但是TM 網路沒有的時候呢，CAP理論 TM 都沒有存在的任何意義了！ 所以CAP 理論其實TM 真是個 扯淡的 極容易搞暈的 無聊的 所謂的 理論。  甚至， 理論都稱不上， 因為 完全無法 真正意義的 證明。    P 是很難理解， 真正理解了後又TM 想罵人的 C 是很好理解的， AP 是最容易證明和理解 A 也還好，證明CP的時候呢， 需要考慮 網路問題已然發生， 不要考慮把網路恢復。 —— 我看到很多部落格 說 考慮網路恢復， 我這裡要罵死他們， 如果恢復了 TM 就不要討論CAP了！   CAP 是說最多隻能保證兩項，確實， 有時候只能保證P。 P 無法捨棄。 是否可以只保證A 或者C，這種情況不存在。  所有的情況就是： P； AP； CP；CAP（ 沒有網路問題的時候）；

 

CAP是非常騷的 理論， 非常扯淡、折騰人的理論。