本文節選自我開源的 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 面試手冊。