分散式系統知識分享：正確理解CAP定理

　　前言

　　CAP的理解我也看了很多書籍，也看了不少同行的博文，基本每個人的理解都不一樣，而布魯爾教授得定義又太過的簡單，沒有具體描述和場景案例分析。因此自己參考部分資料梳理了一篇與大家互相分享一下。

　　標題寫了正確理解，或許某些點不是百分百正確或者有歧義，但是希望與各位分享討論後達到最終正確。

　　簡介

　　CAP定理，又被稱作布魯爾定理(Brewer's theorem)，是埃裡克·布魯爾教授在2000 年提出的一個猜想，它指出對於一個分散式系統來說，不可能同時滿足以下三點：

　　·Consistency(一致性): where all nodes see the same data at the same time.(所有節點在同一時間具有相同的資料)

　　·Availability(可用性): which guarantees that every request receives a response about whether it succeeded or failed.(保證每個請求不管成功或者失敗都有響應)

　　·Partition tolerance(分隔容忍): where the system continues to operate even if any one part of the system is lost or fails.(系統中任意資訊的丟失或失敗不會影響系統的繼續運作)

　　很多書籍與文章引用Robert Greiner在2014年8月寫的一篇博文 。相比與看著布魯爾教授一臉懵逼的定義，Robert Greiner的更加容易理解。

　　定義

　　原文：In a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair: Consistency, Availability, and Partition Tolerance - one of them must be sacrificed.

　　翻譯：在一個分散式系統(指互相連線並共享資料的節點的集合)中，當涉及讀寫操作時，只能保證一致性(Consistence)、可用性(Availability)、分割槽容錯性(Partition Tolerance)三者中的兩個，另外一個必須被犧牲。

　　關鍵字：interconnected nodes(互連節點)、share data(共享資料)、a write/read pair(讀/寫)

　　從上面一段話，有幾個，也就是說我們聊CAP定理的時候，是在具有資料讀寫、資料共享和節點互連的前提下，對上面三者選其二，也是建議我們不要花費時間與精力同時滿足三者。

　　舉例說明，web叢集、memcached叢集不屬於討論物件

　　web叢集只是資源複製分配在不同的節點上，然而節點間沒有互連、也沒有資料共享(sessionid、memory cache)。

　　memcached叢集資料儲存是透過客戶端實現雜湊一致性，但是叢集節點間不互連的，也沒有資料共享。

　　總得來說，CAP定理討論的並不是分散式系統所有的功能。

　　一致性(Consistency)

　　原文：A read is guaranteed to return the most recent write for a given client.

　　翻譯：對某個指定的客戶端來說，讀操作保證能夠返回最新的寫操作結果

　　關鍵字：a given client(指定的客戶端)。

　　這裡的一致性與我們平常瞭解ACID的一致性有點偏差，ACID的一致性關注的是資料庫的資料完整性。

　　上面定義沒說明是所有節點必須在同一時間資料一致，而關注點在客戶端，假如有個場景，您在ATM(客戶端)往某張銀行卡存500元后，立刻在ATM發起查詢餘額的時候會顯示加了500元后的餘額，隨後我們也能把這500元取出來。查詢餘額讀操作可以是寫後立刻讀的主庫，也或者寫後某個時間段過後(中途無寫)讀從庫。

　　可用性(Availability)

　　原文：A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).

　　翻譯：非故障節點將在合理的時間內返回合理的響應(不是錯誤或超時)。

　　關鍵字：non-failing node(非故障節點)、reasonable response(合理的響應)

　　這裡的可用性和我們平常所理解的高可用性有點偏差，高可用性指系統無中斷的執行其功能的能力。

　　已故障的節點就不具有可用性了，因為請求結果要麼error要麼 timeout。合理的響應沒有說明是成功還是失敗，但是響應應該具有是否成功的精確描述。例如我們讀取sql server叢集的某從庫，同步需要時間，讀取出來可能不是最新的資料，但卻是合理的響應。

　　分割槽容錯性(Partition tolerance)

　　原文：The system will continue to function when network partitions occur.

　　翻譯：當網路分割槽發生時，系統將繼續正常運作

　　關鍵字：continue to function(繼續正常運作)

　　假如做了一個redis的一主兩從的叢集，某天某個從節點因為網路故障變成不可用，但是另外的一主一 從仍然能正常運作，那麼我們認為它具有分割槽容錯性。

　　CA-犧牲分割槽容錯性

　　作為分散式系統，分割槽必然總會發生(2年1次50分鐘還是1年3次共10分鐘?)，因此認為CAP的討論是大部分建立在P確立前提下。假設我們犧牲了P這個時候因為網路故障發生了分割槽導致節點不可用，這個時候請求響應了error、timeout，與可用性的定義相沖突了。

　　但是，我們又假如分割槽大部分時間是不存在的，這時對單節點的讀\寫，那麼就無需作出C、A的取捨。但是上面說分割槽總會發生這不互相矛盾麼，還是取捨。假如1年時間內99.99%時間是正常的，不可用時間為0.01%(52.56分鐘)不可用，若這個時間屬於業務接受範圍，或者只在某個地區(華南、華北、華中?)有影響，那麼CA也是可以選擇的。

　　PC-犧牲可用性

　　最典型的案例是RDBMS叢集與Redis叢集，這兩種都是利用主從複製實現讀寫分離的方案。假如兩者都是建立一主多從的叢集，在主節點寫入資料，為了保證隨後的讀操作獲取最新資料(一致性)，這個讀操作仍會請求主節點(讀寫分離的複雜點在從庫同步不及時導致業務的異常，為了保證業務的正常性寫後的讀會請求主庫)，某個從節點掛了但是隻要主節點和其他從節點仍然正常運作，就滿足分割槽容錯性。但是哪天主節點因為網路故障導致寫操作的error或者timeout，那麼這個系統就不可用了(犧牲可用性)。

　　這個時候可以引入其他功能和機制完成，例如Redis哨兵模式、故障轉移功能。

　　PA-犧牲一致性

　　最典型的案例是Cassanda叢集和Riak叢集，這種型別的分散式資料庫，可以任意節點寫入，任意節點讀取，當作為叢集出現，無論寫入哪個節點，都將會把該節點的資料同步到其他節點上，因為這種同步方式，讀取資料時只要訪問一個節點就足夠了(喜歡任意訪問也不攔著你)，但是因為其他節點資料同步原因，資料可能並不是最新的(犧牲一致性)。如果當前節點因為網路異常導致分割槽變得不可用(無論讀\寫)，可以轉移訪問節點(可用性)。

　　另外這裡說的犧牲一致性，並不代表放棄一致性，而PA選擇的是最終一致性(系統中所有的資料副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態)

　　總結

　　上面涉及“犧牲”字眼，並不代表非此即彼的選擇，可以根據子系統、模組之間的設計上進行混搭使用(例如PA和PC、CA和PC)。

　　本文對CAP定理做了一個簡單的梳理描述，參考了部分書籍和文章加上自己的理解希望可以跟大家做個分享，如果有不同建議和看法包括文章內描述錯誤，請在下方評論指出，我將及時作出修改。

　　作 者： 陳珙

　　出 處：http://www.cnblogs.com/skychen1218/ 

　　關於作者：專注於微軟平臺的專案開發。如有問題或建議，請多多賜教!