系統架構師知識:什麼是CAP

CAP、BASE理論是當前在互聯網領域非常流行的NoSQL的理論基礎。那麼什麼是CAP呢?我們一起來了解一下!

系統架構師知識:什麼是CAP

  1、什麼是CAP

著名的CAP理論是由Brewer提出的,所謂CAP,即一致性(Consistency)、可用性(Availability)和分區容錯性(Partition Tolerance)。

(1)、Consistency(一致性):更新操作成功並返回客戶端完成後,分佈式的所有節點在同一時間的數據完全一致(All nodes see the same data at the same time)。

這裏的一致性,一定要和傳統的RDBMS中的事務一致性區分開。

在傳統的RDBMS中,事務具有ACID4個屬性,即原子性(Atomicity),一致性(Consistency),隔離性(Isolation)和持久性(Durable)。

ACID是關係型數據庫的最基本原則,遵循ACID原則強調一致性,對成本要求很高,對性能影響很大。

a、原子性(Atomicity):事務是一個原子操作單元,其對數據的修改,要麼全都執行,要麼全都不執行。

b、一致性(Consistency):在事務開始和完成時,數據都必須保持一致狀態。這意味着所有相關的數據規則都必須應用於事務的修改,以保持數據的完整性;事務結束時,所有的內部數據結構(如B樹索引或雙向鏈表)也都必須是正確的。

c、隔離性(Isolation):數據庫系統提供一定的隔離機制,保證事務在不受外部併發操作影響的“獨立”環境執行。這意味着事務處理過程中的中間狀態對外部是不可見的,反之亦然。

d、持久性(Durability):事務完成之後,它對於數據的修改是永久性的,即使出現系統故障也能夠保持。

MIT的Gilbert和Lynch在證明CAP的過程中改變了Consistency的概念,也就是將Consistency轉化爲Atomic。Gilbert認爲這裏所說的Consistency其實就是數據庫系統中提到的ACID的另一種表述:一個用戶請求要麼成功、要麼失敗,不能處於中間狀態(Atomic);一旦一個事務完成,將來的所有事務都必須基於這個完成後的狀態(Consistent);未完成的事務不會互相影響(Isolated);一旦一個事務完成,就是持久的(Durable)。

(2)、Availability(可用性):讀和寫操作都能成功(Reads and writes always succeed)。

可用性是說服務能一直保證是可用的狀態,當用戶發出一個請求,服務能在有限時間內返回結果,所有的請求都能“成功”拿到對應的響應。

(3)、Partition Tolerance(分區容錯性):在出現網絡故障導致分佈式節點間不能通信時,系統能否繼續服務(The system continues to operate despite arbitrary message loss or failure of part of the system)。

直觀感受就是系統中節點crash或者網絡分片都不應該導致一個分佈式系統停止服務。

  2、如何證明CAP?

CAP的證明很簡單:

假設兩個節點集{G1, G2},由於網絡分片導致G1和G2之間所有的通訊都斷開了。

如果在G1中寫,在G2中讀剛寫的數據, G2中返回的值不可能是剛剛在G1中的寫值。

對於分佈式數據系統而言,分區容錯性(Partition Tolerance)是基本要求,否則就不稱其爲分佈式系統。

由於可用性(Availability)的'要求,G2一定要返回這次讀請求,因爲分區容錯性(Partition Tolerance)的存在,導致一致性(Consistency)一定是不可滿足的。

CAP理論告訴我們,一個分佈式系統不可能同時滿足一致性,可用性和分區容錯性這三個需求,三個要素中最多隻能同時滿足兩點。

顯然,任何橫向擴展策略都要依賴於數據分區,軟件架構通常必須在一致性(Consistency)與可用性(Availability)之間做出選擇。

  3、CAP的延伸BASE

BASE是Basically Available、Soft state、Eventually consistent三個詞組的簡寫,是對CAP中C 和A的延伸。

(1)Basically Available:基本可用,即數據一致性能夠基本滿足二八定律,即至少保證80%一致性,剩下20%就不要過於糾結。

(2)Soft-state:軟狀態/柔性事務,即狀態可以有一段時間的不同步

在不過分追求數據一致性(強一致性)前提下可考慮軟狀態策略,例如把數據(State)緩存在客戶端一段時間,在一段時間過後,如果客戶端沒有再次刷新狀態的請求的話,就清除此緩存(Soft),這個狀態就會消失。

(3)Eventual consistency:最終一致性,即在某一段短時間內允許數據不一致,但經過一段較長時間(這裏的一段時間多數是業務能夠容忍的延遲),等所有節點上數據的拷貝都整合在一起的時候,數據會最終達到完全一致。我用自己的經驗和親身實踐證明,最終一致性貫穿着互聯網尤其是電子商務類型的主要應用的生命週期。

BASE來自於互聯網的電子商務領域的實踐,它是基於CAP理論逐步演化而來,核心思想是即便不能達到強一致性(Strong Consistency),但可以根據應用特點採用適當的方式來達到最終一致性(Eventual consistency)的效果。BASE是反ACID的,它完全不同於ACID模型,犧牲強一致性,獲得基本可用性和柔性可靠性並要求達到最終一致性。