大家好，歡迎來到Tlog4J課堂，我是Jensen。

分布式CAP定理大家也耳熟能詳了，CAP指的是分布式系統(tǒng)中的三個特性：

在我之前的文章也有提到過——CAP是分布式系統(tǒng)中三個維度的“客戶承諾”：

• 一致性(Consistency)：要么我給你返回一個錯誤，要么我給你返回絕對一致的最新數據，強調數據正確。
• 可用性(Availibility)：我一定會給你返回數據，不會給你返回錯誤，但不保證數據最新，強調的是服務不出錯。
• 分區(qū)容錯性(Partition Tolerance)：我會一直運行，不管我的內部出現何種數據同步問題，強調的是不掛掉。

在Jeff Hodges精彩的博文筆記中，他建議我們用 CAP 定理來評論分布式系統(tǒng)，并且很多人都聽取了這個建議，描述他們的系統(tǒng)為“CP” (有一致性但在網絡分區(qū)的時候不可用)，“AP”(可用但是在網絡分區(qū)的時候不一致) 或者有時候 “CA”。

那這次咱們再深入探討一下，不同的系統(tǒng)按CP/AP來劃分，到底合不合理。

回過頭來看一致性

首先我們要了解，數據的一致性問題存在于計算機軟硬件層面的任意一個數據拷貝的環(huán)節(jié)，如CPU與內存的數據拷貝、內存間的數據拷貝、內存與磁盤的數據拷貝、計算機之間的網絡通訊等等。

而分布式系統(tǒng)是基于軟件系統(tǒng)的，系統(tǒng)分布在不同的計算機必然會產生網絡通訊延遲或網絡分區(qū)的情況，以我們現在的計算機技術是無法100%解決一致性問題的。

CAP中的一致性是可線性化的意思，它是非常特殊、非常強的一致性，雖然說ACID中的C也是一致性，但和CAP的一致性沒有任何關系。

那什么是可線性化呢?

舉個例子：如果B操作在完成A操作成功之后，那么整個系統(tǒng)對B操作來說必須表現為A操作已經完成了或者更新的狀態(tài)。

這張圖展示了 Alice 還有 Bob, 他們在同一個房間，都在用他們的手機查詢 2014 年世界杯的決賽結果。

就在最終結果剛發(fā)布之后，Alice 刷新了頁面，看到了宣布冠軍的消息，而且很興奮地告訴了 Bob。

Bob 馬上也重新加載了他手機上的頁面，但是他的請求被送到了一個數據庫的拷貝，還沒有拿到產生結果的數據，結果他的手機上顯示決賽還正在進行。

如果 Alice 和 Bob 同時刷新，拿到了不一樣的結果，并不會太讓人意外，因為他們不知道具體服務器到底是先處理了他們中哪一個請求。

但是 Bob 知道他刷新頁面是在 Alice 告訴了他最終結果之后的，所以他預期他查詢的結果一定比 Alice 的更新，但事實是他卻拿到了舊的結果，這就違反了可線性化。

只有 Bob 通過另外一個溝通渠道從 Alice 那里知道了結果， Bob 才能知道他的請求一定在 Alice 之后。

如果 Bob 沒有從 Alice 那里聽到比賽已經結束了，他就不會知道他看到的結果是舊的。

如果你在建一個數據庫，你不知道用戶們會有什么另外的溝通渠道，所以，如果你想提供可線性化訪問，你就需要讓你的數據庫看起來就好像只有一個拷貝，雖然實際上可能有多個備份在多個地方。

這是一個非常昂貴的屬性，因為它要求你做很多協(xié)調工作，甚至你電腦上的CPU都不提供本地內存的可線性化訪問!

在現代的CPU上，你需要用Memory Barrier指令來達到可線性化訪問，甚至測試一個系統(tǒng)是不是可線性化的也是非常困難的。

所以說，脫離了關注點，討論一致性沒有多大意義。

回過頭來看可用性

可用性在CAP中是定義為“每一個請求如果被一個工作中的[數據庫]節(jié)點收到，那一定要返回[非錯誤的]結果”。

注意到，這里一部分節(jié)點可以處理這個請求是不充分的，任意一個工作中的節(jié)點都要可以處理這個請求，所以很多自稱高可用的系統(tǒng)通常并沒有滿足這里的可用性的定義，它們只是做了故障轉移或者是熔斷降級而已。

CAP中根本沒有提到延遲，而我們其實對延遲比可用性更關心，事實上，滿足CAP可用性的系統(tǒng)可以花任意長的時間來回復一個請求，而且同時保持可用性這個屬性。

但如果你的系統(tǒng)要花兩分鐘來加載一個頁面，你的用戶絕對不會認為它是“可用的”，這也是為什么現在互聯(lián)網項目大多只允許2~10秒的請求延遲。

CP和AP的取舍

CAP定理只考慮了網絡分區(qū)這一種故障情況(比如所有節(jié)點還在運行，但是他們之間的網絡已經不工作了)，這種故障絕對會發(fā)生，但是這不是唯一會出故障的地方。

節(jié)點可以整個崩潰或者重啟，你可能沒有足夠的磁盤空間，你可能會遇到一個軟件故障(bug)，等等，在建分布式系統(tǒng)的時候，你需要考慮到更多得多的問題，如果太關注CAP就容易導致忽略了其他重要的問題。

那為什么在網絡分區(qū)的情況下，我們要放棄可用性和一致性中的一個呢?

舉個例子：你的數據庫有兩個拷貝在兩個不同的數據中心，具體怎么做備份并不重要，可以是Single-Master，或者多個Leader，或者基于Quorum的備份，要求是當數據被寫到一個數據中心的時候，它也一定要被寫到另一個數據中心。

假設Client只連接到其中一個數據中心，而且連接兩個數據中心的網絡故障了，網絡中斷了就是我們所說的網絡分區(qū)的意思，接下來會怎樣呢?

我們有兩個選擇：

• 應用還是被允許寫到數據庫，兩邊的數據庫還是完全可用的。但是一旦兩個數據庫之間的網絡中斷了，任何一個數據中心的寫操作就不會同步到另一個數據中心。這違反了可線性化(用之前的例子，Alice 可能鏈接到了一號數據中心，而 Bob 連接到了二號數據中心)。
• 如果你不想失去可線性化，就必須保證你的讀寫操作都在同一個數據中心，你可能叫它 Leader，另一個數據中心，因為網絡故障不能被更新，就必須停止接收讀寫操作，直到網絡恢復，兩邊數據庫又進行同步。所以雖然非Leader數據庫正常運行，但是他卻不能處理請求，這就違反了 CAP 的可用性定義。

這個其實就是 CAP 定理的證明，咱們這里的例子用到了兩個數據中心，但對于一個數據中心內的網絡故障也同樣適用，之所以這里用兩個數據中心是因為更容易考慮這個問題。

當一個系統(tǒng)選擇了可線性化，也就是說不是 CAP 可用的，并不意味著網絡分區(qū)一定會造成應用停運。

如果你可以把用戶的流量轉移到Leader數據庫，那么用戶根本就不會注意到任何問題。

實際應用中的可用性和CAP可用性并不相同，咱們應用的可用性多數是通過SLA來衡量的，比如99.9%正確的請求一定要在一秒鐘之內返回成功，這實際上是一種整體的衡量。

但是一個系統(tǒng)無論是否滿足CAP可用性其實都可以滿足這樣的SLA，在實際操作中，跨多個數據中心的系統(tǒng)經常是通過異步備份的，所以不是可線性化的。

但是做出這個選擇的原因經常是因為遠距離網絡的延遲，而不是僅僅為了處理數據中心的網絡故障。

寫在最后

CAP定理其實是一個被簡化了的理論，以致于被大眾廣泛地誤解了，實際上CAP是一個非常精確的定義。

其實大部分軟件都不在CP/AP這兩類中，但人們還是強行把軟件分為這兩類，這導致為了適用，不可避免地改變對“一致性”或者“可用性”的定義，如果用詞的定義改變了，CAP定理自己也不適用了，那CP/AP劃分也就完全沒有意義了。

所以，在技術面試的時候，我再也不會問“哪些框架是CP的，哪些框架是AP的”這個問題了，這么問其實沒多大意義。

從另一方面看，CAP也是被廣泛接受的分布式基礎理論，很多框架也可以通過不同的配置實現廣義上的CP/AP，與其花時間跟別人解釋一堆按CP/AP來劃分系統(tǒng)是怎么不合理的，不如坦然接受現狀，但是別忘了，心中也要有自己的答案。

獨立思考，保持好奇心和耐心。