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頁面）一樣。

在計算機網絡中，這種統一性、模型以及其中的軟件都不存在。用戶看到的是實際的機器，計算機網絡並沒有使這些機器看起來是統一的。如果這些機器有不同的硬件或者不同的操作系統，那么，這些差異對於用戶來說都是完全可見的。如果一個用戶希望在一台遠程機器上運行一個程序，那么，他必須登陸到遠程機器上，然后在那台機器上運行該程序。