NoSql中的CAP原則

C：一致性 。A：可用性。P：分區容錯性

Partition tolerance(分區容錯性)：

　　大多數分佈式系統都分佈在多個子網絡。每一個子網絡就叫作一個區（partition）。分區容錯的意思是，區間通訊可能失敗。好比，一臺服務器放在中國，另外一臺服務器放在美國，這就是兩個區，它們之間可能沒法通訊。下圖中，G1 和 G2 是兩臺跨區的服務器。G1 向 G2 發送一條消息，G2 可能沒法收到。系統設計的時候，必須考慮到這種狀況。通常來講，分區容錯沒法避免，所以能夠認爲 CAP 的 P 老是成立。CAP 定理告訴咱們，剩下的 C 和 A 沒法同時作到。

 

Consistency(一致性)

　　任何一個讀操做老是能讀取到以前完成的寫操做結果，也就是在分佈式環境中，多點的數據是一致的。問題是，用戶有可能向 G2 發起讀操做，因爲 G2 的值沒有發生變化，所以返回的是 v0。G1 和 G2 讀操做的結果不一致，這就不知足一致性了。

 

 爲了讓 G2 也能變爲 v1，就要在 G1 寫操做的時候，讓 G1 向 G2 發送一條消息，要求 G2 也改爲 v1。

 

 Availability(可用性)

 　　只要收到用戶的請求，服務器就必須給出迴應。用戶能夠向G1或者G2發起讀操做，不論是哪臺服務器，只要收到請求，就必須告訴用戶究竟是V0仍是V1，不然就不知足可用性。 一致性和可用性不可能同時成立，由於通信可能失敗(即出現分區容錯) 若是須要保證G2的一致性，那麼G1必須在寫操做時鎖定G2的讀操做和寫操做。只有數據同步後才從新開放讀寫。鎖按期間G2是不能讀寫的，全部沒有可用性。若是須要保證G2的可用性那麼勢必不能鎖定G2，可是G1和G2的一致性就不成立。因此G2沒法同時作到一致性和可用性。系統設計時只能選擇一個目標， 追求一致性那麼就沒法保證可用性，如過追求可用性就沒法作到一致性。

CA：傳統Oracle數據庫。

AP：大多數網站架構的選擇。

CP：Redis，MongoDB （弱一致性，高可用性和分區容錯性）。

Base

　　Bas理論是對CAP中一致性和可用性權衡的結果，其來源與對大型互聯網分佈式實踐的總結，是基於CAP定理逐步演化而來的。 Base全稱 Basically Available(基本可用)，Soft state（軟狀態）,和 Eventually consistent（最終一致性）三個短語的縮寫，來自 ebay 的架構師提出。其核心思想是便是沒法作到強一致性(Strong consistency),但每一個應用均可以根據自身的業務特色，採用適當的方式來使系統達到最終的一致性(Eventual consistency)。

Basically Available(基本可用)　　

• 假設系統出現了不可預知的故障，可是仍是能用的。相比較正常的系統而言響應時間上的損失，好比正常須要0.5秒返回用戶結果，而基本可用能夠在1秒返回結果。或功能上的損失。

Soft state（軟狀態）

• 相對於原子性而言，要求多個節點的數據副本都是一致的，這是一種 「硬狀態」。 軟狀態指的是容許系統中的數據存在中間狀態，並認爲該狀態不影響系統的總體可用性，即容許系統在多個不一樣節點的數據副本存在數據延時。

Eventually consistent（最終一致性）

•  數據不可能一直是軟狀態，必須有個時間期限。在期限事後，應當保證全部副本保持數據一致性。從而達到數據的最終一致性。這個時間期限取決於網絡延時，系統負載，數據複製方案設計等等因素。

最終一致性分爲五種

1. 因果一致性（Causal consistency）： 指的是若是節點 A 在更新完某個數據後通知了節點 B，那麼節點 B 以後對該數據的訪問和修改都是基於 A 更新後的值。於此同時，和節點 A 無因果關係的節點 C 的數據訪問則沒有這樣的限制。
2. 讀已之所寫(Read your writes) ：節點A更新一個數據後，它自身老是能訪問到自身更新過的最新值，而不會看到舊值。
3. 會話一致性(session consistency)： 會話一致性將對系統數據的訪問過程框定在了一個會話當中,系統能保證在同一個有效的會話中實現 「讀己之所寫」 的一致性，也就是說，執行更新操做以後，客戶端可以在同一個會話中始終讀取到該數據項的最新值。
4. 單調讀一致性(Monotonic read consistency) ：單調讀一致性是指若是一個節點從系統中讀取出一個數據項的某個值後，那麼系統對於該節點後續的任何數據訪問都不該該返回更舊的值。
5. 當調寫一致性(Monotonic write consistency)： 指一個系統要可以保證來自同一個節點的寫操做被順序的執行。 在實際的實踐中，這 5 種系統每每會結合使用，以構建一個具備最終一致性的分佈式系統。實際上，不僅是分佈式系統使用最終一致性，關係型數據庫在某個功能上，也是使用最終一致性的，好比備份，數據庫的複製過程是須要時間的，這個複製過程當中，業務讀取到的值就是舊的。固然，最終仍是達成了數據一致性。這也算是一個最終一致性的經典案例