CAP原則(CAP定理)、BASE理論

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

　　CAP原則是NOSQL資料庫的基石。Consistency（一緻性）。 Availability（可用性）。Partition tolerance（分區容錯性）。

分布式系統的CAP理論：理論首先把分布式系統中的三個特性進行了如下歸納：

一緻性（C）：在分布式系統中的所有資料備份，在同一時刻是否同樣的值。（等同于所有節點通路同一份最新的資料副本）

可用性（A）：在叢集中一部分節點故障後，叢集整體是否還能響應用戶端的讀寫請求。（對資料更新具備高可用性）

分區容忍性（P）：以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限内達成資料一緻性，就意味着發生了分區的情況，必須就目前操作在C和A之間做出選擇。

CAP理論就是說在分布式存儲系統中，最多隻能實作上面的兩點。而由于目前的網絡硬體肯定會出現延遲丢包等問題，是以分區容忍性是我們必須需要實作的。是以我們隻能在一緻性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。

對于web2.0網站來說，關系資料庫的很多主要特性卻往往無用武之地

資料庫事務一緻性需求 

　　很多web實時系統并不要求嚴格的資料庫事務，對讀一緻性的要求很低，有些場合對寫一緻性要求并不高。允許實作最終一緻性。

資料庫的寫實時性和讀實時性需求

　　對關系資料庫來說，插入一條資料之後立刻查詢，是肯定可以讀出來這條資料的，但是對于很多web應用來說，并不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動态是完全可以接受的。

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

　　任何大資料量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的資料分析類型的報表查詢，特别是SNS類型的網站，從需求以及産品設計角 度，就避免了這種情況的産生。往往更多的隻是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

BASE是Basically Available（基本可用）、Soft state（軟狀态）和Eventually consistent（最終一緻性）三個短語的簡寫，BASE是對CAP中一緻性和可用性權衡的結果，其來源于對大規模網際網路系統分布式實踐的結論，是基于CAP定理逐漸演化而來的，其核心思想是即使無法做到強一緻性（Strong consistency），但每個應用都可以根據自身的業務特點，采用适當的方式來使系統達到最終一緻性（Eventual consistency）。接下來我們着重對BASE中的三要素進行詳細講解。

基本可用

基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性——但請注意，這絕不等價于系統不可用，以下兩個就是“基本可用”的典型例子。

響應時間上的損失：正常情況下，一個線上搜尋引擎需要0.5秒内傳回給使用者相應的查詢結果，但由于出現異常（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了1~2秒。

功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峰的時候，由于消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。

弱狀态也稱為軟狀态，和硬狀态相對，是指允許系統中的資料存在中間狀态，并認為該中間狀态的存在不會影響系統的整體可用性，即允許系統在不同節點的資料副本之間進行資料聽不的過程存在延時。

最終一緻性

最終一緻性強調的是系統中所有的資料副本，在經過一段時間的同步後，最終能夠達到一個一緻的狀态。是以，最終一緻性的本質是需要系統保證最終資料能夠達到一緻，而不需要實時保證系統資料的強一緻性

亞馬遜首席技術官Werner Vogels在于2008年發表的一篇文章中對最終一緻性進行了非常詳細的介紹。他認為最終一緻性時一種特殊的弱一緻性：系統能夠保證在沒有其他新的更新操作的情況下，資料最終一定能夠達到一緻的狀态，是以所有用戶端對系統的資料通路都能夠胡管道最新的值。同時，在沒有發生故障的前提下，資料達到一緻狀态的時間延遲，取決于網絡延遲，系統負載和資料複制方案設計等因素。

在實際工程實踐中，最終一緻性存在以下五類主要變種。

因果一緻性：

        因果一緻性是指，如果程序A在更新完某個資料項後通知了程序B，那麼程序B之後對該資料項的通路都應該能夠擷取到程序A更新後的最新值，并且如果程序B要對該資料項進行更新操作的話，務必基于程序A更新後的最新值，即不能發生丢失更新情況。與此同時，與程序A無因果關系的程序C的資料通路則沒有這樣的限制。

讀己之所寫：

        讀己之所寫是指，程序A更新一個資料項之後，它自己總是能夠通路到更新過的最新值，而不會看到舊值。也就是說，對于單個資料擷取者而言，其讀取到的資料一定不會比自己上次寫入的值舊。是以，讀己之所寫也可以看作是一種特殊的因果一緻性。

會話一緻性：

        會話一緻性将對系統資料的通路過程框定在了一個會話當中：系統能保證在同一個有效的會話中實作“讀己之所寫”的一緻性，也就是說，執行更新操作之後，用戶端能夠在同一個會話中始終讀取到該資料項的最新值。

單調讀一緻性：

        單調讀一緻性是指如果一個程序從系統中讀取出一個資料項的某個值後，那麼系統對于該程序後續的任何資料通路都不應該傳回更舊的值。

單調寫一緻性：

         單調寫一緻性是指，一個系統需要能夠保證來自同一個程序的寫操作被順序地執行。

以上就是最終一緻性的五類常見的變種，在時間系統實踐中，可以将其中的若幹個變種互相結合起來，以建構一個具有最終一緻性的分布式系統。事實上，可以将其中的若幹個變種互相結合起來，以建構一個具有最終一緻性特性的分布式系統。事實上，最終一緻性并不是隻有那些大型分布式系統才設計的特性，許多現代的關系型資料庫都采用了最終一緻性模型。在現代關系型資料庫中，大多都會采用同步和異步方式來實作主備資料複制技術。在同步方式中，資料的複制國恥鞥通常是更新事務的一部分，是以在事務完成後，主備資料庫的資料就會達到一緻。而在異步方式中，備庫的更新往往存在延時，這取決于事務日志在主備資料庫之間傳輸的時間長短，如果傳輸時間過長或者甚至在日志傳輸過程中出現異常導緻無法及時将事務應用到備庫上，那麼狠顯然，從備庫中讀取的的資料将是舊的，是以就出現了不一緻的情況。當然，無論是采用多次重試還是認為資料訂正，關系型資料庫還是能搞保證最終資料達到一緻——這就是系統提供最終一緻性保證的經典案例。

總的來說，BASE理論面向的是大型高可用可擴充的分布式系統，和傳統事務的ACID特性使相反的，它完全不同于ACID的強一緻性模型，而是提出通過犧牲強一緻性來獲得可用性，并允許資料在一段時間内是不一緻的，但最終達到一緻狀态。但同時，在實際的分布式場景中，不同業務單元群組件對資料一緻性的要求是不同的，是以在具體的分布式系統架構設計過程中，ACID特性與BASE理論往往又會結合在一起使用。

計算機系統從集中式向分布式的變革随着包括分布式網絡、分布式事務和分布式資料一緻性等在内的一系列問題與挑戰，同時也催生了一大批諸如ACID、CAP和BASE等經典理論的快速發展。

傳統的關系型資料庫在功能支援上通常很寬泛，從簡單的鍵值查詢，到複雜的多表聯合查詢再到事務機制的支援。而與之不同的是，NoSQL系統通常注重性能和擴充性，而非事務機制（事務就是強一緻性的展現）[2]  。

　　傳統的SQL資料庫的事務通常都是支援ACID的強事務機制。A代表原子性，即在事務中執行多個操作是原子性的，要麼事務中的操作全部執行，要麼一個都不執行;C代表一緻性，即保證進行事務的過程中整個資料加的狀态是一緻的，不會出現資料花掉的情況;I代表隔離性，即兩個事務不會互相影響，覆寫彼此資料等;D表示持久化，即事務一量完成，那麼資料應該是被寫到安全的，持久化存儲的裝置上（比如磁盤）。

　　NoSQL系統僅提供對行級别的原子性保證，也就是說同時對同一個Key下的資料進行的兩個操作，在實際執行的時候是會串行的執行，保證了每一個Key-Value對不會被破壞。

It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in every system, unfortunately no system can achieve all three at the same time.

在分布式系統的設計中，沒有一種設計可以同時滿足一緻性，可用性，分區容錯性 3個特性

注意：不要将弱一緻性，最終一緻性放到CAP理論裡混為一談（混淆概念的坑真多）

弱一緻性，最終一緻性 你可以認為和CAP的C一點關系也沒有，因為CAP的C是更新操作完成後，任何節點看到的資料完全一緻, 弱一緻性。最終一緻性本身和CAP的C一緻性是違背的，是以你可以看到那些謊稱自己系統同時具備CAP 3個特性是多麼的可笑，可能國内更多的場景是：一個開放人員一旦走上講台演講，就立馬轉變為了營銷人員，連最基本的理念也不要了。

實際上本文的changed更多的是在思考方式上，而本身CAP理論是沒有changed的

我們來看一個簡單的問題, 一個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，隻能檢視資訊不能更新資訊有時候從産品層面還不如直接拒絕服務）

延伸

BASE(Basically Available, Soft State, Eventual Consistency  基本可用、軟狀态、最終一緻性) 對CAP AP理論的延伸, Redis等衆多系統建構與這個理論之上

ACID  傳統資料庫常用的設計理念, ACID和BASE代表了兩種截然相反的設計哲學，分處一緻性-可用性分布圖譜的兩極。

分布式系統是一個非常廣泛的概念，它最終要落實到解決實際問題上，不同的問題有不同的方法和架構。所有的開源軟體都是以某個應用場景出現，而純粹以“分布式”概念進行劃分的比較少見。

但如果以算法劃分，到能分出幾類：

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

2.以分布式事務為主的一類主要是二段送出，這些分布式資料庫管理器及資料庫都支援

3.以若一緻性為主的，主要代表是Cassandra的W、R、N可調節的一緻性

4.以租賃機制為主的，主要是一些分布式鎖的概念，目前還沒有看到純粹“分布式”鎖的實作

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

6.以弱一緻性、因果一緻性、順序一緻性為主的，開源尚不多，但大都應用在Linkedin、Twitter、Facebook等公司内部

7當然以異步解耦為主的，還有各類Queue