作者: Chuanhui | 可以轉(zhuǎn)載， 但必須以超鏈接形式標明文章原始出處和作者信息及版權(quán)聲明
本文鏈接地址: http://www.nosqlnotes.net/archives/21
印象中CAP理論開始流行是從Amazon Dynamo的論文開始的，Amazon的CTO還在他的博客中介紹了最終一致性的概念，從此以后，各種會議和交流中都少不了CAP的影子。然而，對于分布式系統(tǒng)工程設(shè)計和開發(fā)來說，CAP意味著什么呢？
CAP 理論由 Berkerly 的 Brewer 教授提出，三者的含義如下：
- 一致性 ( Consistency) ：任何一個讀操作總是能讀取到之前完成的寫操作結(jié)果；
- 可用性 ( Availability) ：每一個操作總是能夠在確定的時間內(nèi)返回；
- 分區(qū)可容忍性 (Tolerance of network Partition) ：在出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況下，仍然能夠滿足一致性和可用性；
CAP 理論認為，三者不能同時滿足，并給出了證明，簡單闡述如下：假設(shè)系統(tǒng)出現(xiàn)網(wǎng)絡(luò)分區(qū)為 G1 和 G2 兩個部分，在一個寫操作 W1 后面有一個讀操作 R2 ， W1 寫 G1 ， R2 讀取 G2 ，由于 G1 和 G2 不能通信，如果讀操作 R2 可以終結(jié)的話，必定不能讀取寫操作 W1 的操作結(jié)果。
由于CAP三者無法同時滿足，Amazon Dynamo論文中引入了用戶可配置的NWR策略，在CAP三個特性中作出權(quán)衡。比如N=3, W=3, R=1強調(diào)一致性；N=3, W=1, R=1強調(diào)可用性；N=3, W=2, R=2是一種折衷的策略。另外，還有一些NOSQL系統(tǒng)把CAP理論當(dāng)成一種借口，認為既然我們不能同時滿足一致性和可用性，那NOSQL系統(tǒng)就犧牲一致性。這些說法本身雖然不能說有錯，但我們至少需要思考兩個問題：
- CAP理論在工程的角度意味著什么？
- 一致性的具體含義？
筆者認為，最初的CAP理論只是粗略地告訴我們”天下沒有免費的午餐”，對于NOSQL系統(tǒng)設(shè)計指導(dǎo)意義不大。原始的CAP理論描述有如下缺陷：
- 缺少時間因素。比如對于可用性描述，10s中停服務(wù)和1個小時停服務(wù)完全是兩個概念，只停寫服務(wù)和同時停讀寫服務(wù)的影響也是很不一樣的。
- 一致性描述問題。每個讀操作雖然能夠讀取到之前寫操作結(jié)果，但是假設(shè)某些寫操作發(fā)生在機器A，某些寫操作發(fā)生在機器B，一致性依賴于對機器A和機器B上寫操作的合并，操作的順序是無法保證的。比如Dynamo&Cassandra系統(tǒng)中由于可能出現(xiàn)同一個<key, value>對被多個節(jié)點同時修改的情形，即使在NWR策略中配置W + R > N，也需要依賴沖突合并來保證一致性，這從理論上是沒有完美做法的。
- 網(wǎng)絡(luò)分區(qū)描述過于模糊。工程上容易出現(xiàn)的網(wǎng)絡(luò)問題一般是機房之間網(wǎng)絡(luò)不通，某個機房停電，某臺機器故障或者某些機器因為機架電源或者交換機的原因發(fā)生故障。單個機器故障也可以認為是網(wǎng)絡(luò)分區(qū)，但這和機房網(wǎng)絡(luò)不通對系統(tǒng)設(shè)計帶來的挑戰(zhàn)差別是很大的。
一般可以認為：工程上網(wǎng)絡(luò)分區(qū)總是存在，比如機器故障或者網(wǎng)絡(luò)異常，一致性和可用性不能同時滿足。且工程上從來不要求絕對的一致性或者可用性，而是尋求一種平衡，可以將一致性和可用性分別重定義為Harvest和Yield。
- Harvest (對應(yīng)一致性)：percent of required data actually included in the responses (請求結(jié)果的真實程度)；
- Yield (可用性)：percent of requests answered successfully (成功請求占的百分比)；
CAP理論可以演化為在工程上尋找一種方法，在”成功請求占的百分比”和”請求結(jié)果的真實程度”之間取得一個權(quán)衡，詳細描述可以參考Coda的博客。然而，這個描述仍然不夠具體，下面我們就有總控節(jié)點的系統(tǒng)（如GFS+Bigtable）和P2P系統(tǒng)（如Amazon Dynamo）兩類系統(tǒng)的CAP含義分別進行說明。
首先我們必須明確一致性的概念。NOSQL系統(tǒng)經(jīng)常提到最終一致性模型：假如客戶端A寫入一個值到存儲系統(tǒng)，客戶端B最終總是能夠讀取到A寫入的最新值，這里有一個時間窗口，依賴于交互延遲，系統(tǒng)負載以及復(fù)制技術(shù)中的replica的個數(shù)。Amazon CTO宣稱Dynamo為最終一致性系統(tǒng)，然而，這里的最終一致性具有很大的欺騙性，因為雖然客戶端B能夠讀到其它客戶端寫入的所有數(shù)據(jù)，但是可能出現(xiàn)多個節(jié)點更新同一個值的情況，需要依賴沖突合并來解決多機操作順序問題。后續(xù)的文章中，我們都會把Amazon Dynamo這種需要依賴操作合并，可能會丟失數(shù)據(jù)的模型從最終一致性模型中排除出去。最終一致性模型要求同一份數(shù)據(jù)同一時刻只能被一臺機器修改，也就是說機器宕機時需要停很短時間寫服務(wù)。
對于帶有總控節(jié)點的系統(tǒng)，將CAP理論的定義做出適當(dāng)?shù)恼{(diào)整如下：
- 一致性：讀操作總是能讀取到之前完成的寫操作結(jié)果，且不需要依賴于操作合并；
- 可用性：讀寫操作總是能夠在很短的時間內(nèi)返回，即使某臺機器發(fā)生了故障，也能夠通過其它副本正常執(zhí)行，而不需要等到機器重啟或者機器上的服務(wù)分配給其它機器以后才能成功；
- 分區(qū)可容忍性：能夠處理機器宕機，機房停電或者出現(xiàn)機房之間網(wǎng)絡(luò)故障等異常情況；
帶有總控節(jié)點的NOSQL系統(tǒng)一般是最終一致性系統(tǒng)，允許機器宕機時停止很短時間，比如10s的部分數(shù)據(jù)寫服務(wù)，但是不允許停讀服務(wù)，且服務(wù)恢復(fù)時間越短越好。大多數(shù)NOSQL系統(tǒng)都是對一份數(shù)據(jù)保留多個備份，同一時刻只有一個備份為主，提供寫服務(wù)，其它備份為輔，同步主備份的寫操作，所有的備份都可以提供讀取服務(wù)，且主備份提供保證強一致性的讀服務(wù)。當(dāng)主備份所在機器發(fā)生故障時，需要等一段時間才能由原來的輔備份接替主備份提供寫服務(wù)。
類似Amazon的P2P去中心化系統(tǒng)提供需要依賴沖突合并的一致性，比如Cassandra中的“last write wins”沖突合并策略，雖然并不完美但確實能夠解決很多問題。這樣的系統(tǒng)能夠通過用戶配置NWR策略來權(quán)衡一致性和可用性，可以做到單臺機器宕機時讀寫服務(wù)都不停止。
最后，再次提醒大家設(shè)計系統(tǒng)時：不要過分迷戀CAP，認清最終一致性，理智對待NWR。
