轉自：http://book.51cto.com/art/201503/469187.htm

《從Paxos到Zookeeper：分散式一致性原理與實踐》本書從分散式一致性的理論出發，向讀者簡要介紹幾種典型的分散式一致性協議，以及解決分散式一致性問題的思路，其中重點講解了Paxos和ZAB協議。同時，本書深入介紹了分散式一致性問題的工業解決方案——ZooKeeper，並著重向讀者展示這一分散式協調框架的使用方法、內部實現及運維技巧，旨在幫助讀者全面瞭解ZooKeeper，並更好地使用和運維ZooKeeper。本節為大家介紹CAP和BASE理論。

1.2.3  CAP和BASE理論

對於本地事務處理或者是集中式的事務處理系統，很顯然我們可以採用已經被實踐證明很成熟的ACID模型來保證資料的嚴格一致性。而在1.2.2節中，我們也已經看到，隨著分散式事務的出現，傳統的單機事務模型已經無法勝任。尤其是對於一個高訪問量、高併發的網際網路分散式系統來說，如果我們期望實現一套嚴格滿足ACID特性的分散式事務，很可能出現的情況就是在系統的可用性和嚴格一致性之間出現衝突——因為當我們要求分散式系統具有嚴格一致性時，很可能就需要犧牲掉系統的可用性。但毋庸置疑的一點是，可用性又是一個所有消費者不允許我們討價還價的系統屬性，比如說像淘寶網這樣的線上購物網站，就要求它能夠7?24小時不間斷地對外提供服務，而對於一致性，則更加是所有消費者對於一個軟體系統的剛需。因此，在可用性和一致性之間永遠無法存在一個兩全其美的方案，於是如何構建一個兼顧可用性和一致性的分散式系統成為了無數工程師探討的難題，出現了諸如CAP和BASE這樣的分散式系統經典理論。

CAP定理

2000年7月，來自加州大學伯克利分校的Eric Brewer教授注 在ACM PODC（Principles of Distributed Computing）會議上，首次提出了著名的CAP猜想注 。2年後，來自麻省理工學院的Seth Gilbert和Nancy Lynch從理論上證明了Brewer教授CAP猜想的可行性注 ，從此，CAP理論正式在學術上成為了分散式計算領域的公認定理，並深深地影響了分散式計算的發展。

CAP理論告訴我們，一個分散式系統不可能同時滿足一致性（C：Consistency）、可用性（A：Availability）和分割槽容錯性（P：Partition tolerance）這三個基本需求，最多隻能同時滿足其中的兩項。

一致性

在分散式環境中，一致性是指資料在多個副本之間是否能夠保持一致的特性。在一致性的需求下，當一個系統在資料一致的狀態下執行更新操作後，應該保證系統的資料仍然處於一致的狀態。

對於一個將資料副本分佈在不同分散式節點上的系統來說，如果對第一個節點的資料進行了更新操作並且更新成功後，卻沒有使得第二個節點上的資料得到相應的更新，於是在對第二個節點的資料進行讀取操作時，獲取的依然是老資料（或稱為髒資料），這就是典型的分散式資料不一致情況。在分散式系統中，如果能夠做到針對一個數據項的更新操作執行成功後，所有的使用者都可以讀取到其最新的值，那麼這樣的系統就被認為具有強一致性（或嚴格的一致性）。

可用性

可用性是指系統提供的服務必須一直處於可用的狀態，對於使用者的每一個操作請求總是能夠在有限的時間內返回結果。這裡我們重點看下“有限的時間內”和“返回結果”。

“有限的時間內”是指，對於使用者的一個操作請求，系統必須能夠在指定的時間（即響應時間）內返回對應的處理結果，如果超過了這個時間範圍，那麼系統就被認為是不可用的。另外，“有限的時間內”是一個在系統設計之初就設定好的系統執行指標，通常不同的系統之間會有很大的不同。比如說，對於一個線上搜尋引擎來說，通常在0.5秒內需要給出使用者搜尋關鍵詞對應的檢索結果。以Google為例，搜尋“分散式”這一關鍵詞，Google能夠在0.3秒左右的時間，返回大約上千萬條檢索結果。而對於一個面向HIVE的海量資料查詢平臺來說，正常的一次資料檢索時間可能在20秒到30秒之間，而如果是一個時間跨度較大的資料內容查詢，“有限的時間”有時候甚至會長達幾分鐘。

從上面的例子中，我們可以看出，使用者對於一個系統的請求響應時間的期望值不盡相同。但是，無論系統之間的差異有多大，唯一相同的一點就是對於使用者請求，系統必須存在一個合理的響應時間，否則使用者便會對系統感到失望。

“返回結果”是可用性的另一個非常重要的指標，它要求系統在完成對使用者請求的處理後，返回一個正常的響應結果。正常的響應結果通常能夠明確地反映出對請求的處理結果，即成功或失敗，而不是一個讓使用者感到困惑的返回結果。

讓我們再來看看上面提到的線上搜尋引擎的例子，如果使用者輸入指定的搜尋關鍵詞後，返回的結果是一個系統錯誤，通常類似於“OutOfMemoryError”或“System Has Crashed”等提示語，那麼我們認為此時系統是不可用的。

分割槽容錯性

分割槽容錯性約束了一個分散式系統需要具有如下特性：分散式系統在遇到任何網路分割槽故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網路環境都發生了故障。

網路分割槽是指在分散式系統中，不同的節點分佈在不同的子網路（機房或異地網路等）中，由於一些特殊的原因導致這些子網路之間出現網路不連通的狀況，但各個子網路的內部網路是正常的，從而導致整個系統的網路環境被切分成了若干個孤立的區域。需要注意的是，組成一個分散式系統的每個節點的加入與退出都可以看作是一個特殊的網路分割槽。

以上就是對CAP定理中一致性、可用性和分割槽容錯性的講解，通常使用圖1-2所示的示意圖來表示CAP定理。

既然在上文中我們提到，一個分散式系統無法同時滿足上述三個需求，而只能滿足其中的兩項，因此在進行對CAP定理的應用時，我們就需要拋棄其中的一項，表1-2所示是拋棄CAP定理中任意一項特性的場景說明。

表1-2．CAP定理應用

從CAP定理中我們可以看出，一個分散式系統不可能同時滿足一致性、可用性和分割槽容錯性這三個需求。另一方面，需要明確的一點是，對於一個分散式系統而言，分割槽容錯性可以說是一個最基本的要求。為什麼這樣說，其實很簡單，因為既然是一個分散式系統，那麼分散式系統中的元件必然需要被部署到不同的節點，否則也就無所謂分散式系統了，因此必然出現子網路。而對於分散式系統而言，網路問題又是一個必定會出現的異常情況，因此分割槽容錯性也就成為了一個分散式系統必然需要面對和解決的問題。因此係統架構設計師往往需要把精力花在如何根據業務特點在C（一致性）和A（可用性）之間尋求平衡。

BASE理論

BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫，是由來自eBay的架構師Dan Pritchett在其文章BASE: An Acid Alternative注 中第一次明確提出的。BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模網際網路系統分散式實踐的總結，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性(Strong consistency)，但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性(Eventual consistency)。接下來我們著重對BASE中的三要素進行詳細講解。

基本可用

基本可用是指分散式系統在出現不可預知故障的時候，允許損失部分可用性——但請注意，這絕不等價於系統不可用。以下兩個就是“基本可用”的典型例子。

響應時間上的損失：正常情況下，一個線上搜尋引擎需要在0.5秒之內返回給使用者相應的查詢結果，但由於出現故障（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了1～2秒。

功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峰的時候，由於消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。

弱狀態

弱狀態也稱為軟狀態，和硬狀態相對，是指允許系統中的資料存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的資料副本之間進行資料同步的過程存在延時。

最終一致性

最終一致性強調的是系統中所有的資料副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終資料能夠達到一致，而不需要實時保證系統資料的強一致性。

亞馬遜首席技術官Werner Vogels在於2008年發表的一篇經典文章Eventually Consistent-

Revisited中，對最終一致性進行了非常詳細的介紹。他認為最終一致性是一種特殊的弱一致性：系統能夠保證在沒有其他新的更新操作的情況下，資料最終一定能夠達到一致的狀態，因此所有客戶端對系統的資料訪問都能夠獲取到最新的值。同時，在沒有發生故障的前提下，資料達到一致狀態的時間延遲，取決於網路延遲、系統負載和資料複製方案設計等因素。

在實際工程實踐中，最終一致性存在以下五類主要變種。

因果一致性（Causal consistency）

因果一致性是指，如果程序A在更新完某個資料項後通知了程序B，那麼程序B之後對該資料項的訪問都應該能夠獲取到程序A更新後的最新值，並且如果程序B要對該資料項進行更新操作的話，務必基於程序A更新後的最新值，即不能發生丟失更新情況。與此同時，與程序A無因果關係的程序C的資料訪問則沒有這樣的限制。

讀己之所寫（Read your writes）

讀己之所寫是指，程序A更新一個數據項之後，它自己總是能夠訪問到更新過的最新值，而不會看到舊值。也就是說，對於單個數據獲取者來說，其讀取到的資料，一定不會比自己上次寫入的值舊。因此，讀己之所寫也可以看作是一種特殊的因果一致性。

會話一致性（Session consistency）

會話一致性將對系統資料的訪問過程框定在了一個會話當中：系統能保證在同一個有效的會話中實現“讀己之所寫”的一致性，也就是說，執行更能操作之後，客戶端能夠在同一個會話中始終讀取到該資料項的最新值。

單調讀一致性（Monotonic read consistency）

單調讀一致性是指如果一個程序從系統中讀取出一個數據項的某個值後，那麼系統對於該程序後續的任何資料訪問都不應該返回更舊的值。

單調寫一致性（Monotonic write consistency）

單調寫一致性是指，一個系統需要能夠保證來自同一個程序的寫操作被順序地執行。

以上就是最終一致性的五類常見的變種，在實際系統實踐中，可以將其中的若干個變種互相結合起來，以構建一個具有最終一致性特性的分散式系統。事實上，最終一致性並不是只有那些大型分散式系統才涉及的特性，許多現代的關係型資料庫都採用了最終一致性模型。在現代關係型資料庫中，大多都會採用同步和非同步方式來實現主備資料複製技術。在同步方式中，資料的複製過程通常是更新事務的一部分，因此在事務完成後，主備資料庫的資料就會達到一致。而在非同步方式中，備庫的更新往往會存在延時，這取決於事務日誌在主備資料庫之間傳輸的時間長短，如果傳輸時間過長或者甚至在日誌傳輸過程中出現異常導致無法及時將事務應用到備庫上，那麼很顯然，從備庫中讀取的資料將是舊的，因此就出現了資料不一致的情況。當然，無論是採用多次重試還是人為資料訂正，關係型資料庫還是能夠保證最終資料達到一致——這就是系統提供最終一致性保證的經典案例。

總的來說，BASE理論面向的是大型高可用可擴充套件的分散式系統，和傳統事務的ACID特性是相反的，它完全不同於ACID的強一致性模型，而是提出通過犧牲強一致性來獲得可用性，並允許資料在一段時間內是不一致的，但最終達到一致狀態。但同時，在實際的分散式場景中，不同業務單元和元件對資料一致性的要求是不同的，因此在具體的分散式系統架構設計過程中，ACID特性與BASE理論往往又會結合在一起使用

總的來說，BASE理論面向的是大型高可用可擴充套件的分散式系統，和傳統事務的ACID特性是相反的，它完全不同於ACID的強一致性模型，而是提出通過犧牲強一致性來獲得可用性，並允許資料在一段時間內是不一致的，但最終達到一致狀態。但同時，在實際的分散式場景中，不同業務單元和元件對資料一致性的要求是不同的，因此在具體的分散式系統架構設計過程中，ACID特性與BASE理論往往又會結合在一起使用。