我是如何用CAP和BASE兩個基礎理論卷死其他組員的？

本文內容整理自 博學谷狂野架構師

​ CAP 定理又被稱作布魯爾定理，是加州大學的電腦科學家布魯爾在 2000 年提出的一個猜想。2002 年，麻省理工學院的賽斯·吉爾伯特和南希·林奇發表了布魯爾猜想的證明，使之成為分散式計算領域公認的一個定理。

​ 布魯爾在提出CAP猜想時並沒有具體定義 Consistency、Availability、Partition Tolerance 這3個詞的含義，不同資料的具體定義也有差別，為了更好地解釋，下面選擇Robert Greiner的文章《CAP Theorem》作為參考基礎。

CAP理論的定義

在一個分散式系統（指互相連線並共享資料的節點的集合）中，當涉及讀寫操作時，只能保證一致性（Consistence）、可用性（Availability）、分割槽容錯性（PartitionTolerance）三者中的兩個，另外一個必須被犧牲。

Consistency、Availability、Partition Tolerance具體解釋如下：

C - Consistency 一致性

A read is guaranteed to return the most recent write for a given client. 對某個指定的客戶端來說，讀操作保證能夠返回最新的寫操作結果。

​ 這裡並不是強調同一時刻擁有相同的資料，對於系統執行事務來說，在事務執行過程中，系統其實處於一個不一致的狀態，不同的節點的資料並不完全一致。

​ 一致性強調客戶端讀操作能夠獲取最新的寫操作結果，是因為事務在執行過程中，客戶端是無法讀取到未提交的資料的，只有等到事務提交後，客戶端才能讀取到事務寫入的資料，而如果事務失敗則會進行回滾，客戶端也不會讀取到事務中間寫入的資料。

A - Availability 可用性

A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout). 非故障的節點在合理的時間內返回合理的響應（不是錯誤和超時的響應）。

​ 這裡強調的是合理的響應，不能超時，不能出錯。注意並沒有說“正確”的結果，例如，應該返回 100 但實際上返回了 90，肯定是不正確的結果，但可以是一個合理的結果。

P - Partition Tolerance 分割槽容忍性

The system will continue to function when network partitions occur. 當出現網路分割槽後，系統能夠繼續“履行職責”。

這裡網路分割槽是指： 一個分散式系統裡面，節點組成的網路本來應該是連通的。然而可能因為一些故障（節點間網路連線斷開、節點宕機），使得有些節點之間不連通了，整個網路就分成了幾塊區域，資料就散佈在了這些不連通的區域中。

一致性、可用性、分割槽容忍性的選擇

​ 雖然 CAP 理論定義是三個要素中只能取兩個，但放到分散式環境下來思考，我們會發現必須選擇 P（分割槽容忍）要素，因為網路本身無法做到 100% 可靠，有可能出故障，所以分割槽是一個必然的現象。

​ 如果我們選擇了 CA（一致性 + 可用性） 而放棄了 P（分割槽容忍性），那麼當發生分割槽現象時，為了保證 C（一致性），系統需要禁止寫入，當有寫入請求時，系統返回 error（例如，當前系統不允許寫入），這又和 A(可用性) 衝突了，因為 A（可用性）要求返回 no error 和 no timeout。

因此，分散式系統理論上不可能選擇 CA （一致性 + 可用性）架構，只能選擇 CP（一致性 + 分割槽容忍性） 或者 AP （可用性 + 分割槽容忍性）架構，在一致性和可用性做折中選擇。

CP - Consistency + Partition Tolerance （一致性 + 分割槽容忍性）

​ 如上圖所示，因為Node1節點和Node2節點連線中斷導致分割槽現象，Node1節點的資料已經更新到y，但是Node1 和 Node2 之間的複製通道中斷，資料 y 無法同步到 Node2，Node2 節點上的資料還是舊資料x。

​ 這時客戶端C 訪問 Node2 時，Node2 需要返回 Error，提示客戶端 “系統現在發生了錯誤”，這種處理方式違 背了可用性（Availability）的要求，因此 CAP 三者只能滿足 CP。

AP - Availability + Partition Tolerance （可用性 + 分割槽容忍性）

​ 同樣是Node2 節點上的資料還是舊資料x，這時客戶端C 訪問 Node2 時，Node2 將當前自己擁有的資料 x 返回給客戶端 了，而實際上當前最新的資料已經是 y 了，這就不滿足一致性（Consistency）的要求了，因此 CAP 三者只能滿足 AP。

​ 注意：這裡 Node2 節點返回 x，雖然不是一個“正確”的結果，但是一個“合理”的結果，因為 x 是舊的資料，並不是一個錯亂的值，只是不是最新的資料。

​ 值得補充的是，CAP理論告訴我們分散式系統只能選擇AP或者CP，但實際上並不是說整個系統只能選擇AP或者CP，在 CAP 理論落地實踐時，我們需要將系統內的資料按照不同的應用場景和要求進行分類，每類資料選擇不同的策略（CP 還是 AP），而不是直接限定整個系統所有資料都是同一策略。

​ 另外，只能選擇CP或者AP是指系統發生分割槽現象時無法同時保證C（一致性）和A（可用性），但不是意味著什麼都不做，當分割槽故障解決後，系統還是要保持保證CA。

CAP理論的延伸——BASE理論

​ BASE 是指基本可用（Basically Available）、軟狀態（ Soft State）、最終一致性（ Eventual Consistency），核心思想是即使無法做到強一致性（CAP 的一致性就是強一致性），但應用可以採用適合的方式達到最終一致性。

BA - Basically Available 基本可用

分散式系統在出現故障時，允許損失部分可用性，即保證核心可用。

​ 這裡的關鍵詞是“部分”和“核心”，實際實踐上，哪些是核心需要根據具體業務來權衡。例如登入功能相對註冊功能更加核心，註冊不了最多影響流失一部分使用者，如果使用者已經註冊但無法登入，那就意味使用者無法使用系統，造成的影響範圍更大。

S - Soft State 軟狀態

​ 允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。這裡的中間狀態就是 CAP 理論中的資料不一致。

E - Eventual Consistency 最終一致性

系統中的所有資料副本經過一定時間後，最終能夠達到一致的狀態。

​ 這裡的關鍵詞是“一定時間” 和 “最終”，“一定時間”和資料的特性是強關聯的，不同業務不同資料能夠容忍的不一致時間是不同的。例如支付類業務是要求秒級別內達到一致，因為使用者時時關注；使用者發的最新微博，可以容忍30分鐘內達到一致的狀態，因為使用者短時間看不到明星發的微博是無感知的。而“最終”的含義就是不管多長時間，最終還是要達到一致性的狀態。

BASE 理論本質上是對 CAP 的延伸和補充，更具體地說，是對 CAP 中 AP 方案的一個補充：

• CP 理論是忽略延時的，而實際應用中延時是無法避免的。 這一點就意味著完美的 CP 場景是不存在的，即使是幾毫秒的資料複製延遲，在這幾毫秒時間間隔內，系統是不符合 CP 要求的。因此 CAP 中的 CP 方案，實際上也是實現了最終一致性，只是“一定時間”是指幾毫秒而已。

• AP 方案中犧牲一致性只是指發生分割槽故障期間，而不是永遠放棄一致性。 這一點其實就是 BASE 理論延伸的地方，分割槽期間犧牲一致性，但分割槽故障恢復後，系統應該達到最終一致性。

資料一致性模型

前面介紹的BASE模型提過“強一致性”和“最終一致性”，下面對這些一致性模型展開介紹。

​ 分散式系統通過複製資料來提高系統的可靠性和容錯性，並且將資料的不同的副本存放在不同的機器上，由於維護資料副本的一致性代價很高，因此許多系統採用弱一致性來提高效能，下面介紹常見的一致性模型：

強一致性

	要求無論更新操作是在哪個資料副本上執行，之後所有的讀操作都要能獲得最新的資料。對於單副本資料來說，讀寫操作是在同一資料上執行的，容易保證強一致性。對多副本資料來說，則需要使用分散式事務協議。

弱一致性

	在這種一致性下，使用者讀到某一操作對系統特定資料的更新需要一段時間，我們將這段時間稱為"不一致性視窗"。

最終一致性

​ 是弱一致性的一種特例，在這種一致性下系統保證使用者最終能夠讀取到某操作對系統特定資料的更新（讀取操作之前沒有該資料的其他更新操作）。"不一致性視窗"的大小依賴於互動延遲、系統的負載，以及資料的副本數等。

總結

​ 系統選擇哪種一致性模型取決於應用對一致性的需求，所選取的一致性模型還會影響到系統如何處理使用者的請求以及對副本維護技術的選擇等。後面將基於上面介紹的一致性模型分別介紹分散式事務的解決方案。

柔性事務

柔性事務的概念

​ 在電商等網際網路場景下，傳統的事務在資料庫效能和處理能力上都暴露出了瓶頸。在分散式領域基於CAP理論以及BASE理論，有人就提出了柔性事務的概念。

​ 基於BASE理論的設計思想，柔性事務下，在不影響系統整體可用性的情況下(Basically Available 基本可用)，允許系統存在資料不一致的中間狀態(Soft State 軟狀態)，在經過資料同步的延時之後，最終資料能夠達到一致。並不是完全放棄了ACID，而是通過放寬一致性要求，藉助本地事務來實現最終分散式事務一致性的同時也保證系統的吞吐。

實現柔性事務的一些特性

下面介紹的是實現柔性事務的一些常見特性，這些特性在具體的方案中不一定都要滿足，因為不同的方案要求不一樣。

可見性(對外可查詢)

​ 在分散式事務執行過程中，如果某一個步驟執行出錯，就需要明確的知道其他幾個操作的處理情況，這就需要其他的服務都能夠提供查詢介面，保證可以通過查詢來判斷操作的處理情況。

​ 為了保證操作的可查詢，需要對於每一個服務的每一次呼叫都有一個全域性唯一的標識，可以是業務單據號（如訂單號）、也可以是系統分配的操作流水號（如支付記錄流水號）。除此之外，操作的時間資訊也要有完整的記錄。

操作冪等性

​ 冪等性，其實是一個數學概念。冪等函式，或冪等方法，是指可以使用相同引數重複執行，並能獲得相同結果的函式。冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。也就是說，同一個方法，使用同樣的引數，呼叫多次產生的業務結果與呼叫一次產生的業務結果相同。

​ 之所以需要操作冪等性，是因為為了保證資料的最終一致性，很多事務協議都會有很多重試的操作，如果一個方法不保證冪等，那麼將無法被重試。冪等操作的實現方式有多種，如在系統中快取所有的請求與處理結果、檢測到重複操作後，直接返回上一次的處理結果等。

本文由傳智教育博學谷狂野架構師教研團隊釋出。

如果本文對您有幫助，歡迎關注和點贊；如果您有任何建議也可留言評論或私信，您的支援是我堅持創作的動力。

轉載請註明出處！