深入理解 CAP 定理
深入理解 CAP 定理
- 什么是 CAP 定理
- 結點、系統、集群
- 一致性、可用性、分區容錯性
- 一致性、可用性、分區容錯性之間的區別
- 為什么不能同時滿足 CAP
- 總結
什么是 CAP 定理
??CAP 定理是分布式系統中必定要了解的內容。它指的是，對于一個分布式系統，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）最多只能同時滿足其中兩個。
??什么是一致性、可用性、分區容錯性呢？在介紹這幾個概念前，先介紹本文需要涉及的三個概念：結點、系統、集群。
結點、系統、集群
-
結點：參與儲存某數據的不可再分的服務器稱為結點。
-
整個系統：參與儲存某數據的所有結點構成整個系統。
-
集群：將整個系統對應的無向圖分為若干互不相連的連通圖。其中每個連通圖對應一個集群。其中，無向圖、連通圖為離散數學中的概念，這里不做詳解。
-
系統：參與儲存某數據的若干集群構成一個系統。
【說明】
??此處是在數學層面上給出集群的抽象定義。在計算機領域中，集群指的是滿足如下條件的進程的集合。
-
這些進程之間相對獨立（這些進程彼此之間沒有進程創建上的父子關系）。
-
這些進程可以在同一個主機上，通過占用這臺主機上不同的端口號來運行，也可以運行在不同的主機中，而這些主機之間可以通過計算機網絡等通信技術來相互連接。
-
這些進程可以通過計算機網絡等通信技術來同步它們之間的數據，從而使它們彼此之間的行為受到一定的制約。
-
這些進程之間都同時使用了計算機網絡等通信技術之外的某一類技術，如 Redis 集群之間都使用了 Redis 技術，Zookeeper 集群之間都使用了 Zookeeper 技術等等。
??結點、集群、系統如圖 1 所示。
圖 1??為了簡化說明，本文再介紹如下約定及概念：
-
本文中的系統均指分布式系統。整個系統中可以只有一個集群，但不能只有一個結點。
-
客戶端對服務端訪問的最小粒度為系統。即客戶端只能對系統進行通信，而不能直接與結點進行通信。
-
本文中的系統均為需要對外提供通信服務的系統，即便系統是內部發生故障之后也是如此。
-
當客戶端對系統發出請求時，只要該系統中有一個結點進行了響應，就視為系統進行了響應。
-
集群中的所有結點必定是連通的。如果集群中某結點或鏈路發生故障，則該集群有可能變成多個集群。
-
數據：當客戶端對系統發出請求時，系統反饋信息的全部內容。
-
數據版本：數據是可能時刻被更新的。某數據在某時刻的完整內容為該數據的一個數據版本。
-
系統中的最新數據：在系統所有的結點中，最新版本的數據。
-
本 CAP 定理是建立在極大似然估計、長期這個兩個意義之上的。
-
不管使用任何技術來防范，如果系統中所有的結點都長期同時發生故障，這都必定同時不滿足 CAP 定理（一致性、可用性、分區容錯性）中的任何一個。但這里認為 ：
-
系統中所有的結點同時發生永久性故障 是不可能事件。
-
系統中某結點發生永久性故障 是不可能事件。
-
系統中某結點之間的鏈路短期發生故障 是可能事件。
-
系統中某結點短期發生故障 是可能事件。當某結點短期發生故障時，也認為與該結點相連的鏈路也同時發生故障。
-
短期所有結點、鏈路都不發生任何故障 是可能事件。
-
故障是隨機的，不可能使用某種算法提前準確預知的。
-
數據總是時刻隨機變化的，通過以往數據精確預知某數據的變化是不可能的。
-
-
CAP 是建立在長遠來看的實現。短期是可能同時滿足 CAP 的，CAP 定理針對的長期情況下的滿足，而長期來講，任何結點、鏈路都有可能發生故障。
（極大似然估計、不可能事件、可能事件均為概率論中的概念，這里不做詳解。）
-
一致性、可用性、分區容錯性
??下面來解釋什么是一致性、可用性、分區容錯性。
-
一致性：當每次客戶端對系統發出請求后，若直至該系統進行響應前，系統的連通性不發生變化。當該系統進行響應時，反饋的數據是 系統中的最新完整數據，則稱該系統滿足一致性。
【注意】
-
一致性是針對系統響應信息之時來說的。如果該系統不及時進行響應，不能認為該系統不滿足一致性。即對于一致性，系統可以選擇等到能保證一致性時再進行響應來保證。
如果系統一直不進行響應，則這種情況對一致性來說是未定義的。即無法界定該系統是否滿足一致性，但一般認為此時系統至少不滿足可用性。研究人員可以增加附加條件來對此情況進行界定，比如強制規定一個最晚響應時間。如果系統超過這個時間沒有進行響應，就認為該系統響應的是一個空白數據。此時就相當于將一直不進行響應當作是不滿足一致性。
-
如果系統中有某結點發生故障，則此時對客戶端反饋的信息必定不能滿足一致性。但認為沒有結點會發生永久性的故障。
-
本文中的系統均指分布式系統。系統中可以只有一個集群，但不能只有一個結點。不能通過在系統中只使用一個結點來達成一致性。
-
任何結點上的數據都可能動態變化，不能認定數據未來不再變化而實現一致性。
-
-
可用性：若當每次客戶端對系統發出請求，到該系統進行響應之間的時間，小于一個事先約定的定值，則稱該系統滿足可用性。
【注意】
- 此定值可長可短，但要是一個與“技術攻關用時”、“網絡恢復通暢用時”無關的值。
-
分區容錯性：對于不同的場景要求，可以是以下定義之一：
-
對于有可能發生故障的鏈路，即便是已經發生故障，此時當每次客戶端對任意系統發出請求后，該系統進行響應時，反饋的數據都令人滿意，則稱該系統滿足分區容錯性。
-
對于有可能發生故障的鏈路，即便是已經發生故障，此時當每次客戶端對任意系統發出請求后，該系統進行響應時，反饋的數據是任意一個版本的完整數據，則稱該系統滿足分區容錯性。
【注意】
-
分區容錯性中的分區，對應這里的系統。
-
分區容錯性是針對系統響應信息之時來說的。如果該系統不及時進行響應，不能認為該系統不滿足分區容錯性。即對于分區容錯性，系統可以選擇等到能保證分區容錯性時再進行響應來保證。
-
完整數據可以分散到系統的多個結點中。如果系統中所有結點合起來都不能提供完整的數據，則認為此時該系統不滿足分區容錯性。
特別地，如果某系統中只有一個結點，則認為該系統不滿足分區容錯性。因為如果該結點故障，則該系統就不能對外提供服務。
-
-
一致性、可用性、分區容錯性之間的區別
-
一致性、可用性之間的區別：
這兩個概念很容易區分，從略。
-
分區容錯性、可用性之間的區別：
這兩個概念很容易區分，從略。
-
一致性、分區容錯性之間的區別：
一致性描述的是當系統沒有發生故障時的響應情況。而分區容錯性描述的是系統沒有發生故障和已經發生可能故障時的響應情況，且一致性對響應的要求強于分區容錯性。
一致性與分區容錯性描述的時系統在不同條件下的表現，它們之間沒有包含關系，只是概念上有些相交。當一致性被滿足時，分區容錯性未必會被滿足。
為什么不能同時滿足 CAP
??假設已經滿足了 CAP 中的兩者：
-
CP：如果滿足了一致性，則系統中各結點必定連通。但系統的連通不是永恒的，如果由于關鍵性的故障，系統被分成多個集群，此時就需要一些時間來等待故障被消除，因此此時不能滿足 A。
-
AP：如果滿足了可用性與分區容錯性，說明系統中的各個集群都能做到獨立工作和及時反饋。如果此時要求還要滿足一致性，則會破壞它們之間的獨立性，從而影響它們之中的可用性。
-
CA：如果滿足了一致性，則系統中各結點必定連通。如果同時滿足 CA，則要求系統中各結點一直保持連通。這就會導致系統對鏈路故障零容忍。因為如果系統中發生了關鍵性的故障，系統內部將被劃分成互不相連的多個集群。由于不能與其它集群進行通信，所以每個集群都不能保證自己的數據是最新數據，如果還要求它們即時反饋，則將不滿足一致性。
總結
-
CAP 之間的側重點各有不同：
-
一致性代表著系統之間能否實現數據同步。
-
可用性代表著系統能否實現對外的即時反饋。
-
分區容錯性指的是系統之間的獨立性。
-
-
一般會優先實現分區容錯性、可用性。
總結
以上是生活随笔為你收集整理的深入理解 CAP 定理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux 下 Redis 安装教程
- 下一篇： 不使用 Maven 等构建工具，而使用原