• 一、CAP
  • 1、一致性
    • 1.1、一致性分類：
  • 2、可用性
    • 2.1、不可用：
    • 2.2、可用性級別：
  • 3、分割槽容忍性
    • 3.1、分割槽partition/network partition
    • 3.2、不具備分割槽容忍性
  • 4、CAP => CP or AP
  • 5、保證CP
  • 6、AP
    • 6.1、場景：
• 二、BASE
  • 1、基本可用：
  • 2、軟狀態：
  • 3、最終一致性：

一、CAP

CAP是研究分散式的一個比較經典的理論。

CAP就是Consistency、Availability、Partition Tolerence的簡稱。
也就是一致性，可用性，分割槽容忍性。

1、一致性

1.1、一致性分類：

1、強一致性：就是圖中的那種。

2、弱一致性：節點資料如果同步了，你就能查到，沒同步，就查不到，結果具有不確定性。

3、最終一致性：過一段時間，等節點之間資料同步之後，就可以查到。

2、可用性

客戶端往分散式系統的各個節點發送請求，都是可以獲取到響應的，寫入、查詢等操作都是成功的。

2.1、不可用：

客戶端往分散式系統中的各個節點發送請求的時候，獲取不到響應結果，那麼系統就是不可用了。

2.2、可用性級別：

99%，一年中只能有80小時左右是可以允許訪問失敗的

99.9%，一年中大概有8小時左右是可以訪問失敗

99.99%，一年中有大概不到1小時是可以訪問失敗的

99.999%，一年中有大概不到5分鐘是可以訪問失敗的

99.9999%，一年中只能有大概不到1分鐘可以訪問失敗

很多行業大部分的系統，其實99%可用性都沒到，每年總得故障幾次。能做到99.9%的系統就算是比較牛的了，畢竟一年內就幾個小時不可用。

3、分割槽容忍性

3.1、分割槽partition/network partition

網路分割槽 => 分散式系統之間的網路環境出了故障，分散式系統的各個節點之間現在已經無法進行通訊了。

遇到網路分割槽故障，類似於腦裂，然後系統還是可以正常對外提供服務的。

3.2、不具備分割槽容忍性

一旦網路故障，整套系統崩潰，你哪怕給各個節點發送訊息，全部失敗，整套系統甚至會宕機。

4、CAP => CP or AP

一個分散式系統不可能同時兼備一致性、可用性、分割槽容忍性，要麼是CP（一致性 + 分割槽容忍性），要麼就是AP（可用性 + 分割槽容忍性）。

基於這套理論，redis、mongodb、hbase等分散式系統，都是參照著CAP理論來設計的，有些系統是CP，有些系統是AP。

5、保證CP

1、現在網路發生故障，client向節點A傳送一個插入請求，節點A將資料插入。

2、節點A發現節點B之間網路不通了，無法進行資料同步。

3、client向節點B查詢資料，由於當前節點之間網路不通，直接給client返回：當前系統處於不一致狀態，不能查詢。

這樣就保證了一致性，不會讓client看到不一致的狀態，同時不能保證Available。

6、AP

同樣的場景下，要保證兩個節點都要可用的，所以client如果在節點A能夠查詢這條資料，但是如果請求到了節點B就查不到了。

6.1、場景：

電商、12306，這種業務類系統，一般都是AP。

查詢的商品或者火車票庫存可能都是舊資料，但是當你買的時候，肯定就是要查詢庫存，不影響使用。

二、BASE

Basicly Available、Soft State、Eventual Consistency，也就是基本可用、軟狀態、最終一致性。

1、基本可用：

• 正常情況下查詢，負載均衡到各個節點去查的，多節點抗高併發，如果發生網路故障，可以選擇降級。
• 如果流量太大了，直接返回一個空，讓你稍後再來查詢。

2、軟狀態：

多個節點都是可用的，但是可能一會能查到，一會就查不到了。

3、最終一致性：

一旦故障或者延遲解決了，資料過了一段時間最終一定是可以同步到其他節點的，資料最終一定是可以處於一致性的。