[轉]CAP原理與最終一致性 強一致性 透析

在足球比賽裏，一個球員在一場比賽中進三個球，稱之爲帽子戲法(Hat-trick)。在分佈式數據系統中，也有一個帽子原理(CAP Theorem)，不過此帽子非彼帽子。CAP原理中，有三個要素：

• 一致性(Consistency)
• 可用性(Availability)
• 分區容忍性(Partition tolerance)

CAP原理指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。所以在進行分佈式架構設計時，必須作出取捨。而對於分佈式數據系統，分區容忍性是基本要求，不然就失去了價值。所以設計分佈式數據系統，就是在一致性和可用性之間取一個平衡。對於大多數web應用，其實並不須要強一致性，所以犧牲一致性而換取高可用性，是目前多數分佈式數據庫產品的方向。

固然，犧牲一致性，並非徹底無論數據的一致性，不然數據是混亂的，那麼系統可用性再高分佈式再好也沒有了價值。犧牲一致性，只是再也不要求關係型數據庫中的強一致性，而是隻要系統能達到最終一致性便可，考慮到客戶體驗，這個最終一致的時間窗口，要儘量的對用戶透明，也就是須要保障「用戶感知到的一致性」。一般是經過數據的多份異步複製來實現系統的高可用和數據的最終一致性的，「用戶感知到的一致性」的時間窗口則取決於數據複製到一致狀態的時間。

最終一致性(eventually consistent)

對於一致性，能夠分爲從客戶端和服務端兩個不一樣的視角。從客戶端來看，一致性主要指的是多併發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何複製分佈到整個系統，以保證數據最終一致。一致性是由於有併發讀寫纔有的問題，所以在理解一致性的問題時，必定要注意結合考慮併發讀寫的場景。

從客戶端角度，多進程併發訪問時，更新過的數據在不一樣進程如何獲取的不一樣策略，決定了不一樣的一致性。對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到，這是強一致性。若是能容忍後續的部分或者所有訪問不到，則是弱一致性。若是通過一段時間後要求能訪問到更新後的數據，則是最終一致性。

最終一致性根據更新數據後各進程訪問到數據的時間和方式的不一樣，又能夠區分爲：

• 因果一致性。若是進程A通知進程B它已更新了一個數據項，那麼進程B的後續訪問將返回更新後的值，且一次寫入將保證取代前一次寫入。與進程A無因果關係的進程C的訪問遵照通常的最終一致性規則。
• 「讀己之所寫（read-your-writes）」一致性。當進程A本身更新一個數據項以後，它老是訪問到更新過的值，毫不會看到舊值。這是因果一致性模型的一個特例。
• 會話（Session）一致性。這是上一個模型的實用版本，它把訪問存儲系統的進程放到會話的上下文中。只要會話還存在，系統就保證「讀己之所寫」一致性。若是因爲某些失敗情形令會話終止，就要創建新的會話，並且系統的保證不會延續到新的會話。
• 單調（Monotonic）讀一致性。若是進程已經看到過數據對象的某個值，那麼任何後續訪問都不會返回在那個值以前的值。
• 單調寫一致性。系統保證來自同一個進程的寫操做順序執行。要是系統不能保證這種程度的一致性，就很是難以編程了。

上述最終一致性的不一樣方式能夠進行組合，例如單調讀一致性和讀己之所寫一致性就能夠組合實現。而且從實踐的角度來看，這二者的組合，讀取本身更新的數據，和一旦讀取到最新的版本不會再讀取舊版本，對於此架構上的程序開發來講，會少不少額外的煩惱。

從服務端角度，如何儘快將更新後的數據分佈到整個系統，下降達到最終一致性的時間窗口，是提升系統的可用度和用戶體驗很是重要的方面。對於分佈式數據系統：

• N — 數據複製的份數
• W — 更新數據是須要保證寫完成的節點數
• R — 讀取數據的時候須要讀取的節點數

若是W+R>N，寫的節點和讀的節點重疊，則是強一致性。例如對於典型的一主一備同步複製的關係型數據庫，N=2,W=2,R=1，則無論讀的是主庫仍是備庫的數據，都是一致的。

若是W+R<=N，則是弱一致性。例如對於一主一備異步複製的關係型數據庫，N=2,W=1,R=1，則若是讀的是備庫，就可能沒法讀取主庫已經更新過的數據，因此是弱一致性。

對於分佈式系統，爲了保證高可用性，通常設置N>=3。不一樣的N,W,R組合，是在可用性和一致性之間取一個平衡，以適應不一樣的應用場景。

• 若是N=W,R=1，任何一個寫節點失效，都會致使寫失敗，所以可用性會下降，可是因爲數據分佈的N個節點是同步寫入的，所以能夠保證強一致性。
• 若是N=R,W=1，只須要一個節點寫入成功便可，寫性能和可用性都比較高。可是讀取其餘節點的進程可能不能獲取更新後的數據，所以是弱一致性。這種狀況下，若是W<(N+1)/2，而且寫入的節點不重疊的話，則會存在寫衝突  

轉自：http://www.blogjava.net/hello-yun/archive/2012/04/27/376744.html

參見：http://www.infoq.com/cn/news/2008/01/consistency-vs-availability