導航

• 引言
• 一、CAP 原則
• • 1.1 Consistency 一致性
  • 1.2 Available 可用性
  • 1.3 Partition tolerance 分區容錯性
  • 1.4 CAP 的矛盾
  • 1.5 CAP 的組合場景
• 二、BASE 理論
• • 2.1 基本可用
  • 2.2 軟狀態
  • 2.3 最終一致性
  • • 2.3.1 因果一致性
    • 2.3.2 讀自身所寫
    • 2.3.3 會話一致性
    • 2.3.4 單調讀一致性
    • 2.3.5 單調寫一致性
• 總結

引言

本文介紹CAP原則和BASE理論。二者是分布式系統中重要的參考原則及指導方針。

其中 CAP 是由加州大學的計算機科學家 Eric Brewer 于1998 年提出，代表了分布式系統的三個重要指標。

一、CAP 原則

CAP 是 Consistency 、Availability、Partition tolerance 的首字母縮寫。所謂CAP原則，簡單的說就是不可能存在CAP，即如下圖所示，CAP 三個指標只能實現其中兩個，而永遠無法三者兼具。

1.1 Consistency 一致性

在系統中的所有數據備份，在同一時刻要保持同樣的值。

1.2 Available 可用性

在集群系統中，一部分節點故障后，集群整體依然可以響應外界請求。

簡單來說，只要用戶發起請求，系統就必須及時響應。響應的越快，可用性越好。

1.3 Partition tolerance 分區容錯性

分區指的是分布式系統中的多個網絡節點之間無法通信，導致分布在不同網絡中的應用無法訪問“失聯的”數據。

解決分區問題的最好辦法就是給數據備份，備份在不同的網絡中，這樣，當網絡通信出現故障，就會降低數據訪問不到的風險，提高了分區容錯性。

1.4 CAP 的矛盾

一般來說，分區問題無法避免，只能采用備份數據的方式盡可能提高分區容錯性。因此可以認為 CAP 中的 P 總是要具備的。CAP 原則告訴我們，剩下的 C 和 A 無法兼得。

簡單來說，為了提高分區容錯性，數據的備份是必要的，備份的數量越多，容錯性越好，但備份的越多，保證一致性就越困難，也勢必就影響系統整體的響應速度（可用性）。

但是，根據不同的業務場景，CAP 三者可以達到一種平衡關系。

1.5 CAP 的組合場景

CA：不允許分區的組合方式，舍棄了分區容錯性。則 C （一致性）和 A（可用性）可以保證。但放棄 P 的同時也意味著放棄了系統擴展性，即限制分布式節點，這違背了分布式系統設計的初衷。滿足CA 組合的系統例如傳統的單體應用。

CP：不要求 A（可用性），相當于數據需要保證較強的一致性。而 P （分區）會導致系統響應時間的延長，一旦發生網絡故障或消息丟失等情況，就要犧牲用戶體驗。最典型的就是分布式系統，如傳統數據庫 MySQL，各種金融業務場景也需要優先保證CP指標，也可以算作是CP組合。

AP：放棄一致性，追求更高的系統響應。一旦分區發生，節點之間的數據無法保持一致，為了高可用，每個節點只能使用本地數據提供服務。最典型的場景就是電商系統，同一個商品可能前一秒還庫存充足，但秒殺一開始，剛準備下單，就提示下單失敗，商品已售完。Redis也是一種AP分布式結構。

二、BASE 理論

BASE 是 Basically Available（基本可用）、Soft state（軟狀態）、Eventually Consistent（最終一致性）三個短語的縮寫。

BASE 是對大規模互聯網分布式系統的實踐結論，是對 CAP 中 C 一致性 和 A 可用性的權衡策略。
其核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。

2.1 基本可用

基本可用指的是，當系統出現故障，部分節點無法正常工作，可以允許犧牲一定程度的用戶體驗，但絕不允許系統完全不可用。

• 響應時間：正常情況，一個在線搜索引擎需要 0.5 秒內返回查詢結果，但由于出現異常，查詢時間增加到 1 ~ 2 秒。
• 功能：正常情況，在一個電商系統購物，消費者幾乎可以順利完成每一筆訂單，但是由于異常，或消費者數量激增，為了保證系統的穩定性，部分消費者可能會被引導到一個降級頁面。

2.2 軟狀態

什么是軟狀態呢？相對于原子性而言，要求多個節點的數據副本都是一致的，這是一種“硬狀態”。

軟狀態指的是：允許系統中的數據存在中間狀態，并認為該狀態不影響系統的整體可用性，即允許系統在多個不同節點的數據副本存在數據延遲。

2.3 最終一致性

軟狀態允許數據備份延遲，但最終這些數據都要保證一致性。這就是最終一致性。

最終一致性在軟狀態上加了一個時限，這個時限取決于網絡延時、系統負載、數據復制方案設計等。根據實際的業務場景，最終一致性可被分為以下 5 種。

2.3.1 因果一致性

有果必有因。收到數據更新通知的節點，應該使用更新后的新值，即種下什么因，就得什么果。

例如，服務A更新了一個數據后，通知給了服務B，那么服務B如果要操作這個數據，應該使用 A 更新后的新值。如果 C 和 A沒有這種關系，那么可以不受這一條件的限制。

2.3.2 讀自身所寫

自身寫入的新值，之后讀取也應該是這個新值。這是一種特殊的因果一致性。

2.3.3 會話一致性

會話一致性將對系統數據的訪問過程框定在了一個會話當中：系統能保證在同一個有效的會話中實現“讀自身所寫”的一致性，也就是說，執行更新操作之后，客戶端能夠在同一個會話中始終讀取到該數據項的最新值。

2.3.4 單調讀一致性

單調讀一致性是指，如果一個節點從系統中讀取出一個數據項的某個值后，那么系統對于該節點后續的任何數據訪問都不應該返回更舊的值。

2.3.5 單調寫一致性

單調寫一致性是指，一個系統要能夠保證來自同一個節點的寫操作被順序的執行。

在實踐中，這5種一致性往往會結合使用，以構建一個具有最終一致性的分布式系統

總結

CAP 原則，分布式系統參考的三個重要指標。具體是指 Consistency 一致性、Availability 可用性、Partition tolerance 分區容錯性。

CAP 原則指出，在一個分布式系統中，不可能同時滿足三者，而分區容錯性一般是必須具備的重要指標，這也是分布式系統的初衷，因此，實際的業務架構設計中，往往都是對 C 一致性 和 A 可用性的權衡和取舍。

三種類型組合的常見案例：

1、CA ：破壞了分布式系統的設計初衷，單體應用。
2、CP ：傳統數據庫如 MySQL、各種涉及到銀行、金融的交易系統。要求較高的一致性，舍棄用戶體驗。
3、AP ：電商系統，秒殺等業務場景。但數據會實現最終一致性，追求用戶體驗的響應性，舍棄一部分實時的一致性，如 Redis 。

BASE 理論，是對CAP實踐的進一步指導方針。是基本可用、軟狀態、最終一致性三個英文單詞的縮寫。

基本可用：顧名思義，即系統允許犧牲一部分用戶體驗，但決不允許系統無法響應，甚至崩潰。

軟狀態：允許系統中的備份數據存在中間狀態，但也必須是不影響整體系統功能的前提下，即數據備份允許延遲。

最終一致性：在軟狀態之上增加了時限，要努力達到數據最終是一致的。5 種最終一致性：因果、讀自寫、會話、單調讀、單調寫。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的CAP 原则与 BASE 理论的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。