摘要：和上一篇博文一樣，這次我們依舊以為案例，來分析理論在一個實際的分布式數據庫中的作用。這次我們來看看，在這樣的分布式數據庫中，理論是怎么起作用的。需要最終包含正確的值的服務器節點總數正確的冗余數據拷貝數。其實這就是關系型數據庫的做法。

和上一篇博文一樣，這次我們依舊以 Riak 為案例，來分析 CAP 理論在一個實際的分布式數據庫中的作用。

如果你還不熟悉 CAP，可以參考我之前的兩篇博客 理解 CAP 理論, 最終一致性.html)。

這次我們來看看，在 Riak 這樣的分布式key-value數據庫中，CAP理論是怎么起作用的。

首先還是讓我們來明確幾個概念。

N odes

需要"最終"包含正確的值的服務器節點總數(正確的冗余數據拷貝數)。

W rites

每次寫操作，我們需要確保最少有多少節點被更新。也就是說，我們在執行寫操作的時候，不需要等待 N 個節點都成功被寫入，
而只需要 W 個節點成功寫入，這次寫操作就返回成功，而其他節點是在后臺進行同步。

R eads

每次讀操作，我們需要確保最少讀到幾份冗余數據。也就是說，我們在執行讀操作的時候，需要讀到 R 個節點的數據才算讀成功，否則讀取失敗。

為什么要這三個變量？其實這三個變量直接關系到了 Riak 的 CAP 特性。下面我們就來一一說明：

如下圖所示：假設我們的 N=3, 設置 W + R <= N(例如：R=2, W=1)。這樣我們的系統可以相對保證讀寫性能。
因為寫操作只需要一個節點寫入就返回成功。

然而這里有機率發生這樣的情況：就像圖中所示，我寫入的是node1(versionB)，然后進行了一次讀操作。
恰好這時候新數據尚未同步到node2, node3，而讀操作又是從node2，node3取的值。由于這兩個節點的值都是 version A，
所以得到的值便是 version A。

不過隨著時間的推移，node1 中的 versionB 會被同步到 node2 以及 node3 中。
這時候，再有讀操作，得到的值便是最新值(versionB)了。

這就是所謂的 Eventual Consistency。整個系統有著較高的讀寫性能，但一致性有所犧牲。

如果我們需要加強一致性，可以通過調整 W, R, N 來實現。

接下來我們會討論如何調整 W，R，N 的關系來平衡讀寫性能和一致性(即 A 和 C 的平衡)。

一種極端做法(下圖所示)，我們可以設 W=N, R=1。其實這就是關系型數據庫的做法。
通過確保每次寫操作時，所有相關節點都被成功寫入，來確保一致性。這樣可以保證一致性，但是犧牲了寫操作的性能。

還有一種極端做法，我們可以設W=1, R=N。這樣，無論你向哪個node寫入了數據，都會被讀到。
然后你讀到的N個值也可能包含舊的值，只要有辦法分辨出哪個是最新的值就可以了
(Riak 是用一直叫向量鐘(Vector Clock)的技術來判斷的，我們會在后面的博客中做介紹)
這樣可以保證一致性，但是犧牲了讀操作的性能。

最后再給出一種被稱作 quorum 的做法。如下圖所示，可以設置 W + R > N (例如 W=2, R=2)。這樣同樣可以保證一致性。
然而性能的損失由寫操作和讀操作共同承擔。這種做法叫做 quorum。