分布式|CAP&BASE

CAP&BASE

• 前言
• CAP
• • 一緻性
  • • 場景
    • 分類
  • 可用性
  • 分區容錯性
• BASE
• • 基本可用
  • 軟狀态
  • 最終一緻性
• 總結
• • CA
  • CP
  • AP

前言

CAP和BASE算是耳熟能詳的名字了吧，本篇文章中，想結合自己已有的億點點實踐經曆，談談自身的了解。

CAP

CAP的英文名和中文名如下：

1. Consistency：一緻性
2. Availability：可用性
3. Partition Tolerance：分區容錯性（分區容忍性）

   

一緻性

場景

個人覺得在不同的場景下，關于一緻性的了解是各種各樣的。在資料操作方面的一緻性，可以了解為資料的變化情況和單線程的場景下的變化情況應該保持一緻。如：網上電影售票時，不能出現一張票賣給了多個人，即出現漏減的情況。

在事務方面的一緻性（即ACID中的C）可以了解為“目标”上的一緻性，譬如，一次A轉賬給B100元的過程，目标是A的賬戶扣100，B的賬戶增100，這個“目标”要麼達成，要麼不達成，不能隻完成一半。（為了防止扁桃體同學擡杠，這裡強調不是在事務過程中）是不是覺得很像原子性，當然了，原子性隻是保證事務一緻性的手段之一。

在資料存儲方面（這裡指資料分布在伺服器叢集中），一緻性可以指資料在多台伺服器上分布協調，如一緻性雜湊演算法就可以解決這個問題，也可以多個指同步資料的副本的資料一緻，例如我們的elasticsearch，在用戶端發起資料更新請求後，可以讓所有副本分片同步更新後才讓協調節點傳回成功。

分類

盡管不同場景下的一緻性了解稍微有些不同，但它卻有着與之對應的模型。這裡隻說了比較爛大街的強一緻性、弱一緻性、最終一緻性。

對了，這裡還要再扯一下，一緻性實作的算法很多，像很多人張口就來什麼Paxos、Raft什麼的。其實，這些個算法從英文翻譯過來時，叫做共識算法比較好了解一些。這些個算法，大都假設存在拜占庭問題，在此背景下，讓分布式下的多個節點的投票可以達成共識。

而我們這裡通常所說的一緻性，大都指這麼個情況，為了保證容錯性，我們通常會用多個副本來同步主節點的資料，如何讓資料在副本和主節點上保持一緻性的問題。

1. 強一緻性（線性一緻性）

   CAP中的C就是強一緻性，按百科的描述就是，在同一時刻是否同樣的值。（等同于所有節點通路同一份最新的資料副本）。在實際運用中，關于強一緻性的實作一般都很難真正的實作。這也不難解釋，有些中間件會在主節點選舉時，容易造成腦裂問題。而強一緻性的情況下，是不應該出現這個問題的。

2. 弱一緻性

   分布式下，弱一緻性指産生資料後，不需要所有節點就立刻都看到，但不同不同的節點看到這些新資料時需要按照它們處理時的順序。譬如A、B、C三個節點，A上産生新資料，依次同步到B、C，不能說同步給B時，還沒到C，C就能看到了。

3. 最終一緻性

   這個下面分析base時說。

可用性

可用性指在叢集中一部分節點故障後，叢集整體是否還能響應用戶端的讀寫請求能力。（對資料更新具備高可用性）。

可用性，範圍說小一點，譬如隻單節點可用性，我們可以考慮是否可以啟動多個服務，挂載不同的磁盤，進行僞負載均衡，防止某個盤挂了，服務就不可用了。當通路的數量量上來後，這是我們就需要考慮叢集的方案了。這時，使用者的通路量由多台叢集進行負載，考慮到通路量還是可能超過叢集限制，我們又得增加一些限流或者熔斷措施。考慮到某個服務挂了之後，程式需要自動切換到另一台服務，此時就引入服務注冊與發現中心。

分區容錯性

分區容錯性可以了解為當存在網絡分區時（另個子系統之間的網絡不可達），系統仍可繼續運作的能力。在分區恢複後，保證分區容限的分布式系統還可以從分區正常恢複。

看了一些文章，目前分區容錯性也可以了解為系統對節點動态加入和離開的處理能力，因為節點的加入和離開可以認為是叢集内部的網絡分區。

BASE

BASE比CAP放寬了條件，放棄了CAP理論的C（強一緻性），強調最終一緻性。基本可用來表明可用性。

BASE：全稱：

1. Basically Available(基本可用)
2. Soft state（軟狀态）
3. Eventually consistent（最終一緻性）

基本可用

基本可用是指分布式系統在出現不可預知的故障的時候，允許系損失部分可用性。最常見的，雙11淘寶在遇到大流量的購買操作後，此時，使用者繼續購買時，會跳轉到一個引導頁。進而保證其他服務的正常運作。

軟狀态

軟狀态表示即使沒有輸入，系統的狀态也可能随時間變化。這個軟狀态又指中間狀态，資料同步過程可以存在一定的延遲。譬如我們Kafka中的ISR伸縮，它表示follower副本同步leader節點需要的延時差，這個是允許存在的。

最終一緻性

最終一緻性強調的是系統中所有的資料副本，在經過一段時間的同步後（軟狀态），最終能夠達到一個一緻的狀态。

總結

個人認為，BASE是CAP的一個拓展，結合實際運用場景，放寬了條件。其中，CAP的C指待的是強一緻性，而BASE的E指的是最終一緻性。CAP的A隻的是可用性，而BASE的B強調的是基本可用。

另外，CAP的精髓在于一個分布式系統不可能同時滿足這三點，一緻性、可用性、分區容錯性。如果強調CA（一緻性和可用區），需要犧牲P（分區容錯性）

CA

基于CA的設計不能滿足P，由于C追求強一緻性，一般就沒有了多個資料副本了，隻有一個的資料副本滿足了強一緻的需求，最常見于單節點系統，此時遇到不可預知的錯誤，伺服器它完犢子了，哦吼，系統不能通路了，不具備分區容錯性。

CP

基于CP的設計（zookeeper，話說zookeeper的一緻性應該是弱一緻性，不能歸類為CAP中的C才對，非要歸類，也應該是Eventually consistent），犧牲了A（可用性）。在分區出現故障後，不斷通過重試來恢複，這個期間的可用性無法滿足。

AP

基于AP的設計（Eureka），犧牲了C（一緻性）。分區（P）越來越多，可以了解為備胎越來越多，為了不給他們湊在一起打麻将的機會，我們需要犧牲掉C（一緻性），即資訊在多個分區間的同步具有延時性的特點。