一.CAP理論

CAP 理論/定理open in new window起源于 2000年，由加州大學伯克利分校的Eric Brewer教授在分布式計算原理研討會（PODC）上提出，因此 CAP定理又被稱作?布魯爾定理（Brewer’s theorem）

2年后，麻省理工學院的Seth Gilbert和Nancy Lynch 發(fā)表了布魯爾猜想的證明，CAP理論正式成為分布式領(lǐng)域的定理。

簡介

CAP?也就是?Consistency（一致性）、Availability（可用性）、Partition Tolerance（分區(qū)容錯性）?這三個單詞首字母組合。

CAP 理論的提出者布魯爾在提出 CAP 猜想的時候，并沒有詳細定義?Consistency、Availability、Partition Tolerance?三個單詞的明確定義。

因此，對于 CAP 的民間解讀有很多，一般比較被大家推薦的是下面 👇 這種版本的解讀。

在理論計算機科學中，CAP 定理（CAP theorem）指出對于一個分布式系統(tǒng)來說，當設計讀寫操作時，只能同時滿足以下三點中的兩個：

• 一致性（Consistency）?: 所有節(jié)點訪問同一份最新的數(shù)據(jù)副本
• 可用性（Availability）: 非故障的節(jié)點在合理的時間內(nèi)返回合理的響應（不是錯誤或者超時的響應）。
• 分區(qū)容錯性（Partition tolerance）?: 分布式系統(tǒng)出現(xiàn)網(wǎng)絡分區(qū)的時候，仍然能夠?qū)ν馓峁┓铡?/li>

什么是網(wǎng)絡分區(qū)？

分布式系統(tǒng)中，多個節(jié)點之前的網(wǎng)絡本來是連通的，但是因為某些故障（比如部分節(jié)點網(wǎng)絡出了問題）某些節(jié)點之間不連通了，整個網(wǎng)絡就分成了幾塊區(qū)域，這就叫網(wǎng)絡分區(qū)。

不是所謂的“3 選 2”

大部分人解釋這一定律時，常常簡單的表述為：“一致性、可用性、分區(qū)容忍性三者你只能同時達到其中兩個，不可能同時達到”。實際上這是一個非常具有誤導性質(zhì)的說法，而且在 CAP 理論誕生 12 年之后，CAP 之父也在 2012 年重寫了之前的論文。

當發(fā)生網(wǎng)絡分區(qū)的時候，如果我們要繼續(xù)服務，那么強一致性和可用性只能 2 選 1。也就是說當網(wǎng)絡分區(qū)之后 P 是前提，決定了 P 之后才有 C 和 A 的選擇。也就是說分區(qū)容錯性（Partition tolerance）我們是必須要實現(xiàn)的。

簡而言之就是：CAP 理論中分區(qū)容錯性 P 是一定要滿足的，在此基礎上，只能滿足可用性 A 或者一致性 C。

因此，分布式系統(tǒng)理論上不可能選擇 CA 架構(gòu)，只能選擇 CP 或者 AP 架構(gòu)。?比如 ZooKeeper、HBase 就是 CP 架構(gòu)，Cassandra、Eureka 就是 AP 架構(gòu)，Nacos 不僅支持 CP 架構(gòu)也支持 AP 架構(gòu)。

為啥不可能選擇 CA 架構(gòu)呢？?舉個例子：若系統(tǒng)出現(xiàn)“分區(qū)”，系統(tǒng)中的某個節(jié)點在進行寫操作。為了保證 C， 必須要禁止其他節(jié)點的讀寫操作，這就和 A 發(fā)生沖突了。如果為了保證 A，其他節(jié)點的讀寫操作正常的話，那就和 C 發(fā)生沖突了。

選擇 CP 還是 AP 的關(guān)鍵在于當前的業(yè)務場景，沒有定論，比如對于需要確保強一致性的場景如銀行一般會選擇保證 CP 。

另外，需要補充說明的一點是：?如果網(wǎng)絡分區(qū)正常的話（系統(tǒng)在絕大部分時候所處的狀態(tài)），也就說不需要保證 P 的時候，C 和 A 能夠同時保證。

CAP 實際應用案例

我這里以注冊中心來探討一下 CAP 的實際應用。考慮到很多小伙伴不知道注冊中心是干嘛的，這里簡單以 Dubbo 為例說一說。

下圖是 Dubbo 的架構(gòu)圖。注冊中心 Registry 在其中扮演了什么角色呢？提供了什么服務呢？

注冊中心負責服務地址的注冊與查找，相當于目錄服務，服務提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉(zhuǎn)發(fā)請求，壓力較小。

常見的可以作為注冊中心的組件有：ZooKeeper、Eureka、Nacos...。

ZooKeeper 保證的是 CP。?任何時刻對 ZooKeeper 的讀請求都能得到一致性的結(jié)果，但是， ZooKeeper 不保證每次請求的可用性比如在 Leader 選舉過程中或者半數(shù)以上的機器不可用的時候服務就是不可用的。

Eureka 保證的則是 AP。?Eureka 在設計的時候就是優(yōu)先保證 A （可用性）。在 Eureka 中不存在什么 Leader 節(jié)點，每個節(jié)點都是一樣的、平等的。因此 Eureka 不會像 ZooKeeper 那樣出現(xiàn)選舉過程中或者半數(shù)以上的機器不可用的時候服務就是不可用的情況。 Eureka 保證即使大部分節(jié)點掛掉也不會影響正常提供服務，只要有一個節(jié)點是可用的就行了。只不過這個節(jié)點上的數(shù)據(jù)可能并不是最新的。

Nacos 不僅支持 CP 也支持 AP。

總結(jié)

在進行分布式系統(tǒng)設計和開發(fā)時，我們不應該僅僅局限在 CAP 問題上，還要關(guān)注系統(tǒng)的擴展性、可用性等等

在系統(tǒng)發(fā)生“分區(qū)”的情況下，CAP 理論只能滿足 CP 或者 AP。要注意的是，這里的前提是系統(tǒng)發(fā)生了“分區(qū)”

如果系統(tǒng)沒有發(fā)生“分區(qū)”的話，節(jié)點間的網(wǎng)絡連接通信正常的話，也就不存在 P 了。這個時候，我們就可以同時保證 C 和 A 了。

總結(jié)：如果系統(tǒng)發(fā)生“分區(qū)”，我們要考慮選擇 CP 還是 AP。如果系統(tǒng)沒有發(fā)生“分區(qū)”的話，我們要思考如何保證 CA 。

相關(guān)閱讀：

神一樣的CAP理論被應用在何方 - 掘金

二.BASE 理論

BASE 理論open in new window起源于 2008 年， 由eBay的架構(gòu)師Dan Pritchett在ACM上發(fā)表。

簡介

BASE?是?Basically Available（基本可用）?、Soft-state（軟狀態(tài)）?和?Eventually Consistent（最終一致性）?三個短語的縮寫。BASE 理論是對 CAP 中一致性 C 和可用性 A 權(quán)衡的結(jié)果，其來源于對大規(guī)模互聯(lián)網(wǎng)系統(tǒng)分布式實踐的總結(jié)，是基于 CAP 定理逐步演化而來的，它大大降低了我們對系統(tǒng)的要求。

BASE 理論的核心思想

即使無法做到強一致性，但每個應用都可以根據(jù)自身業(yè)務特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。

也就是犧牲數(shù)據(jù)的一致性來滿足系統(tǒng)的高可用性，系統(tǒng)中一部分數(shù)據(jù)不可用或者不一致時，仍需要保持系統(tǒng)整體“主要可用”。

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

為什么這樣說呢？

CAP 理論這節(jié)我們也說過了：

如果系統(tǒng)沒有發(fā)生“分區(qū)”的話，節(jié)點間的網(wǎng)絡連接通信正常的話，也就不存在 P 了。這個時候，我們就可以同時保證 C 和 A 了。因此，如果系統(tǒng)發(fā)生“分區(qū)”，我們要考慮選擇 CP 還是 AP。如果系統(tǒng)沒有發(fā)生“分區(qū)”的話，我們要思考如何保證 CA 。

因此，AP 方案只是在系統(tǒng)發(fā)生分區(qū)的時候放棄一致性，而不是永遠放棄一致性。在分區(qū)故障恢復后，系統(tǒng)應該達到最終一致性。這一點其實就是 BASE 理論延伸的地方。

BASE 理論三要素

1. 基本可用

基本可用是指分布式系統(tǒng)在出現(xiàn)不可預知故障的時候，允許損失部分可用性。但是，這絕不等價于系統(tǒng)不可用。

什么叫允許損失部分可用性呢？

• 響應時間上的損失: 正常情況下，處理用戶請求需要 0.5s 返回結(jié)果，但是由于系統(tǒng)出現(xiàn)故障，處理用戶請求的時間變?yōu)?3 s。
• 系統(tǒng)功能上的損失：正常情況下，用戶可以使用系統(tǒng)的全部功能，但是由于系統(tǒng)訪問量突然劇增，系統(tǒng)的部分非核心功能無法使用。

2. 軟狀態(tài)

軟狀態(tài)指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)（CAP 理論中的數(shù)據(jù)不一致），并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點的數(shù)據(jù)副本之間進行數(shù)據(jù)同步的過程存在延時。

3. 最終一致性

最終一致性強調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步后，最終能夠達到一個一致的狀態(tài)。因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性。

分布式一致性的 3 種級別：

強一致性?：系統(tǒng)寫入了什么，讀出來的就是什么。

弱一致性?：不一定可以讀取到最新寫入的值，也不保證多少時間之后讀取到的數(shù)據(jù)是最新的，只是會盡量保證某個時刻達到數(shù)據(jù)一致的狀態(tài)。

最終一致性?：弱一致性的升級版，系統(tǒng)會保證在一定時間內(nèi)達到數(shù)據(jù)一致的狀態(tài)。

業(yè)界比較推崇是最終一致性級別，但是某些對數(shù)據(jù)一致要求十分嚴格的場景比如銀行轉(zhuǎn)賬還是要保證強一致性。

那實現(xiàn)最終一致性的具體方式是什么呢??《分布式協(xié)議與算法實戰(zhàn)》open in new window?中是這樣介紹：

• 讀時修復?: 在讀取數(shù)據(jù)時，檢測數(shù)據(jù)的不一致，進行修復。比如 Cassandra 的 Read Repair 實現(xiàn)，具體來說，在向 Cassandra 系統(tǒng)查詢數(shù)據(jù)的時候，如果檢測到不同節(jié)點 的副本數(shù)據(jù)不一致，系統(tǒng)就自動修復數(shù)據(jù)。
• 寫時修復?: 在寫入數(shù)據(jù)，檢測數(shù)據(jù)的不一致時，進行修復。比如 Cassandra 的 Hinted Handoff 實現(xiàn)。具體來說，Cassandra 集群的節(jié)點之間遠程寫數(shù)據(jù)的時候，如果寫失敗 就將數(shù)據(jù)緩存下來，然后定時重傳，修復數(shù)據(jù)的不一致性。
• 異步修復?: 這個是最常用的方式，通過定時對賬檢測副本數(shù)據(jù)的一致性，并修復。

比較推薦?寫時修復，這種方式對性能消耗比較低。

參考文章：https://javaguide.cn/distributed-system/theorem&algorithm&protocol/cap&base-theorem.html#cap%E7%90%86%E8%AE%BA

總結(jié)

以上是生活随笔為你收集整理的分布式系统中的CAP理论和BASE理论详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。