差點跪了！阿里3面真題：CAP和BASE理論瞭解麼？能夠結合實際案例說下不？

本文節選自我開源的 JavaGuide ：https://github.com/Snailclimb/JavaGuide （Github標星92k+!一份涵蓋大部分 Java 程序員所須要掌握的核心知識。準備 Java 面試，首選 JavaGuide！）

經歷過技術面試的小夥伴想必對這個兩個概念已經再熟悉不過了！

Guide哥當年參加面試的時候，不誇張地說，只要問到分佈式相關的內容，面試官幾乎是一定會問這兩個分佈式相關的理論。

而且，這兩個理論也能夠說是小夥伴們學習分佈式相關內容的基礎了！

所以，小夥伴們很是很是有必要將這理論搞懂，而且可以用本身的理解給別人講出來。

這篇文章我會站在本身的角度對這兩個概念進行解讀！

我的能力有限。若是文章有任何須要改善和完善的地方，歡迎在評論區指出，共同進步！——愛大家的Guide哥

CAP理論

CAP 理論/定理起源於 2000年，由加州大學伯克利分校的Eric Brewer教授在分佈式計算原理研討會（PODC）上提出，所以 CAP定理又被稱做 布魯爾定理（Brewer’s theorem）

2年後，麻省理工學院的Seth Gilbert和Nancy Lynch 發表了布魯爾猜測的證實，CAP理論正式成爲分佈式領域的定理。

簡介

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分區容錯性） 這三個單詞首字母組合。

CAP 理論的提出者布魯爾在提出 CAP 猜測的時候，並無詳細定義 Consistency、Availability、Partition Tolerance 三個單詞的明肯定義。

所以，對於 CAP 的民間解讀有不少，通常比較被你們推薦的是下面 👇 這種版本的解。

在理論計算機科學中，CAP 定理（CAP theorem）指出對於一個分佈式系統來講，當設計讀寫操做時，只能能同時知足如下三點中的兩個：

• 一致性（Consistence） : 全部節點訪問同一份最新的數據副本
• 可用性（Availability）: 非故障的節點在合理的時間內返回合理的響應（不是錯誤或者超時的響應）。
• 分區容錯性（Partition tolerance） : 分佈式系統出現網絡分區的時候，仍然可以對外提供服務。

什麼是網絡分區？

分佈式系統中，多個節點以前的網絡原本是連通的，可是由於某些故障（好比部分節點網絡出了問題）某些節點之間不連通了，整個網絡就分紅了幾塊區域，這就叫網絡分區。

不是所謂的「3 選 2」

大部分人解釋這必定律時，經常簡單的表述爲：「一致性、可用性、分區容忍性三者你只能同時達到其中兩個，不可能同時達到」。實際上這是一個很是具備誤導性質的說法，並且在 CAP 理論誕生 12 年以後，CAP 之父也在 2012 年重寫了以前的論文。

當發生網絡分區的時候，若是咱們要繼續服務，那麼強一致性和可用性只能 2 選 1。也就是說當網絡分區以後 P 是前提，決定了 P 以後纔有 C 和 A 的選擇。也就是說分區容錯性（Partition tolerance）咱們是必需要實現的。

簡而言之就是：CAP 理論中分區容錯性 P 是必定要知足的，在此基礎上，只能知足可用性 A 或者一致性 C。

所以，分佈式系統理論上不可能選擇 CA 架構，只能選擇 CP 或者 AP 架構。

爲啥無同時保證 CA 呢？

舉個例子：若系統出現「分區」，系統中的某個節點在進行寫操做。爲了保證 C， 必需要禁止其餘節點的讀寫操做，這就和 A 發生衝突了。若是爲了保證 A，其餘節點的讀寫操做正常的話，那就和 C 發生衝突了。

選擇的關鍵在於當前的業務場景，沒有定論，好比對於須要確保強一致性的場景如銀行通常會選擇保證 CP 。

CAP 實際應用案例

我這裏以註冊中心來探討一下 CAP 的實際應用。考慮到不少小夥伴不知道註冊中心是幹嗎的，這裏簡單以 Dubbo 爲例說一說。

下圖是 Dubbo 的架構圖。註冊中心 Registry 在其中扮演了什麼角色呢？提供了什麼服務呢？

註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小。

常見的能夠做爲註冊中心的組件有：ZooKeeper、Eureka、Nacos...。

1. ZooKeeper 保證的是 CP。 任什麼時候刻對 ZooKeeper 的讀請求都能獲得一致性的結果，可是， ZooKeeper 不保證每次請求的可用性好比在 Leader 選舉過程當中或者半數以上的機器不可用的時候服務就是不可用的。
2. Eureka 保證的則是 AP。 Eureka 在設計的時候就是優先保證 A （可用性）。在 Eureka 中不存在什麼 Leader 節點，每一個節點都是同樣的、平等的。所以 Eureka 不會像 ZooKeeper 那樣出現選舉過程當中或者半數以上的機器不可用的時候服務就是不可用的狀況。 Eureka 保證即便大部分節點掛掉也不會影響正常提供服務，只要有一個節點是可用的就好了。只不過這個節點上的數據可能並非最新的。
3. Nacos 不只支持 CP 也支持 AP。

總結

在進行分佈式系統設計和開發時，咱們不該該僅僅侷限在 CAP 問題上，還要關注系統的擴展性、可用性等等

在系統發生「分區」的狀況下，CAP 理論只能知足 CP 或者 AP。要注意的是，這裏的前提是系統發生了「分區」

若是系統沒有發生「分區」的話，節點間的網絡鏈接通訊正常的話，也就不存在 P 了。這個時候，咱們就能夠同時保證 C 和 A 了。

總結：若是系統發生「分區」，咱們要考慮選擇 CP 仍是 AP。若是系統沒有發生「分區」的話，咱們要思考如何保證 CA 。

推薦閱讀

1. CAP 定理簡化 （英文，有趣的案例）
2. 神同樣的 CAP 理論被應用在何方 （中文，列舉了不少實際的例子）
3. 請中止呼叫數據庫 CP 或 AP （英文，帶給你不同的思考）

BASE 理論

BASE 理論起源於 2008 年， 由eBay的架構師Dan Pritchett在ACM上發表。

簡介

BASE 是 Basically Available（基本可用） 、Soft-state（軟狀態） 和 Eventually Consistent（最終一致性） 三個短語的縮寫。BASE 理論是對 CAP 中一致性 C 和可用性 A 權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結，是基於 CAP 定理逐步演化而來的，它大大下降了咱們對系統的要求。

BASE 理論的核心思想

即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，採用適當的方式來使系統達到最終一致性。

也就是犧牲數據的一致性來知足系統的高可用性，系統中一部分數據不可用或者不一致時，仍須要保持系統總體「主要可用」。

BASE 理論本質上是對 CAP 的延伸和補充，更具體地說，是對 CAP 中 AP 方案的一個補充。

爲何這樣說呢？

CAP 理論這節咱們也說過了：

若是系統沒有發生「分區」的話，節點間的網絡鏈接通訊正常的話，也就不存在 P 了。這個時候，咱們就能夠同時保證 C 和 A 了。所以，若是系統發生「分區」，咱們要考慮選擇 CP 仍是 AP。若是系統沒有發生「分區」的話，咱們要思考如何保證 CA 。

所以，AP 方案只是在系統發生分區的時候放棄一致性，而不是永遠放棄一致性。在分區故障恢復後，系統應該達到最終一致性。這一點其實就是 BASE 理論延伸的地方。

BASE 理論三要素

1. 基本可用

基本可用是指分佈式系統在出現不可預知故障的時候，容許損失部分可用性。可是，這毫不等價於系統不可用。

什麼叫容許損失部分可用性呢？

• 響應時間上的損失: 正常狀況下，處理用戶請求須要 0.5s 返回結果，可是因爲系統出現故障，處理用戶請求的時間變爲 3 s。
• 系統功能上的損失：正常狀況下，用戶可使用系統的所有功能，可是因爲系統訪問量忽然劇增，系統的部分非核心功能沒法使用。

2. 軟狀態

軟狀態指容許系統中的數據存在中間狀態（CAP 理論中的數據不一致），並認爲該中間狀態的存在不會影響系統的總體可用性，即容許系統在不一樣節點的數據副本之間進行數據同步的過程存在延時。

3. 最終一致性

最終一致性強調的是系統中全部的數據副本，在通過一段時間的同步後，最終可以達到一個一致的狀態。所以，最終一致性的本質是須要系統保證最終數據可以達到一致，而不須要實時保證系統數據的強一致性。

分佈式一致性的 3 種級別：

1. 強一致性 ：系統寫入了什麼，讀出來的就是什麼。

2. 弱一致性 ：不必定能夠讀取到最新寫入的值，也不保證多少時間以後讀取到的數據是最新的，只是會儘可能保證某個時刻達到數據一致的狀態。

3. 最終一致性 ：弱一致性的升級版。，系統會保證在必定時間內達到數據一致的狀態，

業界比較推崇是最終一致性級別，可是某些對數據一致要求十分嚴格的場景好比銀行轉帳仍是要保證強一致性。

總結

ACID 是數據庫事務完整性的理論，CAP 是分佈式系統設計理論，BASE 是 CAP 理論中 AP 方案的延伸。

圖解計算機基礎+我的原創的 Java 面試手冊PDF版。

微信搜「JavaGuide」回覆「計算機基礎」便可獲取圖解計算機基礎+我的原創的 Java 面試手冊。