Cap定理和Base理論

Cap 原則

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

分佈式系統的CAP理論：理論首先把分佈式系統中的三個特性進行了以下概括：

1. 一致性（Consistency）：在分佈式系統中的全部數據備份，在同一時刻是否一樣的值。（等同於全部節點訪問同一份最新的數據副本）。
2. 可用性（Availability）：在集羣中一部分節點故障後，集羣總體是否還能響應客戶端的讀寫請求。（對數據更新具有高可用性）。
3. 分區容忍性（patition tolerance）：以實際效果而言，分區至關於對通訊的時限要求，系統若是不能再時限內達成數據一致性，就意味着發生了分區的狀況。必須就當前操做在C和A之間作出選擇。

一致性與可用性的抉擇編輯

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

1.數據庫事務一致性需求

不少web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求不高，容許實現最終一致。（什麼場景？？？）

2.數據庫的寫實時性和讀實時性需求

對關係數據庫來講，插入一條數據以後馬上查詢，是確定能夠讀出來這條數據的，可是對於不少web應用來講，並不要求這麼高的實時性。好比說：發送一條消息後，過幾秒乃至十幾秒以後，個人訂閱者纔看到這條動態是徹底能夠接受的。

3.對複雜的SQL查詢，特別是多表關聯查詢的需求

　　任何大數據量的web系統，都很是忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種狀況的產生。每每更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

Base理論

BASE是 Basically Available（基本可用），Soft state （軟狀態）和Eventually Consistency（最終一致）三個詞語的簡寫。Base是對CAP中一致性和可用性權衡的結果，其來源與對大規模互聯網系統分佈式時間的結論，是基於CAP定理逐步演化而來的，其核心思想是即便沒法作到強一致性（Strong Consistency），但每一個應用均可以根據自身的業務特色，採用是低昂的方式來使系統達到最終一致性（Eventual consistency）。

基本可用（Basically Available）

基本可用是指分佈式系統在出現不可預知故障的時候，容許損失部分可用性--但注意，這毫不等價與系統不可用，如下兩個就是"基本可用"的典型例子。

1. 響應時間上的損失：正常狀況下，一個在線搜索引擎須要0.5秒內返回給用戶響應的查詢結果，但因爲出現異常（好比系統部分機房發生斷電或斷網故障），查詢結果的響應時間增長的了 1~2秒。
2. 功能上的損失：正常狀況下，在一個電子商務網站上進行購物，消費者幾乎可以順利地完成每一筆訂單，可是在一些節日大促購物高峯的時候，因爲消費者的購物行爲激增，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。

軟狀態（Soft state）

弱狀態也稱爲軟狀態，和硬狀態相對，是指容許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的總體可用性，即容許系統在不一樣節點的數據副本之間進行數據聽不的過程存在延時。

最終一致性

最終一致性強調的是系統中全部的數據副本，在通過一段時間的同步後，最終可以達到一個一致的狀態。所以，最終一致性的本質是須要系統保證最終數據可以達到一致，而不須要實時保證系統數據的強一致性 在實際工程實踐中，最終一致性存在如下五類主要變種。

因果一致性：

因果一致性是指，若是進程A在更新完某個數據項後通知了進程B，那麼進程B以後對該數據項的訪問都應該可以獲取到進程A更新後的最新值，而且若是進程B要對該數據項進行更新操做的話，務必基於進程A更新後的最新值，即不能發生丟失更新狀況。與此同時，與進程A無因果關係的進程C的數據訪問則沒有這樣的限制。

讀己之所寫：

讀己之所寫是指，進程A更新一個數據項以後，它本身老是可以訪問到更新過的最新值，而不會看到舊值。也就是說，對於單個數據獲取者而言，其讀取到的數據必定不會比本身上次寫入的值舊。所以，讀己之所寫也能夠看做是一種特殊的因果一致性。

會話一致性：

會話一致性將對系統數據的訪問過程框定在了一個會話當中：系統能保證在同一個有效的會話中實現「讀己之所寫」的一致性，也就是說，執行更新操做以後，客戶端可以在同一個會話中始終讀取到該數據項的最新值。

單調讀一致性：

單調讀一致性是指若是一個進程從系統中讀取出一個數據項的某個值後，那麼系統對於該進程後續的任何數據訪問都不該該返回更舊的值。

單調寫一致性：

單調寫一致性是指，一個系統須要可以保證來自同一個進程的寫操做被順序地執行。

總的來講，BASE理論面向的是大型高可用可擴展的分佈式系統，和傳統事務的ACID特性使相反的，它徹底不一樣於ACID的強一致性模型，而是提出經過犧牲強一致性來得到可用性，並容許數據在一段時間內是不一致的，但最終達到一致狀態。但同時，在實際的分佈式場景中，不一樣業務單元和組件對數據一致性的要求是不一樣的，所以在具體的分佈式系統架構設計過程當中，ACID特性與BASE理論每每又會結合在一塊兒使用。

爲何會是這樣

咱們來看一個簡單的問題, 一個DB服務 搭建在兩個機房（北京,廣州)，兩個DB實例同時提供寫入和讀取

1. 假設DB的更新操做是同時寫北京和廣州的DB都成功才返回成功 在沒有出現網絡故障的時候，知足CA原則，C 即個人任何一個寫入，更新操做成功並返回客戶端完成後,分佈式的全部節點在同一時間的數據徹底一致， A 即個人讀寫操做都可以成功，可是當出現網絡故障時，我不能同時保證CA，即P條件沒法知足

2. 假設DB的更新操做是隻寫本地機房成功就返回，經過binlog/oplog回放方式同步至側邊機房 這種操做保證了在出現網絡故障時,雙邊機房都是能夠提供服務的，且讀寫操做都能成功，意味着他知足了AP ，可是它不知足C，由於更新操做返回成功後，雙邊機房的DB看到的數據會存在暫時不一致，且在網絡故障時，不一致的時間差會很大（僅能保證最終一致性）

3. 假設DB的更新操做是同時寫北京和廣州的DB都成功才返回成功且網絡故障時提供降級服務 降級服務，如中止寫入，只提供讀取功能，這樣能保證數據是一致的，且網絡故障時能提供服務，知足CP原則，可是他沒法知足可用性原則

選擇權衡

經過上面的例子，咱們得知，咱們永遠沒法同時獲得CAP這3個特性，那麼咱們怎麼來權衡選擇呢？ 選擇的關鍵點取決於業務場景

對於大多數互聯網應用來講（如網易門戶），由於機器數量龐大，部署節點分散，網絡故障是常態，可用性是必須須要保證的，因此只有設置一致性來保證服務的AP，一般常見的高可用服務吹噓5個9 6個9服務SLA穩定性就本都是放棄C選擇AP

對於須要確保強一致性的場景，如銀行，一般會權衡CA和CP模型，CA模型網絡故障時徹底不可用，CP模型具有部分可用性，實際的選擇須要經過業務場景來權衡（並非全部狀況CP都好於CA，只能查看信息不能更新信息有時候從產品層面還不如直接拒絕服務）

分佈式系統的典型應用

分佈式系統是一個很是普遍的概念，它最終要落實到解決實際問題上，不一樣的問題有不一樣的方法和架構。全部的開源軟件都是以某個應用場景出現，而純粹以「分佈式」概念進行劃分的比較少見。 但若是以算法劃分，到能分出幾類：

1.以Leader選舉爲主的一類算法，好比paxos、viewstamp，就是如今zookeeper、Chuby等工具的主體

2.以分佈式事務爲主的一類主要是二段提交，這些分佈式數據庫管理器及數據庫都支持

3.以若一致性爲主的，主要表明是Cassandra的W、R、N可調節的一致性

4.以租賃機制爲主的，主要是一些分佈式鎖的概念，目前尚未看到純粹「分佈式」鎖的實現

5.以失敗探測爲主的，主要是Gossip和phi失敗探測算法，固然也包括簡單的心跳

6.以弱一致性、因果一致性、順序一致性爲主的，開源尚很少，但大都應用在Linkedin、Twitter、Facebook等公司內部

7固然以異步解耦爲主的，還有各種Queue

5、ACID和BASE的區別與聯繫

ACID是傳統數據庫經常使用的設計理念，追求強一致性模型。BASE支持的是大型分佈式系統，提出經過犧牲強一致性得到高可用性。

ACID和BASE表明了兩種截然相反的設計哲學，在分佈式系統設計的場景中，系統組件對一致性要求是不一樣的，所以ACID和BASE又會結合使用。