複製鏈接
請複製以下鏈接發送給好友

CAP原則

鎖定
CAP原則又稱CAP定理,指的是在一個分佈式系統中,一致性(Consistency)、可用性(Availability)、分區容錯性(Partition tolerance)。CAP 原則指的是,這三個要素最多隻能同時實現兩點,不可能三者兼顧。
中文名
CAP原則
外文名
CAP Principle
學    科
計算機科學
特    性
一致性、可用性、分區容忍性
應    用
分佈式系統
特    點
最多隻能同時實現兩點

CAP原則簡介

CAP原則又稱CAP定理,指的是在一個分佈式系統中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分區容錯性),三者不可得兼。
一致性(C):在分佈式系統中的所有數據備份,在同一時刻是否同樣的值。(等同於所有節點訪問同一份最新的數據副本)
可用性(A):保證每個請求不管成功或者失敗都有響應。
分區容忍性(P):系統中任意信息的丟失或失敗不會影響系統的繼續運作。 [1] 
CAP原則的精髓就是要麼AP,要麼CP,要麼AC,但是不存在CAP。如果在某個分佈式系統中數據無副本, 那麼系統必然滿足強一致性條件, 因為只有獨一數據,不會出現數據不一致的情況,此時C和P兩要素具備,但是如果系統發生了網絡分區狀況或者宕機,必然導致某些數據不可以訪問,此時可用性條件就不能被滿足,即在此情況下獲得了CP系統,但是CAP不可同時滿足 [2] 
因此在進行分佈式架構設計時,必須做出取捨。當前一般是通過分佈式緩存中各節點的最終一致性來提高系統的性能,通過使用多節點之間的數據異步複製技術來實現集羣化的數據一致性。通常使用類似 memcached 之類的 NOSQL 作為實現手段。雖然 memcached 也可以是分佈式集羣環境的,但是對於一份數據來説,它總是存儲在某一台 memcached 服務器上。如果發生網絡故障或是服務器死機,則存儲在這台服務器上的所有數據都將不可訪問。由於數據是存儲在內存中的,重啓服務器,將導致數據全部丟失。當然也可以自己實現一套機制,用來在分佈式 memcached 之間進行數據的同步和持久化,但是實現難度是非常大的 [3] 

CAP原則可用的抉擇

CAP理論就是説在分佈式存儲系統中,最多隻能實現上面的兩點。而由於網絡硬件肯定會出現延遲丟包等問題,所以分區容錯性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡,沒有NoSQL系統能同時保證這三點。對於web2.0網站來説,關係數據庫的很多主要特性卻往往無用武之地。
  1. 數據庫事務一致性需求  很多web實時系統並不要求嚴格的數據庫事務,對讀一致性的要求很低,有些場合對寫一致性要求並不高。允許實現最終一致性。
  2. 數據庫的寫實時性和讀實時性需求  對關係數據庫來説,插入一條數據之後立刻查詢,是肯定可以讀出來這條數據的,但是對於很多web應用來説,並不要求這麼高的實時性,比方説發一條消息之 後,過幾秒乃至十幾秒之後,我的訂閲者才看到這條動態是完全可以接受的。
  3. 對複雜的SQL查詢,特別是多表關聯查詢的需求  任何大數據量的web系統,都非常忌諱多個大表的關聯查詢,以及複雜的數據分析類型的報表查詢,特別是SNS類型的網站,從需求以及產品設計角 度,就避免了這種情況的產生。往往更多的只是單表的主鍵查詢,以及單表的簡單條件分頁查詢,SQL的功能被極大的弱化了。

CAP原則與NoSQL的關係

傳統的關係型數據庫在功能支持上通常很寬泛,從簡單的鍵值查詢,到複雜的多表聯合查詢再到事務機制的支持。而與之不同的是,NoSQL系統通常注重性能和擴展性,而非事務機制(事務就是強一致性的體現)。
傳統的SQL數據庫的事務通常都是支持ACID的強事務機制。A代表原子性,即在事務中執行多個操作是原子性的,要麼事務中的操作全部執行,要麼一個都不執行;C代表一致性,即保證進行事務的過程中整個數據庫的狀態是一致的,不會出現數據花掉的情況;I代表隔離性,即兩個事務不會相互影響,覆蓋彼此數據等;D表示持久化,即事務一旦完成,那麼數據應該是被寫到安全的,持久化存儲的設備上(比如磁盤)。
NoSQL系統僅提供對行級別的原子性保證,也就是説同時對同一個Key下的數據進行的兩個操作,在實際執行的時候是會串行的執行,保證了每一個Key-Value對不會被破壞。

CAP原則與BASE的關係

BASE是Basically Available(基本可用)、Soft state(軟狀態)和Eventually consistent(最終一致性)三個短語的簡寫。
BASE是對CAP中一致性和可用性權衡的結果,其來源於對大規模互聯網系統分佈式實踐的結論,是基於CAP定理逐步演化而來的,其核心思想是即使無法做到強一致性(Strong consistency),但每個應用都可以根據自身的業務特點,採用適當的方式來使系統達到最終一致性(Eventual consistency)。接下來我們着重對BASE中的三要素進行詳細講解。基本可用:指分佈式系統在出現不可預知故障的時候,允許損失部分可用性。
注意,這絕不等價於系統不可用,以下兩個就是“基本可用”的典型例子:
響應時間上的損失:正常情況下,一個在線搜索引擎需要0.5秒內返回給用户相應的查詢結果,但由於出現異常(比如系統部分機房發生斷電或斷網故障),查詢結果的響應時間增加到了1~2秒。
功能上的損失:正常情況下,在一個電子商務網站上進行購物,消費者幾乎能夠順利地完成每一筆訂單,但是在一些節日大促購物高峯的時候,由於消費者的購物行為激增,為了保護購物系統的穩定性,部分消費者可能會被引導到一個降級頁面。
弱狀態:也稱為軟狀態,和硬狀態相對,是指允許系統中的數據存在中間狀態,並認為該中間狀態的存在不會影響系統的整體可用性,即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。
最終一致性:強調的是系統中所有的數據副本,在經過一段時間的同步後,最終能夠達到一個一致的狀態。因此,最終一致性的本質是需要系統保證最終數據能夠達到一致,而不需要實時保證系統數據的強一致性。

CAP原則分佈式系統

分佈式系統(distributed system)是建立在網絡之上的軟件系統。正是因為軟件的特性,所以分佈式系統具有高度的內聚性和透明性。因此,網絡和分佈式系統之間的區別更多的在於高層軟件(特別是操作系統),而不是硬件。在一個分佈式系統中,一組獨立的計算機展現給用户的是一個統一的整體,就好像是一個系統似的。系統擁有多種通用的物理和邏輯資源,可以動態的分配任務,分散的物理和邏輯資源通過計算機網絡實現信息交換。系統中存在一個以全局的方式管理計算機資源的分佈式操作系統。通常,對用户來説,分佈式系統只有一個模型或範型。在操作系統之上有一層軟件中間件(middleware)負責實現這個模型。一個著名的分佈式系統的例子是萬維網(World Wide Web),在萬維網中,所有的一切看起來就好像是一個文檔(Web頁面)一樣。
在計算機網絡中,這種統一性、模型以及其中的軟件都不存在。用户看到的是實際的機器,計算機網絡並沒有使這些機器看起來是統一的。如果這些機器有不同的硬件或者不同的操作系統,那麼,這些差異對於用户來説都是完全可見的。如果一個用户希望在一台遠程機器上運行一個程序,那麼,他必須登陸到遠程機器上,然後在那台機器上運行該程序。
參考資料