CAP特性與Base理論

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的補充，犧牲資料的強一致性，來保證資料的可用性，雖然存在中間裝填，但資料最終一致、允許資料在一段時間內是不一致的，但最終達到一致狀態

標籤：架構設計

上一篇：讀編程與型別系統筆記08_面向物件變成的元素

下一篇：CAP特性與Base理論