轉載 https://blog.csdn.net/u013332124/article/details/82874178
文章目錄
一、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實現原理也會比較好理解一些。