分布式系統CAP理論

2022-01-17 12:49:12 字數 854 閱讀 1486

c是一致性,a是可用性,p是分割槽容錯。

前兩個沒什麼好說的,主要是p我不太清楚。然後我看文章中最後的證明,有點明白了。

分割槽是指兩個伺服器之間傳送資訊失敗。而分割槽容錯就是系統允許發生這種兩個伺服器之間無法傳輸資料的情況。

也就是說c和a如果算是正面的、好的性質,那麼p就是負面的、壞的性質。

那為什麼允許這種負面的情況發生?我的理解是如果只有乙個伺服器,那肯定不會發生兩個伺服器無法傳輸資料的情況,因為本來就只有一台伺服器,但現在討論的是分布式系統,不止一台伺服器,那麼就很可能出現這種情況,比如停電啊、失火啊、誤操作啊、**把電纜震斷了啊,等等等等。

所以我認為不是系統允許發生這種情況,而是目前根本不存在乙個分布式系統能保證分割槽不發生。因此一般認為p總是成立的,總會有兩個伺服器之間無法傳輸資料。

證明:假設,如果有乙個分布式系統同時滿足cap這三個條件,也就是說

1.乙個伺服器的資料改了之後,再次訪問其它伺服器,會得到修改之後的結果或者其他人對該資料修改後的結果,而不是原來的值。

2.對任意乙個伺服器的訪問的時候,如果伺服器沒崩潰(不是分布式的鍋),那麼伺服器必須給出結果。

3.這個系統設計的時候就允許分割槽的情況發生(你也沒法不允許),即可能會出現兩個伺服器之間無法傳輸資料。

那麼對於這個系統,先模擬一下分割槽的情況發生,兩台伺服器無法傳輸資料。這是乙個人把一台伺服器(x)的乙個資料a改成b,然後向另一台伺服器(y)詢問這個資料結果是什麼。由於分割槽發生了,兩個伺服器之間無法傳輸資料,所以接下來有兩種情況:

1.因為滿足可用性,y返回a,但使用者本該收到b,這就違背了一致性;

2.因為滿足一致性,所以y在資料同步前,不會返回資料給使用者,這就違背了可用性。

假設矛盾,所以無法同時滿足cap三個指標。

分布式系統 CAP理論

cp 天貓雙十一下單搶購,要保證一致性,沒貨了下單失敗 一般來說,如果不需要儲存服務級別的資訊,且服務例項是通過 nacos client 註冊,並能夠保證心跳上報,那麼就可以選擇 ap 模式。當前主流的服務如 spring cloud 和 dubbo 服務,都適用於 ap 模式,ap模式為了服務的...

分布式CAP理論

根據維基百科定義 cap 根據定理,乙個分布式系統最多只能滿足其中兩項,不可能同時滿則c a p三項 首先說一下對各項原則的理解 1 一致性c 單機環境下,資料只有乙份,所有的客戶端訪問的是同乙份資料,不會出現兩個客戶端看到不一樣的資料 分布式環境下,同乙份資料會儲存在多台伺服器上,大量客戶端來訪問...

分布式理論CAP學習

前言 今天背面試題,看到了zookeeper和eureka的區別,看到了cap原則 尷尬了zookeeper 之前學kafka的使用配置過zookeeper集群,但是忘得差不多了 之前使用這些服務註冊的時候並沒有看什麼原理,倒是能夠直接上手,以後還是多看看原理吧,不浮在表面了分布式cap定理,為什麼...