CAP和BASE理論可以說是分布式系統的基礎理論了，只要面試的時候遇到分布式的問題，基本上都會問到這兩個理論。但是好多沒畢業的同學，或者參加工作時間不長的同學，可能沒有在實際開發中接觸過分布式系統，這種情況我的建議是多看優質博客，自己多思考，然后找一些開源的項目看一下理論的實際運用。當然有相關經驗的同學也可以復習鞏固一下。
一、CAP定理
CAP定理又被稱為布魯爾定理，是加州大學計算機科學家埃里克·布魯爾提出來的猜想，后來被證明成為分布式計算領域公認的定理。不過布魯爾在出來CAP的時候并沒有對CAP三者（Consistency，AvAIlability，Partition tolerance）進行詳細的定義，所以在網上也出現了不少對CAP不同解讀的聲音。
CAP定理在發展中經歷過兩個版本，后一個版本比較完善，我們以第二個版本為準：在一個分布式系統中（指互相連接并共享數據的節點集合）中，當涉及到讀寫操作時，只能保證一致性（Consistence）、可用性(Availability）、分區容錯性（Partition Tolerance）三者中的兩個，另外一個必須被犧牲。
其中的關系如下圖所示：
為了方便理解，我們先用相對通俗的語言來解釋一下一致性、可用性、分區容錯性的具體體現是什么，也就是保證的到底是什么。
一致性(Consistence) , 這個是針對數據來說的，比如數據庫MySQL中的數據，一個分布式系統中，某個節點修改了一個數據，那么之后其他所有節點讀取這條數據的時候，得到的一定是最新的數據。
可用性(Availability)，分布式系統中某些節點掛掉了，但是不會影響整體的業務，比如 C 這個微服務，有10個實例組成一個集群，其中5個掛了，另外5個正常，這種情況下整個系統還是可用的，不會因為掛了那5個，導致系統整體不可用。
分區容錯性(Partition Tolerance)，分布式系統出現網絡分區的時候，仍然能夠對外提供服務。
什么是網絡分區？
分布式系統中，多個節點之前的網絡本來是連通的，但是因為某些故障（比如部分節點網絡出了問題）某些節點之間不連通了，整個網絡就分成了幾塊區域，這就叫網絡分區。
1.1只能三選二？
我在網上看了一些博客，有些說這三個特性只能三選二，不可能同時滿足。這其實是一個具有誤導性質的說法。
因為在分布式系統中，網絡不是100%可靠的，網絡分區是必選項，也就是P是必選的，如果我們不選P，選CA，這個時候如果網絡發生了分區，那么為了保證C，系統就會禁止寫入數據，這樣就與A產生了沖突，如果為了保證A，那么正常的分區可以寫入數據，有故障的分區就不能寫入了，這就與C產生了沖突。
簡單來說，就是P是必須要實現的，因為網絡不是100%可靠的，在此基礎上C 和 A 二選一組成 CP 或者 AP 架構。
比如Zookeeper 是CP架構，Eureka是AP架構，Nacos 不僅支持 CP 架構也支持 AP 架構。
對于服務注冊來說，針對同一個服務，即使注冊中心的不同節點保存的服務注冊信息不相同，也并不會造成災難性的后果，對于服務消費者來說，能消費才是最重要的，就算拿到的數據不是最新的數據，消費者本身也可以進行嘗試失敗重試。總比為了追求數據的一致性而獲取不到實例信息整個服務不可用要好。
所以，對于服務注冊來說，可用性比數據一致性更加的重要，選擇AP。
1.2 CAP的實際應用
1.2.1 注冊中心
注冊中心主要做兩件事：
- 服務注冊：實例把自身的信息給注冊中心，信息包括服務的IP地址和服務Port，以及暴露服務自身狀態和訪問協議信息。
- 服務發現：實例請求注冊中心，拿到想要請求的服務信息，IP+Port，就可以訪問具體的實例了。
常見的注冊中心組件有：Zookeeper、Eureka、Nacos等等，我們以Zookeeper和Eureka為例，分別說明一下CP和AP。
Zookeeper 保證的是CP。任何時刻對Zookeeper的讀請求都能得到一致的結果，但是zookeeper不`能保證服務的可用性，比如在選舉Leader的時候，或者一半以上的機器不可用，那么整個系統就是不可用狀態。
Eureka保證的是AP。因為在設計的時候就是優先保證AP，而且Eureka集群中沒有Leader節點，每個節點都是一樣的，所以Eureka可以做到只要有一個節點可用，那么系統就是可用的，只不過這個節點上的數據不能保證是最新的。
1.2.2 小結
對于服務注冊來說，針對同一個服務，即使注冊中心的不同節點保存的服務注冊信息不相同，也并不會造成災難性的后果，對于服務消費者來說，能消費才是最重要的，就算拿到的數據不是最新的數據，消費者本身也可以進行嘗試失敗重試。總比為了追求數據的一致性而獲取不到實例信息整個服務不可用要好。
所以，對于服務注冊來說，可用性比數據一致性更加的重要，一般選擇AP。
二、BASE理論
BASE 是 Basically Available（基本可用）、Soft-state（軟狀態） 和 Eventually Consistent（最終一致性） 三個短語的縮寫。BASE 理論是對 CAP 中一致性 C 和可用性 A 權衡的結果，其來源于對大規模互聯網系統分布式實踐的總結，是基于 CAP 定理逐步演化而來的，它大大降低了我們對系統的要求。
BASE理論本質上是對CAP的延伸和補充，是對CAP中的AP方案的一個補充，即在選擇AP方案的情況下，如何更好地最終達到C。
2.1 BASE理論三要素
基本可用：出現故障的時候，允許損失部分可用性，即，保證核心可用
如，電商大促時，為了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務。
軟狀態：允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。
軟狀態本質上是一種弱一致性，允許的軟狀態不能違背“基本可用”的要求。如，分布式存儲中一般一份數據至少會有三個副本，允許不同節點間副本同步的延時（某些時刻副本數低于3）。
最終一致性：系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態。
最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步后，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
分布式中的一致性有三種級別：
①強一致性：系統在某個節點中寫入或修改了數據，那么之后在任意節點讀取到的數據都是最新的數據。
②弱一致性：不一定能讀到最新的值，也不能保證在一定時間后讀取到的數據是最新的，只會盡量在某個時刻達到數據一致的狀態。
③最終一致性：弱一致性的升級版，可以保證在一定時間內達到數據的最終一致性。
一般常用的是最終一致性，但是也有一些對一致性要求比較高的，比如銀行的交易系統，這種要保證強一致性。
三、總結
在分布式架構中，是無法脫離CAP理論的，因為網絡永遠不能100%可靠，硬件也會老化，軟件可能出現BUG，所以分區容錯性(Partition Tolerance)是避不開的，只要是分布式，只要是集群，都面臨著選AP或者CP，如果你都想要，那只能對一致性做出一些妥協，也就是引入BASE理論，在業務允許的情況下實現最終一致性。
究竟是選擇AP還是CP，在于業務，比如涉及到金錢交易，庫存相關的會優先考慮CP模型，而例如社區發帖，評論這種相關的可以選擇AP模型。總之選什么模型是由業務來決定的。
