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

阿新 • • 發佈：2021-09-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...。

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

強一致性 ：系統寫入了什麼，讀出來的就是什麼。

弱一致性 ：不一定可以讀取到最新寫入的值，也不保證多少時間之後讀取到的資料是最新的，只是會儘量保證某個時刻達到資料一致的狀態。

最終一致性 ：弱一致性的升級版，系統會保證在一定時間內達到資料一致的狀態。

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

最終一致性怎麼保證呢？

讀時修復 : 在讀取資料時，檢測資料的不一致，進行修復。比如 Cassandra 的 Read Repair 實現，具體來說，在向 Cassandra 系統查詢資料的時候，如果檢測到不同節點的副本資料不一致，系統就自動修復資料。

寫時修復 : 在寫入資料，檢測資料的不一致時，進行修復。比如 Cassandra 的 Hinted Handoff 實現。具體來說，Cassandra 叢集的節點之間遠端寫資料的時候，如果寫失敗就將資料快取下來，然後定時重傳，修復資料的不一致性。

非同步修復 : 這個是最常用的方式，通過定時對賬檢測副本資料的一致性，並修復。