前言

我們學習分布式系統，就一定聽說過CAP定理，尤其在學習分布式事務時，都是以這個定理作為開場。這個定理起源于柏克萊加州大學的計算機科學家埃里克·布魯爾在2000年的分布式計算原則研討會上提出的一個猜想。 在2002年，麻省理工學院的賽斯·吉爾伯特和南希·林奇發表了布魯爾猜想的證明，使之成為一個定理。

讀者福利：Java分布式中間件學習筆記共享。

定理討論了在兩個互相矛盾的請求到達彼此連接不通的兩個不同的分布式節點的時候的處理方案。

CAP針對對象

先上個圖

上圖中，是我們常見的系統設計，web服務集群化，mysql數據庫做主從，數據庫做主從可實現讀寫分離，分擔壓力。

我們看到Mysql數據庫產品，可以進行分布式部署（集群方式，也支持單機），研發Mysql數據庫的工程師是要完成很多業務點（如：最基本的對數據增刪改查）。其中有很重要的點就是CAP定理的平衡。

所謂的CAP定理，是針對分布式系統闡述的，如在分布式環境下，Mysql是怎么平衡CAP的？

說了半天的CAP，到底什么是CAP定理？我們先看一下C、A、P各是什么含義？

CAP的定義

一、C全稱Consistency（一致性）

這個表示所有節點返回的數據是一致的。

如：上圖用戶寫了一篇文章A，數據插入到主Mysql。這時其他用戶讀寫這篇文章時，要必須能夠讀到。
因為讀取請求是走的從Mysql，就必須要求主mysql和從mysql同時更新了數據。

二、A全稱Availability（可用性）

每一個非故障節點，都能夠對每一個請求做出響應。說白了就是某個節點壞了，不能影響其他的節點業務。

如：主mysql掛了，但他不影響從mysql節點對外提供服務，用戶還是可以讀取數據的，只是不能寫而已。
（小伙伴們就會問，那不能寫了啊，還算可用性嗎？這里的可用性的定義是非故障節點，對每個請求做出響應；有故障的不算）

三、P全稱Partition tolerance（分區容錯性）

當系統中有節點因網絡原因無法通信時，系統依然可以繼續運行。

分布式系統由多個節點組成，就像mysql集群，由多個mysql節點組成。節點間的網絡通信總是不可靠的，所以我們總是要保證分布式系統節點間出現網絡故障時，分布式系統還是可用的，這種系統才有意義

可用性和容錯性的區別

很多小伙伴在這一點比較容易糊涂，很多網上的資料也是錯誤的，針對這一點講的不是很清楚。

一、可用性

是針對非故障節點，如主mysql節點掛了，但從mysql沒有掛，而且從mysql照樣提供服務，就說明此分布式系統具有可用性。

（小伙伴們不要和mysql的主從切換混淆了，主從切換是mysql提供的高可用性一種方案，跟這里的可用性是兩個緯度）

二、分區容錯性

是各個節點出現網絡問題時，系統依然可用。如主Mysql和從Mysql 之間沒法通信時，系統可用。

總結：可用性針對節點出現故障，系統可用；分區容錯性針對網絡出現問題，系統可用

CAP定理

我們了解了CAP中的三個定義，CAP定理是表示分布式系統只能滿足三項中的兩項，而不可能滿足全部三項。即分布式系統只能滿足三種情況：CA、AP、CP。

我們來分析一下，我們先看P，也就是分區容錯性；在分布式系統中，網絡異常是不可避免的，所以如果不保證分區容錯性，除非節點間網絡不會發生異常，這個是不可能的（除非單機系統，單機系統就不是分布式系統）。

分布式系統肯定要實現P，那其實CA是理論上面的，其實不存在。

取舍

看一下圖

主Mysql和從Mysql之間出現了網絡異常，那研發Mysql的工程師如何去做？

場景一：更新操作主Mysql成功了，就返回成功

寫請求把用戶姓名【張三】改為【李四】，寫請求寫入主Mysql成功后，系統就直接返回成功；然后再通過主Mysql的binlog日志方式把數據同步到從Mysql。

這種方式其實是放棄了數據一致性。因為如果出現網絡延遲，數據沒有及時同步到從Mysql，那就導致了主Mysql值為李四，而從Mysql值為張三，導致數據不一致。但主從mysql照樣可以提供服務，也就是保證了可用性A。

即此方案為AP

場景二：更新操作主從mysql都成功了，才返回成功

寫請求把用戶姓名【張三】改為【李四】，寫請求一定要等到主從mysql都寫入成功了，系統才能成功返回。

這種方式保證了數據一致性，因為主從mysql更新數據都成功才算成功，但網絡出現問題時，主mysql無法訪問從節點，導致寫操作一直不成功。

其實就是放棄了可用性，只滿足CP原則，系統只能提供讀服務。

小伙伴們會說不是系統能夠提供讀服務嗎？應該系統是可用的啊。我們再看看可用性的定義：非故障節點，要能夠提供服務。
而這里主Mysql節點是正常的（符合非故障節點），而不能提供寫請求，不符合可用性原則

綜合來看，再滿足P的前提下，是不可能同時滿足C和A的。

權衡

在我們架構師開發分布式系統時，是需要根據業務進行權衡的。

在我們大型互聯網公司，因為機器數量龐大，網絡故障是常態，一般選擇AP原則，犧牲掉數據一致性。（一些金融產品對數據一致性要求很高的，就會選擇CP）。

小伙伴們會問，那數據很重要啊，不一致那怎么搞？

當然有別的方案會保證數據最終一致性，也就是BASE理論的提出，小伙伴們可自行查閱。

我們看看常用的分布式系統的權衡：

1、Redis中間件 ----> AP
2、RocketMQ中間件 -----> AP
3、分布式事務-2pc ----> CP
4、分布式事務-最大努力嘗試 ---> AP
5、Eureka ---> AP

小伙伴們看看Mysql是屬于什么？

提醒：看看Mysql 的同步機制

總結

很多中間件核心的問題就是解決在網絡出現分區（異常）時，如何把數據從多節點間進行傳輸，都是在CA當中做權衡，設計了一些方案，讓系統在C和A之間得到合理的控制。

原文鏈接：https://www.toutiao.com/i6716373012393755148/?

總結

以上是生活随笔為你收集整理的分布式系统CAP理论：CAP原则只能满足其中两项！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。