5.5 NoSQL的三大基石
所謂的CAP指的是：
C（Consistency）：一致性，是指任何一個讀操作總是能夠讀到之前完成的寫操作的結果。也就是在分布式環境中，多點的數據是一致的，或者說，所有節點在同一時間(讀寫應該是單線程的，否則寫過程的流水線復制過程中各數據節點內容可能不一致)具有相同的數據
A:（Availability）：可用性，可以在確定的時間內返回操作結果，保證每個請求不管成功或者失敗都有響應；
P（Tolerance of Network Partition）：分區容忍性，是指當出現網絡分區的情況時（即系統中的一部分節點無法和其他節點進行通信），分離的系統也能夠正常運行，也就是說，系統中任意信息的丟失或失敗不會影響系統的繼續運作。
5.5.1 CAP
CAP理論告訴我們，一個分布式系統不可能同時滿足一致性、可用性和分區容忍性這三個需求，最多只能同時滿足其中兩個，正所謂“魚和熊掌不可兼得”。
舉例，為滿足一致性，需要確保多副本數據一致，就使得多副本寫數據過程中無法響應讀請求。所以，NOSql數據庫都不能同時滿足CA(一致性和可用性)兩個要求。關系型數據庫可同時滿足CA(一致性和可用性)。典型的NOSql數據庫Redis、HBase、MongoDB、Neo4j都不能滿足CA特性，可滿足CP特性。
當處理CAP的問題時，可以有幾個明顯的選擇：
CA：也就是強調一致性（C）和可用性（A），放棄分區容忍性（P），最簡單的做法是把所有與事務相關的內容都放到同一台機器上。很顯然，這種做法會嚴重影響系統的可擴展性。傳統的關系數據庫（MySQL、SQL Server和PostgreSQL），都采用了這種設計原則，因此，擴展性都比較差
CP：也就是強調一致性（C）和分區容忍性（P），放棄可用性（A），當出現網絡分區的情況時，受影響的服務需要等待數據一致，因此在等待期間就無法對外提供服務
AP：也就是強調可用性（A）和分區容忍性（P），放棄一致性（C），允許系統返回不一致的數據
圖5-5 不同產品在CAP理論下的不同設計原則
5.5.2 BASE
一個數據庫事務具有ACID四性：
A（Atomicity）：原子性，是指事務必須是原子工作單元，對於其數據修改(包括新增，修改，刪除數據)，要么全都執行，要么全都不執行
C（Consistency）：一致性，是指事務在完成時，必須使所有的數據都保持一致狀態
I（Isolation）：隔離性，是指由並發事務所做的修改必須與任何其它並發事務所做的修改隔離
D（Durability）：持久性，是指事務完成之后，它對於系統的影響是永久性的，該修改即使出現致命的系統故障也將一直保持
BASE的基本含義是基本可用（Basically Availble）、軟狀態（Soft-state）和最終一致性（Eventual consistency）：
1、基本可用
基本可用，是指一個分布式系統的一部分發生問題變得不可用時，其他部分仍然可以正常使用，也就是允許分區失敗的情形出現
2、軟狀態
“軟狀態（soft-state）”是與“硬狀態（hard-state）”相對應的一種提法。數據庫保存的數據是“硬狀態”時，可以保證數據一致性，即保證數據一直是正確的。“軟狀態”是指狀態可以有一段時間不同步，具有一定的滯后性
3、最終一致性
一致性的類型包括強一致性和弱一致性，二者的主要區別在於高並發的數據訪問操作下，后續操作是否能夠獲取最新的數據。對於強一致性而言，當執行完一次更新操作后，后續的其他讀操作就可以保證讀到更新后的最新數據；反之，如果不能保證后續訪問讀到的都是更新后的最新數據，那么就是弱一致性。而最終一致性只不過是弱一致性的一種特例，允許后續的訪問操作可以暫時讀不到更新后的數據，但是經過一段時間之后，必須最終讀到更新后的數據。
最常見的實現最終一致性的系統是DNS（域名系統）。一個域名更新操作根據配置的形式被分發出去，並結合有過期機制的緩存；最終所有的客戶端可以看到最新的值。
備注：軟狀態關注數據在不同節點間同步的滯后性(關注同步狀態)，最終一致性關注不同節點數據最終一致(關注最終結果)
5.5.3 最終一致性
如何實現各種類型的一致性？
對於分布式數據系統：
N — 數據復制的份數
W — 更新數據是需要保證寫完成的節點數(一個寫操作，只有W個節點都寫成功，本次寫操作才返回成功)
R — 讀取數據的時候需要讀取的節點數(一個讀操作，只有R個節點都讀成功，本次讀操作才返回成功)
如果W+R>N，寫的節點和讀的節點重疊(可保證至少讀取的一個節點數據是最新寫入的數據)，則是強一致性。例如對於典型的一主一備同步復制的關系型數據庫，N=2,W=2,R=1，則不管讀的是主庫還是備庫的數據，都是一致的。一般設定是R＋W = N+1，這是保證強一致性的最小設定
如果W+R<=N，則是弱一致性(讀取的R個節點，不能保證至少讀取的一個節點數據是最新寫入的數據)。例如對於一主一備異步復制的關系型數據庫，N=2,W=1,R=1，則如果讀的是備庫，就可能無法讀取主庫已經更新過的數據，所以是弱一致性。
對於分布式系統，為了保證高可用性，一般設置N>=3。不同的N,W,R組合，是在可用性和一致性之間取一個平衡，以適應不同的應用場景。
如果N=W,R=1，任何一個寫節點失效，都會導致寫失敗，因此可用性會降低，但是由於數據分布的N個節點是同步寫入的，因此可以保證強一致性。
實例：HBase是借助其底層的HDFS來實現其數據冗余備份的。HDFS采用的就是強一致性保證。在數據沒有完全同步到N個節點前，寫操作是不會返回成功的。也就是說它的W＝N，而讀操作只需要讀到一個值即可，也就是說它R＝1。
像Voldemort，Cassandra和Riak這些類Dynamo的系統，通常都允許用戶按需要設置N，R，W三個值，即使是設置成W＋R<= N也是可以的。也就是說他允許用戶在強一致性和最終一致性之間自由選擇。而在用戶選擇了最終一致性，或者是W<N的強一致性時，則總會出現一段“各個節點數據不同步導致系統處理不一致的時間”。為了提供最終一致性的支持，這些系統會提供一些工具來使數據更新被最終同步到所有相關節點。