cap？
cap定律說的是在乙個分布式計算機系統中，一致性，可用性和分割槽容錯這三個條件無法同時滿足，最多滿足兩個
強一致性（c）：系統在執行某項操作後仍然處於一致的狀態。在分布式系統中，更新操作執行成功後所有的使用者都讀取到最新的值，等於所有節點訪問同乙份最新的資料副本
可用性（a）：每乙個操作總是能夠在一定的時間內返回結果，一定時間指的是在可以容忍的範圍內返回結果，結果可以是成功或失敗。對資料更新具備高可用性
分割槽容錯性（p）：在網路分割槽的情況下，仍然可以接收請求（在網路中斷，訊息丟失的情況下，系統照樣能夠工作），系統如果不能再時限內達成資料一致性，就意味著發生了分割槽的情況，需要在c和a之間做出選擇
c.a.p的選擇？
放棄p：不進行分割槽，將所有資料放在同一臺機器上，但是會嚴重影響系統的擴充套件性
放棄a： 一旦遇到分割槽容錯故障，那麼受到影響的服務需要等待一定的時間，在此期間無法提供服務
放棄c： 放棄資料的強一致性，但是保留了資料的最終一致性（例如**的雙11）
c和a的抉擇：分布式系統中，最終能實現兩點，而p是一定要實現的（不然怎麼叫分布式），所以c和a要進行選擇權衡
因為通訊中可能會出現通訊失敗，這個時候就要考慮該系統是能提供服務還是不能提供服務（提供服務就是可用性，不提供服務就是一致性）
cp：滿足一致性，效能不是很高，金融系統使用 zookeeper
base？
基本可用：分布式系統出現故障時，允許損失部分可用性，保證核心可用
軟狀態： 允許系統存在中間狀態，該中間狀態不會影響系統整體可用性。分布式儲存中一般乙份資料至少有三個副本，允許不同節點間副本同步的延時
最終一致：系統中所有資料副本經過一定時間後，最終能夠達到一致的狀態，最終一致性就是弱一致行動特殊情況
分布式CAP理論和BASE理論
現如今，在分布式場景下，集群規模越來越大，節點越來越多。所以說節點故障 網路故障會是常態化產生，因此分割槽容錯性 p 是必須要保證的。所以只能在一致性 c 和可用性 a 之間來進行取捨。但對於傳統的專案就可能有所不同，拿銀行的轉賬系統來說，涉及到金錢的對於資料一致性不能做出一絲的讓步，c必須保證，出...
分布式系統 CAP理論
cp 天貓雙十一下單搶購,要保證一致性,沒貨了下單失敗 一般來說，如果不需要儲存服務級別的資訊，且服務例項是通過 nacos client 註冊，並能夠保證心跳上報，那麼就可以選擇 ap 模式。當前主流的服務如 spring cloud 和 dubbo 服務，都適用於 ap 模式，ap模式為了服務的...
分布式系統CAP理論
c是一致性，a是可用性，p是分割槽容錯。前兩個沒什麼好說的，主要是p我不太清楚。然後我看文章中最後的證明，有點明白了。分割槽是指兩個伺服器之間傳送資訊失敗。而分割槽容錯就是系統允許發生這種兩個伺服器之間無法傳輸資料的情況。也就是說c和a如果算是正面的 好的性質，那麼p就是負面的 壞的性質。那為什麼允...