CAP特性 CAP理論是在設計分散式系統的過程中，處理數據一致性問題時必須考慮的理論，一個分散式系統最多只能同時滿足一致性（Consistence）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項。 2000年7月Eric Brewer教授 ...
CAP特性
CAP理論是在設計分散式系統的過程中，處理數據一致性問題時必須考慮的理論，一個分散式系統最多只能同時滿足一致性（Consistence）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項。
2000年7月Eric Brewer教授僅僅提出來的是一個猜想，2年後，麻省理工學院的Seth Gilbert和Nancy Lynch從理論上證明瞭CAP理論，並且而一個分散式系統最多只能滿足CAP中的2項。之後，CAP理論正式成為分散式計算領域的公認定理
比如Redis他就是 AP 特性（所以它才能搞可用）、 Zookeeper就是CP特性
C（一致性Consistency）
所有節點在同一時間的看到的數據相同、即更新操作成功並返回客戶端完成後，所有節點在同一時間的數據完全一致，不能存在中間狀態。
分散式環境中，一致性是指多個副本之間能否保持一致的特性。在一致性的需求下，當一個系統在數據一致的狀態下執行更新操作後，應該保證系統的數據仍然處理一致的狀態。
.png)
一致性又可分為強一致性和弱一致性&最終一致性
強一致性
如果的確能像上面描述的那樣時刻保證客戶端看到的數據都是一致的，那麼稱之為強一致性、比如12306就是強一致性的、用戶下單購票之後，必須要所有節點同步扣除票餘額才算訂票成功，避免超票的情況
最終一致性
允許中間狀態、只要經過一段時間後，通過定時或者其他方式、數據最終是一致性的，則稱為最終一致性（比如我們生活中看到的評論這些就可以使用最終一致性）
弱一致性
允許存在部門數據不一致
A（可用性Availability）
伺服器一直是可用的、不會出現錯誤、即使我數據不一致，我也會返回老的數據給你看，但是不能保證數據是否最新的
從兩個維度去考慮
-
有限時間內
比如有一個用戶下單了一個操作、必須在指定的時間內給用戶響應結果、強調1s法則，不能為了保證分散式事務的一致性，需要10分鐘才能處理完，10分鐘才給用戶響應結果、在互聯網應用顯然是不能接受的。
-
返回正常結果
客戶請求了伺服器、在處理用戶請求的時候、伺服器發生了異常，不能直接丟給用戶一個 Exception、或者超時時間太長了。
客戶端請求伺服器的時候、伺服器需要做很多處理耗時長、如果要保證A可用性的話、就可以使用非同步的方式、提前給客戶響應結果
P（分區容錯性Partition）
即使系統的某個分區遇到嚴重的故障，系統能繼續提供服務。仍然需要能夠保證對外提供滿足一致性和可用性的服務、除非是整個網路環境都發生了故障
網路分區，是指分散式系統中，不同的節點分佈在不同的子網路（機房/異地網路）中，由於一些特殊的原因導致這些子網路之間出現網路不連通的狀態，但各個子網路的內部網路是正常的，從而導致整個系統的網路環境被切分成了若幹孤立的區域。組成一個分散式系統的每個節點的加入與退出都可以看做是一個特殊的網路分區。
如果發生失敗，就要在A和C之間做出選擇、要麼停止系統進行錯誤恢復，要麼繼續服務但是降低一致性，所以我們說只能保證AP或CP
CAP的應用
放棄P(Partition tolerance)
放棄分區容錯性的話，則放棄了分散式，放棄了系統的可擴展性、相當於就是一個單體應用了
放棄A(Availability)
放棄可用性的話、架構模式就是CP 、在遇到網路分區或者其他故障的時候、為了保證數據的一致性、則需要等待一定的時間或者是直接無法使用
放棄C(Consistency)
放棄一致性（指的是強一致性）、架構模式就是AP、無法保證系統數據的實時一致性、在數據達到最終一致性時，有個時間視窗，在時間視窗內，數據是不一致的。
對於分散式系統來說，P是不能放棄的，因此架構師通常是在可用性和一致性之間權衡。
CAP總結
目前大多數大型系統應用都是分散式部署的、分散式場景下中的數據一致性問題一直是一個比較重要的話題。
基於CAP理論、很多系統在設計之初就要對著三者做出取捨、任何一個分散式系統都無法同時滿足一致性(Consistency) 、可用性(Availability)、分區容錯性(Partition tolerance) 、最多只能同時滿足兩項。在互聯網領域的絕大多數的場景中，都需要犧牲強一致性來換取系統的高可用性，系統往往只需要保證最終一致性
疑問解答
為什麼分散式系統中無法同時保證一致性和可用性？
首先一個前提，對於分散式系統而言，分區容錯性是一個最基本的要求，因此基本上我們在設計分散式系統的時候只能從一致（Consistency）和可用性（Awailability）之間進行取捨
- 如果保證了一致性（C）：對於節點N1和N2，當往N1里寫數據時，N2上的操作必須被暫停，只有當N1同步數據到N2時才能對N2進行讀寫請求，在N2被暫停操作期間客戶端提交的請求會收到失敗或超時。顯然，這與可用性是相反的。
- 如果保證了可用性（A）：那就不能暫停N2的讀寫操作，但同時N1在寫數據的話，這就違背了一致性的要求。
CAP和ACID中的A和C有什麼區別？
A的區別
- ACID中的A指的是原子性（Atomicity)、表示事務被視為一個不可分割的最小工作單元、事務中的所有操作要麼全部提交成功，要麼全部失敗回滾；
- CAP中的A指的是可用性(Availability) 、是指集群中一部分節點故障後，集群整體是否還能響應客戶端的讀寫請求；
C的區別
- ACID一致性是有關資料庫規則，指的是在執行事務前後，事務外訪問數據的時候，數據是一致的，要麼看到的是成功的，要麼看到的是失敗的結果，不會多任務查詢到的數據不一樣
- CAP的一致性是分散式多伺服器之間複製數據令這些伺服器擁有同樣的數據，由於網速限制，這種複製在不同的伺服器上所消耗的時間是不固定的，集群通過組織客戶端查看不同節點上還未同步的數據維持邏輯視圖，這是一種分散式領域的一致性概念
ACID里的一致性指的是事務執行前後，資料庫完整性，而CAP的一致性，指的是分散式節點的數據的一致性。背景不同，無從可比
Base理論
BASE是CAP理論的延伸、對於一致性(Consistency)我們採用的方案是保證最終一致性。
eBay的架構師Dan Pritchett源於對大規模分散式系統的實踐總結，在ACM上發表文章提出BASE理論，BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（StrongConsistency，CAP的一致性就是強一致性），但應用可以採用適合的方式達到最終一致性（Eventual Consitency）。
Basically Available（基本可用）
在分散式系統出現故障的時候，允許損失部分可用性,支持分區失敗，即保證核心可用。
- 響應時間上的損失、出現故障的時候，響應時間增加
- 限流、當流量高峰的時候、限流保證系統的穩定性
Soft State(軟狀態)
接受一段時間的狀態不同步，及中間狀態，而改中間狀態不影響系統整體可用性。這裡的中間狀態就是CAP理論中的數據不一致性、允許系統在不同節點的數據副本之間進行數據同步的過程存在延時
最終一致性(Eventually consistency)
系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態、其本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性
主要是對AP的補充。犧牲數據的強一致性，來保證數據的可用性，雖然存在中間裝填，但數據最終一致、允許數據在一段時間內是不一致的，但最終達到一致狀態
