在分布式系統中，一致性（c）指每一次讀都得到最近的寫資料，或者乙個異常；可用性（a）指每乙個請求都得到乙個非異常的響應，而不保證取得最近的寫資料；分割槽容錯性（p）是指結點間網路異常時，系統仍然可以繼續執行。原理指出，乙個分布式系統最多只能提供cap中的兩個保障。
值得注意的是，cap原理指的是在分割槽發生時，只能在保證一致性或可用性中二選其一。而非因為分割槽不可避免，在系統設計時必須放棄一致性或可用性，沒有分割槽發生時可以同時保證一致性和可用性。
如圖，網路中有兩個結點n1和n2，可以簡單的理解n1和n2分別是兩台計算機，他們之間網路可以連通，n1中有乙個應用程式a，和乙個資料庫v，n2也有乙個應用程式b和乙個資料庫v。
正常執行時的場景如下圖：
當結點間的網路發生問題時，n1和n2間的資料同步失效。此時系統只能在一致性和可用性中二選一。選擇一致性時，結點將對請求返回不可用異常。選擇可用性時，結點將返回現有的資料，而此時資料可能已經過時。
對於多數大型網際網路應用的場景，主機眾多、部署分散，而且現在的集群規模越來越大，所以節點故障、網路故障是常態，而且要保證服務可用性達到n個9，即保證p和a，捨棄c（退而求其次保證最終一致性）。雖然某些地方會影響客戶體驗，但沒達到造成使用者流失的嚴重程度。
對於涉及到錢財這樣不能有一絲讓步的場景，c必須保證。網路發生故障寧可停止服務（或者唯讀不寫），這是保證ca，捨棄p。
cap理論在資料庫領域也有廣泛的應用，如下圖中按照cap中三選二對資料庫系統的分類：
分布式系統 CAP理論
cp 天貓雙十一下單搶購,要保證一致性,沒貨了下單失敗 一般來說，如果不需要儲存服務級別的資訊，且服務例項是通過 nacos client 註冊，並能夠保證心跳上報，那麼就可以選擇 ap 模式。當前主流的服務如 spring cloud 和 dubbo 服務，都適用於 ap 模式，ap模式為了服務的...
分布式系統CAP理論
c是一致性，a是可用性，p是分割槽容錯。前兩個沒什麼好說的，主要是p我不太清楚。然後我看文章中最後的證明，有點明白了。分割槽是指兩個伺服器之間傳送資訊失敗。而分割槽容錯就是系統允許發生這種兩個伺服器之間無法傳輸資料的情況。也就是說c和a如果算是正面的 好的性質，那麼p就是負面的 壞的性質。那為什麼允...
分布式系統CAP定理
c 資料一致性 a 服務可用性 p 服務對網路分割槽故障的容錯性這三個特性在任何分布式系統中不能同時滿足，最多同時滿足兩個 zookeeper是個cp的，即任何時刻對zookeeper的訪問請求能得到一致的資料結果，同時系統對網路分割具備容錯性 但是它不能保證每次服務請求的可用性 注 也就是在極端環...