分散式必備理論基礎：CAP和BASE

• 2021 年 9 月 16 日
• 筆記
• 其它, 分散式

大家好，我是老三，今天是沒有刷題的一天，心情愉悅，給大家分享兩個簡單的知識點：分散式理論中的CAP和BASE。

CAP理論

什麼是CAP

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

• 一致性 ：數據在多個副本之間能夠保持一致的特性。
• 可用性：系統提供的服務一直處於可用的狀態，每次請求都能獲得正確的響應。
• 分區容錯性：分散式系統在遇到任何網路分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。

什麼是分區？

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

為什麼三者不可得兼

首先，我們得知道，分散式系統，是避免不了分區的，分區容錯性是一定要滿足的，我們看看在滿足分區容錯的基礎上，能不能同時滿足一致性和可用性？

假如現在有兩個分區N1和N2，N1和N2分別有不同的分區存儲D1和D2，以及不同的服務S1和S2。

• 在滿足一致性 的時候，N1和N2的數據要求值一樣的，D1=D2。
• 在滿足可用性的時候，無論訪問N1還是N2，都能獲取及時的響應。

好的，現在有這樣的場景：

• 用戶訪問了N1，修改了D1的數據。
• 用戶再次訪問，請求落在了N2。此時D1和D2的數據不一致。

接下來：

• 保證一致性：此時D1和D2數據不一致，要保證一致性就不能返回不一致的數據，可用性無法保證。
• 保證可用性：立即響應，可用性得到了保證，但是此時響應的數據和D1不一致，一致性無法保證。

所以，可以看出，分區容錯的前提下，一致性和可用性是矛盾的。

CAP原則權衡

CAP三者不可同得，那麼必須得做一些權衡。

CA without P❌

如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但是對於分散式系統，分區是客觀存在的，其實分散式系統理論上是不可選CA的。

CP without A

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

AP wihtout C

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

CAP原則實際應用

我們應該都接觸過微服務，常見的可以作為註冊中心的組件有：ZooKeeper、Eureka、Nacos…。

1. ZooKeeper 保證的是 CP。 任何時刻對 ZooKeeper 的讀請求都能得到一致性的結果，但是， ZooKeeper 不保證每次請求的可用性比如在 Leader 選舉過程中或者半數以上的機器不可用的時候服務就是不可用的。
2. Eureka 保證的則是 AP。 Eureka 在設計的時候就是優先保證 A （可用性）。在 Eureka 中不存在什麼 Leader 節點，每個節點都是一樣的、平等的。因此 Eureka 不會像 ZooKeeper 那樣出現選舉過程中或者半數以上的機器不可用的時候服務就是不可用的情況。 Eureka 保證即使大部分節點掛掉也不會影響正常提供服務，只要有一個節點是可用的就行了。只不過這個節點上的數據可能並不是最新的。
3. Nacos 不僅支援 CP 也支援 AP。

BASE理論

什麼是BASE理論

BASE 是 Basically Available（基本可用） 、Soft-state（軟狀態） 和 Eventually Consistent（最終一致性） 三個短語的縮寫。

BASE 理論是對 CAP 中一致性 C 和可用性 A 權衡的結果，其來源於對大規模互聯網系統分散式實踐的總結，是基於 CAP 定理逐步演化而來的，它大大降低了我們對系統的要求。

BASE理論的核心思想是：

即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。

BASE理論的三個特性

基本可用

什麼是基本可用呢？

假如系統出現了不可預知故障，允許損失部分可用性，當然也不能完全不可用。

損失的這部分可用性指的是什麼？

• 響應時間上的損失：正常情況下的搜索引擎0.5秒即返回給用戶結果，而基本可用的搜索引擎可以在2秒作用返回結果。

• 功能上的損失：在一個電商網站上，正常情況下，用戶可以順利完成每一筆訂單。但是到了大促期間，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。

軟狀態

軟狀態指允許系統中的數據存在中間狀態（CAP 理論中的數據不一致），並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。

最終一致性

最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。

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

1. 強一致性 ：系統寫入了什麼，讀出來的就是什麼。
2. 弱一致性 ：不一定可以讀取到最新寫入的值，也不保證多少時間之後讀取到的數據是最新的，只是會盡量保證某個時刻達到數據一致的狀態。
3. 最終一致性 ：弱一致性的升級版，系統會保證在一定時間內達到數據一致的狀態。

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

最終一致性怎麼保證呢？

• 讀時修復 : 在讀取數據時，檢測數據的不一致，進行修復。比如 Cassandra 的 Read Repair 實現，具體來說，在向 Cassandra 系統查詢數據的時候，如果檢測到不同節點 的副本數據不一致，系統就自動修複數據。
• 寫時修復 : 在寫入數據，檢測數據的不一致時，進行修復。比如 Cassandra 的 Hinted Handoff 實現。具體來說，Cassandra 集群的節點之間遠程寫數據的時候，如果寫失敗 就將數據快取下來，然後定時重傳，修複數據的不一致性。
• 非同步修復 : 這個是最常用的方式，通過定時對賬檢測副本數據的一致性，並修復。

總結

CAP 是分散式系統設計理論，BASE 是 CAP 理論中 AP 方案的延伸，ACID 是資料庫事務完整性的理論。

CAP理論嚴格來講不是三選二，而是CP、AP二選一，因為通常P（分區容錯性）是必須得到保證的。

BASE理論面向的是大型高可用、可擴展的分散式系統。與傳統ACID特性相反，不是強一致性模型，BASE提出通過犧牲強一致性來獲得可用性，並允許數據一段時間內的不一致，但是最終需要達到一致狀態。

簡單的事情重複做，重複的事情認真做，認真的事情有創造性地做。

我是三分惡，一個努力學習中的程式設計師。

點贊、關注不迷路，咱們下期見！

參考：

[1]. 分散式理論(一) – CAP定理

[2]. CAP理論

[3]. 分散式理論(二) – BASE理論

[4]. BASE理論