CAP原則又稱CAP定理，指的是在一個分布式系統中，Consistency（一緻性）、 Availability（可用性）、Partition tolerance（分區容錯性）這三個基本需求，最多隻能同時滿足其中的2個。

1. CAP原則簡介

什麼是分區？

在分布式系統中，不同的節點分布在不同的子網絡中，由于一些特殊的原因，這些子節點之間出現了網絡不通的狀态，但他們的内部子網絡是正常的。從而導緻了整個系統的環境被切分成了若幹個孤立的區域，這就是分區。

2. CAP原則論證

如圖所示，是我們證明CAP的基本場景，網絡中有兩個節點N1和N2，可以簡單的理解N1和N2分别是兩台計算機，他們之間網絡可以連通，N1中有一個應用程序A，和一個數據庫V，N2也有一個應用程序B和一個數據庫V。現在，A和B是分布式系統的兩個部分，V是分布式系統的數據存儲的兩個子數據庫。

• 在滿足一緻性的時候，N1和N2中的數據是一樣的，V0=V0。
• 在滿足可用性的時候，用戶不管是請求N1或者N2，都會得到立即響應。
• 在滿足分區容錯性的情況下，N1和N2有任何一方宕機，或者網絡不通的時候，都不會影響N1和N2彼此之間的正常運作。

如圖所示，這是分布式系統正常運轉的流程，用戶向N1機器請求數據更新，程序A更新數據庫V0為V1。分布式系統将數據進行同步操作M，将V1同步的N2中V0，使得N2中的數據V0也更新為V1，N2中的數據再響應N2的請求。

根據CAP原則定義，系統的一緻性、可用性和分區容錯性細分如下：

• 一緻性：N1和N2的數據庫V之間的數據是否完全一樣。
• 可用性：N1和N2的對外部的請求能否做出正常的響應。
• 分區容錯性：N1和N2之間的網絡是否互通。

這是正常運作的場景，也是理想的場景。作為一個分布式系統，它和單機系統的最大區别，就在于網絡。現在假設一種極端情況，N1和N2之間的網絡斷開了，我們要支持這種網絡異常。相當于要滿足分區容錯性，能不能同時滿足一緻性和可用性呢？還是說要對他們進行取舍？

假設在N1和N2之間網絡斷開的時候，有用戶向N1發送數據更新請求，那N1中的數據V0将被更新為V1。由于網絡是斷開的，所以分布式系統同步操作M，所以N2中的數據依舊是V0。這個時候，有用戶向N2發送數據讀取請求，由于數據還沒有進行同步，應用程序沒辦法立即給用戶返回最新的數據V1，怎麼辦呢？

這裡有兩種選擇：

• 第一：犧牲數據一緻性，保證可用性。響應舊的數據V0給用戶。
• 第二：犧牲可用性，保證數據一緻性。阻塞等待，直到網絡連接恢複，數據更新操作M完成之後，再給用戶響應最新的數據V1。

這個過程，證明了要滿足分區容錯性的分布式系統，隻能在一緻性和可用性兩者中，選擇其中一個。

3. CAP原則權衡

通過CAP理論，我們知道無法同時滿足一緻性、可用性和分區容錯性這三個特性，那要舍棄哪個呢？

3.1. CA without P

如果不要求P（不允許分區），則C（強一緻性）和A（可用性）是可以保證的。但其實分區不是你想不想的問題，而是始終會存在，因此CA的系統更多的是允許分區後各子系統依然保持CA。

3.2. CP without A

如果不要求A（可用），相當于每個請求都需要在Server之間強一緻，而P（分區）會導緻同步時間無限延長，如此CP也是可以保證的。很多傳統的數據庫分布式事務都屬于這種模式。

3.3. AP wihtout C

要高可用并允許分區，則需放棄一緻性。一旦分區發生，節點之間可能會失去聯系，為了高可用，每個節點隻能用本地數據提供服務，而這樣會導緻全局數據的不一緻性。現在衆多的NoSQL都屬于此類。

小結

對于多數大型互聯網應用的場景，主機衆多、部署分散。而且現在的集群規模越來越大，所以節點故障、網絡故障是常态。這種應用一般要保證服務可用性達到N個9，即保證P和A，隻有舍棄C（退而求其次保證最終一緻性）。雖然某些地方會影響客戶體驗，但沒達到造成用戶流程的嚴重程度。

對于涉及到錢财這樣不能有一絲讓步的場景，C必須保證。網絡發生故障甯可停止服務，這是保證CA，舍棄P。貌似這幾年國内銀行業發生了不下10起事故，但影響面不大，報到也不多，廣大群衆知道的少。還有一種是保證CP，舍棄A，例如網絡故障時隻讀不寫。

孰優孰劣，沒有定論，隻能根據場景定奪，适合的才是最好的

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部