基本介紹
- 中文名：CAP原則
- 外文名：CAP Principle
- 學科：計算機科學
- 特性：一致性、可用性、分區容忍性
- 套用：分散式系統
- 特點：最多只能同時實現兩點
簡介,可用的抉擇,與NoSQL的關係,與BASE的關係,分散式系統,
簡介
CAP原則又稱CAP定理，指的是在一個分散式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
一致性（C）：在分散式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
分區容忍性（P）：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。
CAP原則的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某個分散式系統中數據無副本， 那么系統必然滿足強一致性條件， 因為只有獨一數據，不會出現數據不一致的情況，此時C和P兩要素具備，但是如果系統發生了網路分區狀況或者宕機，必然導致某些數據不可以訪問，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統，但是CAP不可同時滿足。必然導致某些數據不可以訪問，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統，但是CAP不可同時滿足。
因此在進行分散式架構設計時，必須做出取捨。當前一般是通過分散式快取中各節點的最終一致性來提高系統的性能，通過使用多節點之間的數據異步複製技術來實現集群化的數據一致性。通常使用類似 memcached 之類的 NOSQL 作為實現手段。雖然 memcached 也可以是分散式集群環境的，但是對於一份數據來說，它總是存儲在某一台 memcached 伺服器上。如果發生網路故障或是伺服器當機，則存儲在這台伺服器上的所有數據都將不可訪問。由於數據是存儲在記憶體中的，重啟伺服器，將導致數據全部丟失。當然也可以自己實現一套機制，用來在分散式 memcached 之間進行數據的同步和持久化，但是實現難度是非常大的。
可用的抉擇
CAP理論就是說在分散式存儲系統中，最多只能實現上面的兩點。而由於網路硬體肯定會出現延遲丟包等問題，所以分區容錯性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。對於web2.0網站來說，關係資料庫的很多主要特性卻往往無用武之地。
- 資料庫事務一致性需求
很多web實時系統並不要求嚴格的資料庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。允許實現最終一致性。 - 資料庫的寫實時性和讀實時性需求
對關係資料庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web套用來說，並不要求這么高的實時性，比方說發一條訊息之 後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動態是完全可以接受的。 - 對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
與NoSQL的關係
傳統的關係型資料庫在功能支持上通常很寬泛，從簡單的鍵值查詢，到複雜的多表聯合查詢再到事務機制的支持。而與之不同的是，NoSQL系統通常注重性能和擴展性，而非事務機制（事務就是強一致性的體現）。
傳統的SQL資料庫的事務通常都是支持ACID的強事務機制。A代表原子性，即在事務中執行多個操作是原子性的，要么事務中的操作全部執行，要么一個都不執行；C代表一致性，即保證進行事務的過程中整個資料庫的狀態是一致的，不會出現數據花掉的情況；I代表隔離性，即兩個事務不會相互影響，覆蓋彼此數據等；D表示持久化，即事務一旦完成，那么數據應該是被寫到安全的，持久化存儲的設備上（比如磁碟）。
NoSQL系統僅提供對行級別的原子性保證，也就是說同時對同一個Key下的數據進行的兩個操作，在實際執行的時候是會串列的執行，保證了每一個Key-Value對不會被破壞。
傳統的SQL資料庫的事務通常都是支持ACID的強事務機制。A代表原子性，即在事務中執行多個操作是原子性的，要么事務中的操作全部執行，要么一個都不執行；C代表一致性，即保證進行事務的過程中整個資料庫的狀態是一致的，不會出現數據花掉的情況；I代表隔離性，即兩個事務不會相互影響，覆蓋彼此數據等；D表示持久化，即事務一旦完成，那么數據應該是被寫到安全的，持久化存儲的設備上（比如磁碟）。
NoSQL系統僅提供對行級別的原子性保證，也就是說同時對同一個Key下的數據進行的兩個操作，在實際執行的時候是會串列的執行，保證了每一個Key-Value對不會被破壞。
與BASE的關係
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫。
BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模網際網路系統分散式實踐的結論，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個套用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。接下來我們著重對BASE中的三要素進行詳細講解。基本可用：指分散式系統在出現不可預知故障的時候，允許損失部分可用性。
注意，這絕不等價於系統不可用，以下兩個就是“基本可用”的典型例子：
回響時間上的損失：正常情況下，一個線上搜尋引擎需要0.5秒內返回給用戶相應的查詢結果，但由於出現異常（比如系統部分機房發生斷電或斷網故障），查詢結果的回響時間增加到了1~2秒。
功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峰的時候，由於消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。
弱狀態：也稱為軟狀態，和硬狀態相對，是指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。
最終一致性：強調的是系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
分散式系統
分散式系統（distributed system）是建立在網路之上的軟體系統。正是因為軟體的特性，所以分散式系統具有高度的內聚性和透明性。因此，網路和分散式系統之間的區別更多的在於高層軟體（特別是作業系統），而不是硬體。在一個分散式系統中，一組獨立的計算機展現給用戶的是一個統一的整體，就好像是一個系統似的。系統擁有多種通用的物理和邏輯資源，可以動態的分配任務，分散的物理和邏輯資源通過計算機網路實現信息交換。系統中存在一個以全局的方式管理計算機資源的分散式作業系統。通常，對用戶來說，分散式系統只有一個模型或范型。在作業系統之上有一層軟體中間件（middleware）負責實現這個模型。一個著名的分散式系統的例子是全球資訊網（World Wide Web），在全球資訊網中，所有的一切看起來就好像是一個文檔（Web頁面）一樣。
在計算機網路中，這種統一性、模型以及其中的軟體都不存在。用戶看到的是實際的機器，計算機網路並沒有使這些機器看起來是統一的。如果這些機器有不同的硬體或者不同的作業系統，那么，這些差異對於用戶來說都是完全可見的。如果一個用戶希望在一台遠程機器上運行一個程式，那么，他必須登入到遠程機器上，然後在那台機器上運行該程式。
