CAP原則 (阿里)

CAP原則又稱CAP定理，指的是在一個分佈式系統中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。

 

CAP原則又稱CAP定理，指的是在一個 分佈式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。

一致性（C）：在 分佈式系統中的全部數據備份，在同一時刻是否一樣的值。（等同於全部節點訪問同一份最新的數據副本）

可用性（A）：在集羣中一部分節點故障後， 集羣總體是否還能響應 客戶端的讀寫請求。（對數據更新具有高可用性）

分區容忍性（P）：以實際效果而言，分區至關於對通訊的時限要求。系統若是不能在時限內達成數據一致性，就意味着發生了分區的狀況，必須就當前操做在C和A之間作出選擇。

CAP原則的精髓就是要麼AP，要麼CP，要麼AC，可是不存在CAP。若是在某個分佈式系統中數據無副本， 那麼系統必然知足強一致性條件， 由於只有獨一數據，不會出現數據不一致的狀況，此時C和P兩要素具有，可是若是系統發生了網絡分區情況或者宕機，必然致使某些數據不能夠訪問，此時可用性條件就不能被知足，即在此狀況下得到了CP系統，可是CAP不可同時知足。必然致使某些數據不能夠訪問，此時可用性條件就不能被知足，即在此狀況下得到了CP系統，可是CAP不可同時知足  [1] 。

所以在進行分佈式架構設計時，必須作出取捨。當前通常是經過分佈式緩存中各節點的最終一致性來提升系統的性能，經過使用多節點之間的數據異步複製技術來實現集羣化的數據一致性。一般使用相似 memcached 之類的 NOSQL 做爲實現手段。雖然 memcached 也能夠是分佈式集羣環境的，可是對於一份數據來講，它老是存儲在某一臺 memcached 服務器上。若是發生網絡故障或是服務器死機，則存儲在這臺服務器上的全部數據都將不可訪問。因爲數據是存儲在內存中的，重啓 服務器，將致使數據所有丟失。固然也能夠本身實現一套機制，用來在分佈式 memcached 之間進行數據的同步和持久化，可是實現難度是很是大的  [2]  。

可用的抉擇

編輯

CAP理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。而因爲網絡硬件確定會出現延遲丟包等問題，因此分區容錯性是咱們必須須要實現的。因此咱們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。對於web2.0網站來講，關係數據庫的不少主要特性卻每每無用武之地。

1. 數據庫事務一致性需求
   　　不少web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。容許實現最終一致性。
2. 數據庫的寫實時性和讀實時性需求
   　　對關係數據庫來講，插入一條數據以後馬上查詢，是確定能夠讀出來這條數據的，可是對於不少web應用來講，並不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒以後，個人訂閱者纔看到這條動態是徹底能夠接受的。
3. 對複雜的SQL查詢，特別是多表關聯查詢的需求
   　　任何大數據量的web系統，都很是忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種狀況的產生。每每更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

與NoSQL的關係

編輯

傳統的關係型數據庫在功能支持上一般很寬泛，從簡單的鍵值查詢，到複雜的多表聯合查詢再到事務機制的支持。而與之不一樣的是，NoSQL系統一般注重性能和擴展性，而非事務機制（事務就是強一致性的體現）。
　　傳統的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頁面）同樣。

在計算機網絡中，這種統一性、模型以及其中的軟件都不存在。用戶看到的是實際的機器，計算機網絡並無使這些機器看起來是統一的。若是這些機器有不一樣的硬件或者不一樣的操做系統，那麼，這些差別對於用戶來講都是徹底可見的。若是一個用戶但願在一臺遠程機器上運行一個程序，那麼，他必須登錄到遠程機器上，而後在那臺機器上運行該程序。