一、概述
CAP原則又稱CAP定理，指的是在一個分布式系統中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。
CAP原則的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。
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個特性
1998年，加州大學的計算機科學家 Eric Brewer 提出，分布式系統有三個指標。
- 一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值，即寫操作之后的讀操作，必須返回該值。（分為弱一致性、強一致性和最終一致性）
- 可用性（A）：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
- 分區容忍性（P）：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
二、取舍策略
CAP三個特性只能滿足其中兩個，那么取舍的策略就共有三種：
2.1、CA without P：如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但放棄P的同時也就意味着放棄了系統的擴展性，也就是分布式節點受限，沒辦法部署子節點，這是違背分布式系統設計的初衷的。傳統的關系型數據庫RDBMS：Oracle、MySQL就是CA。
2.2、CP without A：如果不要求A（可用），相當於每個請求都需要在服務器之間保持強一致，而P（分區）會導致同步時間無限延長(也就是等待數據同步完才能正常訪問服務)，一旦發生網絡故障或者消息丟失等情況，就要犧牲用戶的體驗，等待所有數據全部一致了之后再讓用戶訪問系統。設計成CP的系統其實不少，最典型的就是分布式數據庫，如Redis、HBase等。對於這些分布式數據庫來說，數據的一致性是最基本的要求，因為如果連這個標准都達不到，那么直接采用關系型數據庫就好，沒必要再浪費資源來部署分布式數據庫。
2.3、 AP wihtout C：要高可用並允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯系，為了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品准備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統可以正常的服務，然后在數據的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗，但也不至於造成用戶購物流程的嚴重阻塞。
三、主要矛盾-Consistency和Availability
CAP理論就是說在分布式存儲系統中，最多只能實現上面的兩點。而由於網絡硬件肯定會出現延遲丟包等問題，所以分區容錯性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。對於web2.0網站來說，關系數據庫的很多主要特性卻往往無用武之地
- 數據庫事務一致性需求 —— 很多web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。允許實現最終一致性。
- 數據庫的寫實時性和讀實時性需求 —— 對關系數據庫來說，插入一條數據之后立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這么高的實時性，比方說發一條消息之 后，過幾秒乃至十幾秒之后，我的訂閱者才看到這條動態是完全可以接受的。
- 對復雜的SQL查詢，特別是多表關聯查詢的需求 —— 任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
與數據庫的關系
傳統的關系型數據庫（CA）在功能支持上通常很寬泛，從簡單的鍵值查詢，到復雜的多表聯合查詢再到事務機制的支持。而與之不同的是，NoSQL系統通常注重性能和擴展性，而非事務機制（事務就是強一致性的體現）。
傳統的SQL數據庫的事務通常都是支持ACID的強事務機制。A代表原子性，即在事務中執行多個操作是原子性的，要么事務中的操作全部執行，要么一個都不執行；C代表一致性，即保證進行事務的過程中整個數據庫的狀態是一致的，不會出現數據花掉的情況;I代表隔離性，即兩個事務不會相互影響，覆蓋彼此數據等；D表示持久化，即事務一旦完成，那么數據應該是被寫到安全的，持久化存儲的設備上（比如磁盤）。
NoSQL系統僅提供對行級別的原子性保證，也就是說同時對同一個Key下的數據進行的兩個操作，在實際執行的時候是會串行的執行，保證了每一個Key-Value對不會被破壞。
四、解決方案——BASE
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫，BASE是對CAP中一致性和可用性權衡的結果。
核心思想：即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency）。
基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性——但請注意，這絕不等價於系統不可用，以下兩個就是“基本可用”的典型例子。
- 響應時間上的損失：正常情況下，一個在線搜索引擎需要0.5秒內返回給用戶相應的查詢結果，但由於出現異常（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了1~2秒。
- 功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峰的時候，由於消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。
4.2、軟狀態Soft state
軟狀態也稱弱狀態，和硬狀態相對，是指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。
4.3、最終一致性Eventually consistent
最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步后，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
亞馬遜首席技術官Werner Vogels在於2008年發表的一篇文章中對最終一致性進行了非常詳細的介紹。他認為最終一致性時一種特殊的弱一致性：系統能夠保證在沒有其他新的更新操作的情況下，數據最終一定能夠達到一致的狀態，因此所有客戶端對系統的數據訪問都能夠胡渠道最新的值。同時，在沒有發生故障的前提下，數據達到一致狀態的時間延遲，取決於網絡延遲，系統負載和數據復制方案設計等因素。
在實際工程實踐中，最終一致性存在以下五類主要變種。
因果一致性：
因果一致性是指，如果進程A在更新完某個數據項后通知了進程B，那么進程B之后對該數據項的訪問都應該能夠獲取到進程A更新后的最新值，並且如果進程B要對該數據項進行更新操作的話，務必基於進程A更新后的最新值，即不能發生丟失更新情況。與此同時，與進程A無因果關系的進程C的數據訪問則沒有這樣的限制。
讀己之所寫：
讀己之所寫是指，進程A更新一個數據項之后，它自己總是能夠訪問到更新過的最新值，而不會看到舊值。也就是說，對於單個數據獲取者而言，其讀取到的數據一定不會比自己上次寫入的值舊。因此，讀己之所寫也可以看作是一種特殊的因果一致性。
會話一致性：
會話一致性將對系統數據的訪問過程框定在了一個會話當中：系統能保證在同一個有效的會話中實現“讀己之所寫”的一致性，也就是說，執行更新操作之后，客戶端能夠在同一個會話中始終讀取到該數據項的最新值。
單調讀一致性：
單調讀一致性是指如果一個進程從系統中讀取出一個數據項的某個值后，那么系統對於該進程后續的任何數據訪問都不應該返回更舊的值。
單調寫一致性：
單調寫一致性是指，一個系統需要能夠保證來自同一個進程的寫操作被順序地執行。
以上就是最終一致性的五類常見的變種，在時間系統實踐中，可以將其中的若干個變種互相結合起來，以構建一個具有最終一致性的分布式系統。事實上，可以將其中的若干個變種相互結合起來，以構建一個具有最終一致性特性的分布式系統。事實上，最終一致性並不是只有那些大型分布式系統才設計的特性，許多現代的關系型數據庫都采用了最終一致性模型。
在現代關系型數據庫中，大多都會采用同步和異步方式來實現主備數據復制技術。在同步方式中，數據的復制通常是更新事務的一部分，因此在事務完成后，主備數據庫的數據就會達到一致。而在異步方式中，備庫的更新往往存在延時，這取決於事務日志在主備數據庫之間傳輸的時間長短，如果傳輸時間過長或者甚至在日志傳輸過程中出現異常導致無法及時將事務應用到備庫上，那么很顯然，從備庫中讀取的的數據將是舊的，因此就出現了不一致的情況。當然，無論是采用多次重試還是認為數據訂正，關系型數據庫還是能搞保證最終數據達到一致——這就是系統提供最終一致性保證的經典案例。
總的來說，BASE理論面向的是大型高可用可擴展的分布式系統，和傳統事務的ACID特性使相反的，它完全不同於ACID的強一致性模型，而是提出通過犧牲強一致性來獲得可用性，並允許數據在一段時間內是不一致的，但最終達到一致狀態。但同時，在實際的分布式場景中，不同業務單元和組件對數據一致性的要求是不同的，因此在具體的分布式系統架構設計過程中，ACID特性與BASE理論往往又會結合在一起使用。
小結：計算機系統從集中式向分布式的變革隨着包括分布式網絡、分布式事務和分布式數據一致性等在內的一系列問題與挑戰，同時也催生了一大批諸如ACID、CAP和BASE等經典理論的快速發展。