本文節選自我開源的 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...。
- ZooKeeper 保證的是 CP。 任何時刻對 ZooKeeper 的讀請求都能得到一致性的結果，但是， ZooKeeper 不保證每次請求的可用性比如在 Leader 選舉過程中或者半數以上的機器不可用的時候服務就是不可用的。
- Eureka 保證的則是 AP。 Eureka 在設計的時候就是優先保證 A （可用性）。在 Eureka 中不存在什麼 Leader 節點，每個節點都是一樣的、平等的。因此 Eureka 不會像 ZooKeeper 那樣出現選舉過程中或者半數以上的機器不可用的時候服務就是不可用的情況。 Eureka 保證即使大部分節點掛掉也不會影響正常提供服務，只要有一個節點是可用的就行了。只不過這個節點上的數據可能並不是最新的。
- Nacos 不僅支持 CP 也支持 AP。
總結
在進行分佈式系統設計和開發時，我們不應該僅僅侷限在 CAP 問題上，還要關注系統的擴展性、可用性等等
在系統發生“分區”的情況下，CAP 理論只能滿足 CP 或者 AP。要注意的是，這裏的前提是系統發生了“分區”
如果系統沒有發生“分區”的話，節點間的網絡連接通信正常的話，也就不存在 P 了。這個時候，我們就可以同時保證 C 和 A 了。
總結：如果系統發生“分區”，我們要考慮選擇 CP 還是 AP。如果系統沒有發生“分區”的話，我們要思考如何保證 CA 。
推薦閱讀
- CAP 定理簡化 （英文，有趣的案例）
- 神一樣的 CAP 理論被應用在何方 （中文，列舉了很多實際的例子）
- 請停止呼叫數據庫 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 種級別：
強一致性 ：系統寫入了什麼，讀出來的就是什麼。
弱一致性 ：不一定可以讀取到最新寫入的值，也不保證多少時間之後讀取到的數據是最新的，只是會儘量保證某個時刻達到數據一致的狀態。
最終一致性 ：弱一致性的升級版。，系統會保證在一定時間內達到數據一致的狀態，
業界比較推崇是最終一致性級別，但是某些對數據一致要求十分嚴格的場景比如銀行轉賬還是要保證強一致性。
總結
ACID 是數據庫事務完整性的理論，CAP 是分佈式系統設計理論，BASE 是 CAP 理論中 AP 方案的延伸。
圖解計算機基礎+個人原創的 Java 面試手冊PDF版。
微信搜“JavaGuide”回覆“計算機基礎”即可獲取圖解計算機基礎+個人原創的 Java 面試手冊。