CAP原理詳解「建議收藏」

大家好，又見面了，我是你們的朋友全棧君。

文章目錄

• 一、CAP原理介紹
  • 對CAP原理的一些常見的了解誤區
• 二、CAP原理簡單證明
  • 1. 在保證C和P的情況下
  • 2. 在保證A和P的情況下
  • 3. 在保證A和C的情況下
• 三、CAP原理在各個系統的應用
• 四、總結

一、CAP原理介紹

先簡單介紹一下CAP原理是什麼:

C：Consistency

即一緻性，通路所有的節點得到的資料應該是一樣的。注意，這裡的一緻性指的是強一緻性，也就是資料更新完，通路任何節點看到的資料完全一緻，要和弱一緻性，最終一緻性區分開來。

A：Availability

即可用性，所有的節點都保持高可用性。注意，這裡的高可用還包括不能出現延遲，比如如果節點B由于等待資料同步而阻塞請求，那麼節點B就不滿足高可用性。

也就是說，任何沒有發生故障的服務必須在有限的時間内傳回合理的結果集。

P：Partiton tolerance

即分區容忍性，這裡的分區是指網絡意義上的分區。由于網絡是不可靠的，所有節點之間很可能出現無法通訊的情況，在節點不能通信時，要保證系統可以繼續正常服務。

以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限内達成資料一緻性，就意味着發生了分區的情況，必須就目前操作在C和A之間做出選擇

CAP原理說，一個資料分布式系統不可能同時滿足C和A和P這3個條件。是以系統架構師在設計系統時，不要将精力浪費在如何設計能滿足三者的完美分布式系統，而是應該進行取舍。由于網絡的不可靠性質，大多數開源的分布式系統都會實作P，也就是分區容忍性，之後在C和A中做抉擇。

對CAP原理的一些常見的了解誤區

看到網上很多文章說CAP原理是分布式系統的基石，但是CAP原理其實是對分布式資料存儲系統的一個定論。我們假設一個分布式系統各個節點都讀寫同一個mysql執行個體，那麼對于這個分布式系統來說，讨論CAP原理是沒有意義的。因為各個節點之間可以不用因為資料複制而進行通信，滿足分區容忍性（P），可以随時響應請求，滿足可用性（A），同時因為通路的是一個資料庫執行個體，本身已經保證了資料一緻性（C）。

是以，在讨論CAP原理的時候，更多的是針對那些有資料存儲、資料複制場景的分布式存儲系統，也就是我們熟悉的NoSql資料庫。

由于我們大多數人都不會去設計一款新的NoSql資料庫來使用，更多的是使用現成的NoSql開源系統進行資料的存儲，比如Hbase、MongoDB、Cassandra等。是以大多數時候，其實我們都用不上CAP原理。

雖然用不上，但是了解一下還是沒有壞處的。下面簡單證明一下CAP

二、CAP原理簡單證明

假設有節點data1和節點data2，一開始有個資料number=1。之後向data1送出更新，将資料number設定為2。

接着data1就需要将更新推送給data2，讓data2也更新number資料。

接下來我們分3個場景分析：

1. 在保證C和P的情況下

為了保證資料一緻性，data1需要将資料複制給data2，即data1和data2需要進行通信。但是由于網絡是不可靠的，我們系統有保證了分區容忍性，也就是說這個系統是可以容忍網絡的不可靠的。這時候data2就不一定能及時的收到data1的資料複制消息，當有請求向data2通路number資料時，為了保證資料的一緻性，data2隻能阻塞等待資料真正同步完成後再傳回，這時候就沒辦法保證高可用性了。

是以，在保證C和P的情況下，是無法同時保證A的。

2. 在保證A和P的情況下

為了保證高可用性，data1和data2都有在有限時間内傳回。同樣由于網絡的不可靠，在有限時間内，data2有可能還沒收到data1發來的資料更新消息，這時候傳回給用戶端的可能是舊的資料，和通路data1的資料是不一緻的，也就是違法了C。

也就是說，在保證A和P的情況下，是無法同時保證C的。

3. 在保證A和C的情況下

如果要保證高可用和一緻性，隻有在網絡情況良好且可靠的情況下才能實作。這樣data1才能立即将更新消息發送給data2。但是我們都知道網絡是不可靠的，是會存在丢包的情況的。是以要滿足即時可靠更新，隻有将data1和data2放到一個區内才可以，也就喪失了P這個保證。其實這時候整個系統也不能算是一個分布式系統了。

了解CAP理論的最簡單方式是想象兩個節點分處分區兩側。允許至少一個節點更新狀态會導緻資料不一緻，即喪失了C性質。如果為了保證資料一緻性，将分區一側的節點設定為不可用，那麼又喪失了A性質。除非兩個節點可以互相通信，才能既保證C又保證A，這又會導緻喪失P性質。

三、CAP原理在各個系統的應用

四、總結

關于CAP原理，還需要特别注意的一點是，雖然說我們設計系統時不能同時保證擁有三點。但是也并不是說，保證了其中2點後，就要完全抛棄另外一點。隻是相對的要做一些犧牲。比如在保證CP的情況下，雖然沒辦法保證高可用性，但這不意味着可用性為0，我們可以通過合理的設計盡量的提高可用性，讓可用性盡可能的接近100%。同理，在AP的情況下，也可以盡量的保證資料的一緻性，或者實作弱一緻性，即最終一緻性。

個人認為，對于大資料的研發人員，CAP原理還是有必要了解的。了解了CAP原理後，再去看一些開源的NoSql實作原理也會比較好了解一些。

釋出者：全棧程式員棧長，轉載請注明出處：https://javaforall.cn/124629.html原文連結：https://javaforall.cn