印象中cap理論開始流行是從amazon dynamo的**開始的，amazon的cto還在他的部落格中介紹了最終一致性的概念，從此以後，各種會議和交流中都少不了cap的影子。然而，對於分布式系統工程設計和開發來說，cap意味著什麼呢？
cap 理論由 berkerly 的 brewer 教授提出，三者的含義如下：
cap 理論認為，三者不能同時滿足，並給出了證明，簡單闡述如下：假設系統出現網路分割槽為 g1 和 g2 兩個部分，在乙個寫操作 w1 後面有乙個讀操作 r2 ， w1 寫 g1 ， r2 讀取 g2 ，由於 g1 和 g2 不能通訊，如果讀操作 r2 可以終結的話，必定不能讀取寫操作 w1 的操作結果。
由於cap三者無法同時滿足，amazon dynamo**中引入了使用者可配置的nwr策略，在cap三個特性中作出權衡。比如n=3, w=3, r=1強調一致性；n=3, w=1, r=1強調可用性；n=3, w=2, r=2是一種折衷的策略。另外，還有一些nosql系統把cap理論當成一種藉口，認為既然我們不能同時滿足一致性和可用性，那nosql系統就犧牲一致性。這些說法本身雖然不能說有錯，但我們至少需要思考兩個問題：
cap理論在工程的角度意味著什麼？
一致性的具體含義？
筆者認為，最初的cap理論只是粗略地告訴我們」天下沒有免費的午餐」，對於nosql系統設計指導意義不大。原始的cap理論描述有如下缺陷：
缺少時間因素。比如對於可用性描述，10s中停服務和1個小時停服務完全是兩個概念，只停寫服務和同時停讀寫服務的影響也是很不一樣的。
一致性描述問題。每個讀操作雖然能夠讀取到之前寫操作結果，但是假設某些寫操作發生在機器a，某些寫操作發生在機器b，一致性依賴於對機器a和機器b上寫操作的合併，操作的順序是無法保證的。比如dynamo&cassandra系統中由於可能出現同乙個對被多個節點同時修改的情形，即使在nwr策略中配置w + r > n，也需要依賴衝突合併來保證一致性，這從理論上是沒有完美做法的。
網路分割槽描述過於模糊。工程上容易出現的網路問題一般是機房之間網路不通，某個機房停電，某台機器故障或者某些機器因為機架電源或者交換機的原因發生故障。單個機器故障也可以認為是網路分割槽，但這和機房網路不通對系統設計帶來的挑戰差別是很大的。
一般可以認為：工程上網路分割槽總是存在，比如機器故障或者網路異常，一致性和可用性不能同時滿足。且工程上從來不要求絕對的一致性或者可用性，而是尋求一種平衡，可以將一致性和可用性分別重定義為harvest和yield。
cap理論可以演化為在工程上尋找一種方法，在」成功請求佔的百分比」和」請求結果的真實程度」之間取得乙個權衡，詳細描述可以參考coda的部落格。然而，這個描述仍然不夠具體，下面我們就有總控節點的系統（如gfs+bigtable）和p2p系統（如amazon dynamo）兩類系統的cap含義分別進行說明。
首先我們必須明確一致性的概念。nosql系統經常提到最終一致性模型：假如客戶端a寫入乙個值到儲存系統，客戶端b最終總是能夠讀取到a寫入的最新值，這裡有乙個時間視窗，依賴於互動延遲，系統負載以及複製技術中的replica的個數。amazon cto宣稱dynamo為最終一致性系統，然而，這裡的最終一致性具有很大的欺騙性，因為雖然客戶端b能夠讀到其它客戶端寫入的所有資料，但是可能出現多個節點更新同乙個值的情況，需要依賴衝突合併來解決多機操作順序問題。後續的文章中，我們都會把amazon dynamo這種需要依賴操作合併，可能會丟失資料的模型從最終一致性模型中排除出去。最終一致性模型要求同乙份資料同一時刻只能被一台機器修改，也就是說機器宕機時需要停很短時間寫服務。
對於帶有總控節點的系統，將cap理論的定義做出適當的調整如下：
帶有總控節點的nosql系統一般是最終一致性系統，允許機器宕機時停止很短時間，比如10s的部分資料寫服務，但是不允許停讀服務，且服務恢復時間越短越好。大多數nosql系統都是對乙份資料保留多個備份，同一時刻只有乙個備份為主，提供寫服務，其它備份為輔，同步主備份的寫操作，所有的備份都可以提供讀取服務，且主備份提供保證強一致性的讀服務。當主備份所在機器發生故障時，需要等一段時間才能由原來的輔備份接替主備份提供寫服務。
類似amazon的p2p去中心化系統提供需要依賴衝突合併的一致性，比如cassandra中的「last write wins」衝突合併策略，雖然並不完美但確實能夠解決很多問題。這樣的系統能夠通過使用者配置nwr策略來權衡一致性和可用性，可以做到單台機器宕機時讀寫服務都不停止。
分布式系統 CAP理論
cp 天貓雙十一下單搶購,要保證一致性,沒貨了下單失敗 一般來說，如果不需要儲存服務級別的資訊，且服務例項是通過 nacos client 註冊，並能夠保證心跳上報，那麼就可以選擇 ap 模式。當前主流的服務如 spring cloud 和 dubbo 服務，都適用於 ap 模式，ap模式為了服務的...
分布式系統CAP理論
c是一致性，a是可用性，p是分割槽容錯。前兩個沒什麼好說的，主要是p我不太清楚。然後我看文章中最後的證明，有點明白了。分割槽是指兩個伺服器之間傳送資訊失敗。而分割槽容錯就是系統允許發生這種兩個伺服器之間無法傳輸資料的情況。也就是說c和a如果算是正面的 好的性質，那麼p就是負面的 壞的性質。那為什麼允...
分布式CAP理論
根據維基百科定義 cap 根據定理，乙個分布式系統最多只能滿足其中兩項，不可能同時滿則c a p三項 首先說一下對各項原則的理解 1 一致性c 單機環境下，資料只有乙份，所有的客戶端訪問的是同乙份資料，不會出現兩個客戶端看到不一樣的資料 分布式環境下，同乙份資料會儲存在多台伺服器上，大量客戶端來訪問...