這兩個理論都是對於分佈式系統設計而言的。
CAP：Consistency(一致性),Availability(可用性),Partition Tolerance(分區容錯)。這三個的單詞的首字母組合。
BASE:Basically Available(基本可用),Soft-state(軟狀態),Eventually Consistent(最終一致性)三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果。其來源對於大規模互聯網系統分佈式實踐的總結。是基於CAP定理逐漸演化而來的。它大大降低了我們對系統的要求。
CAP理論
CAP理論起源於2000年。是布魯爾提出的。因此又被稱爲布魯爾理論。
簡介
CAP也就是Consistency(一致性)，Availability(可用性)，Partition Tolerance(分區容錯性)這三個單詞首字母組合。
其實最開始提出CAP猜想的時候，並沒有詳細定義三個單詞的明確定義。所以這個解讀有多種，下面是一種比較常見的解讀：
- 一致性：所有節點訪問同一份最新的數據副本
- 可用性：非故障的節點在合理的時間內返回合理的響應(不是錯誤或超時的響應)
- 分區容錯性：分佈式系統出現網絡分區的時候，仍然能夠對外提供服務。
什麼是網絡分區？
分佈式系統中，多個節點之間的網絡本來是可以連通的，但是因爲某些故障(比如部分節點網絡出現問題)某些節點不連通了，整個網絡就分成幾塊區域，這就叫網絡分區。
不是所謂的三選二
其實cap不是隻能實現三個中的兩個。而是分區容錯是基礎，而C,A是二選一的。因爲我們任何情況下都不能去實現客觀的不可能。比如服務器爆炸，服務器被摒棄網絡信號，服務器着火種種，這些是沒辦法去控制的。所以網絡分區之後，P是前提。一致性和可用性只能二選一。
因此分佈式系統理論上不可能選擇CA架構，只能選擇CP或者AP架構。
比如zookeeper，hbase就是CP架構，C阿薩Sandra，Eureka就是AP架構。Nacos不僅支持CP架構也支持AP架構。
爲啥不能選擇CA架構呢？舉個例子：若系統出現分區，某個節點正在進行寫操作。爲了保證一致性，必須禁止其他節點的讀寫操作。但是這就和可用性衝突了。如果爲了保證可用性，其他節點正常讀寫的話，又和一致性衝突了。’
選擇CP還是AP的關鍵在於業務場景，沒有定論。對於需要確保強一致性的場景，比如銀行一般會保證CP。
另外其實如果網絡分區正常的話，也就是P沒有出現問題，那麼A和C是可以同時保證的。
CAP實際應用案例
註冊中心負責服務地址的註冊與查找。相當於目錄服務。服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小。
常見的可以作爲註冊中心的組件有：zookeeper，euraka，nacos。
- ZooKeeper：保證的是CP。任何時刻對zookeeper的讀請求都能得到一致性的結果。但是zookeeper不保證每次請求的可用性。比如在leader選舉過程中或者半數以上機器不可用的時候服務就是不可用的。
- Eureka保證的是AP。Eureka在設計的時候就是優先保證可用性。在Eureka中不存在什麼Leader節點。每個節點都是一樣的，平等的。因此Eureka不會像zookeeper那樣出現選舉過程中或者半數以上機器不可用的時候服務就不可用。Eureka保證即使大部分節點掛掉也不會影響正常提供服務，只要有一個節點可用就行，但是這個節點上的數據可能不是最新的。
- Nacos不僅支持CP也支持AP。
總結
其實在分佈式系統設計和開發的時候，我們不應該僅僅侷限於CAP的問題，還要關注系統的擴展性，可用性等。
在系統發生網絡分區的情況下，CAP理論只能滿足CP或者AP。但是如果沒有發生網絡分區，其實C,A是可以同時保證的。
所以說，如果發生網絡分區，我們要考慮CP還是AP。如果沒有網絡分區，我們要考慮如何保證CA。
其實這個CAP我覺得可以認爲是一個選擇題。用生活中一個比喻來說：對一個小孩子來說，如果父母離婚，是跟爸爸還是跟媽媽。
首先前提要父母離婚，所以纔會有接下來的選擇(CAP中前提出現了網絡分區，纔會有一致性和可用性的選擇)
然後跟媽媽還是爸爸只能是二選一的(出現P以後，A和C只能選一個)
至於到底跟誰，其實都要根據實際情況來看。而我們到底選擇哪個自然也要看我們更在意什麼。
比如銀行轉賬，如果出現了P，保證可用性而放棄一致性的話。A轉給B100元錢。A這邊少100.但是因爲B那邊網不通，B沒有多一百。 這樣100塊錢蒸發了。這樣肯定不行，所以我們完全可以在出現P以後，保證一致性而放棄可用性，不讓A轉賬了。這樣哪怕A不樂意不開心，但是整體的邏輯是對的。
而對於別的場景，比如說瀏覽視頻點贊，這個時候出現了網絡分區，你這邊點了可能服務器記錄不上。但是這又不妨礙讓用戶先點着，最多最多最後數據丟失了，那估計用戶還會以爲自己記錯了而已。所以這個時候我們完全可以選擇可用性而不是一致性。
另外CAP其實可以認爲是個預想中的場景。正常來說P是不會出現的，可是我們在做程序要預測到可能出現的bug。所以哪怕說Euraka選擇了AP，但是也沒總出現什麼數據不一致，zookeeper選擇了CP，但是大部分時間也都是可用的。
BASE理論
BASE理論起源於2008年。
簡介
BASE是Basically Available(基本可用)，Soft-state(軟狀態)和Eventually Consistent(最終一致性)三個短語組成。BASE理論是對CAP中一致性和可用性權衡的結果。其來源於對大規模互聯網系統分佈式實踐的總結。是基於CAP定理逐漸演化而來的，它大大降低了我們對系統的要求。
BASE理論的核心思想
即使無法做到強一致性，但是每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。
也就是犧牲數據的一致性來滿足系統的高可用性。系統中一部分數據不可用或者不一致時，仍需要保持系統整體主要可用。
其實BASE可以看成是CAP中關於AP的一個補充。AP方案是放棄一致性選擇可用性。但是隻是在系統發生分區的時候放棄一致性，而不是永久放棄。所以在分區故障恢復後，系統最終應該還是要達到一致性的。這就是BASE理論延申的地方。
BASE理論三要素
-
基本可用
基本可用是指分佈式系統在出現不可預知故障的時候，允許損失部分可用性。但是這決不等於系統不可用。
什麼叫允許損失部分可用性呢?- x響應時間上的損失：正常情況下0.1s返回結果，但是由於系統故障，變成1s返回結果了。
- 系統功能上的損失：正常情況下用戶可以使用系統的全部功能，但是由於訪問量劇增，系統的部分非核心功能無法使用。
軟狀態
軟狀態指允許系統中的數據存在中間狀態(CAP理論中的數據不一致)，並認爲該中間狀態不會影響系統的整體可用性。即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。最終一致性
最終一致性強調的是系統中所有的數據副本，經歷過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據一致而不是實時強一致。
分佈式一致性的三種級別：
- 強一致性：系統寫入什麼讀出來的就是什麼
- 弱一致性：不一定讀取到的是最新的值，也不保證多長時間後讀到的數據是最新的。只會儘量保證某個時刻達到數據一致的狀態
- 最終一致性：弱一致性的升級版，系統會保證在一定時間內達到數據一致的狀態。
目前在要求不嚴格的情況，比較常見的還是最終一致性級別。
實現最終一致性的具體方式是什麼？
- 讀時修復:在讀取數據時，檢測數據不一致，進行修復。比如在查詢的時候如果檢測到不同節點的副本數據不一致，則自動修復數據。
- 寫時修復:在寫入數據的時候，檢測數據的不一致時，進行修復。如果寫失敗了就將數據緩存下來，然後定時重傳，修復數據的不一致性。
- 異步修復:這個是最常用的方式，通過定時對賬，檢測副本數據的一致性並修復。
比較推薦寫時修復，這種方式對性能消耗比較低。
本篇筆記就記到這裏，如果稍微幫到你了記得點個喜歡點個關注，也祝大家工作順順利利！