[[346602]]

引言

在理論計算機科學中，CAP定理(CAP theorem)，又被稱作布魯爾定理(Brewer's theorem)，它指出對于一個分布式計算系統(tǒng)來說，不可能同時滿足以下三點：

• 一致性(Consistency) (等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本)
• 可用性(Availability)(每次請求都能獲取到非錯的響應(yīng)——但是不保證獲取的數(shù)據(jù)為最新數(shù)據(jù))
• 分區(qū)容錯性(Partition tolerance)(以實際效果而言，分區(qū)相當于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當前操作在C和A之間做出選擇)

根據(jù)定理，分布式系統(tǒng)只能滿足三項中的兩項而不可能滿足全部三項。理解CAP理論的最簡單方式是想象兩個節(jié)點分處分區(qū)兩側(cè)。允許至少一個節(jié)點更新狀態(tài)會導致數(shù)據(jù)不一致，即喪失了C性質(zhì)。如果為了保證數(shù)據(jù)一致性，將分區(qū)一側(cè)的節(jié)點設(shè)置為不可用，那么又喪失了A性質(zhì)。除非兩個節(jié)點可以互相通信，才能既保證C又保證A，這又會導致喪失P性質(zhì)。

這個定義讀下來是不是讓人看的一臉懵逼，多讀幾遍是不是又會覺得有那么點明白了。CAP 理論聽起來十分抽象，本文嘗試以生活中的例子并用通俗易懂的語言來解釋 CAP 理論的含義。

CAP小故事

這個故事感覺講的還是挺有意思的，大家點擊鏈接https://zhuanlan.zhihu.com/p/265670196進去看看或者點擊閱讀原文進行閱讀。相信看了這個小故事之后，再來看看前面的定義可能會覺得 更好理解了。

Cap的權(quán)衡

通過CAP理論我們可以無法同時滿足一致性、可用性和分區(qū)容錯性這三個特性，那么我們需要怎么權(quán)衡呢?

選擇CA放棄 P

這種情況的話在分布式系統(tǒng)中基本是不可能存在的。因為在分布式環(huán)境下分區(qū)是必然的，如果我們要舍棄P就意味著我們要舍棄分布式系統(tǒng)，所以也就沒必要再來討論CAP理論了，

選擇CP放棄A

一個分布式系統(tǒng)如果不能做到可用性，經(jīng)常宕機或者停止提供服務(wù)的話，這樣的話用戶體驗是非常差的，就像曾經(jīng)的“微盟刪庫事件”，只有等到所有的數(shù)據(jù)都被找回來才會繼續(xù)對外提供服務(wù)，這期間停機多久，給商家造成了的多大的損失。我們常見的CP分布式系統(tǒng)有分布式數(shù)據(jù)庫(redis)等，以及Zookeeper等都是優(yōu)先保證數(shù)據(jù)的強一致性，來舍棄系統(tǒng)的可用性。

放棄AP放棄C

如果要保證高可用并允許分區(qū)，則需要放棄一致性。一旦網(wǎng)絡(luò)問題發(fā)生，節(jié)點之間可能會失去聯(lián)系。為了保證高可用，需要在用戶訪問時可以馬上得到返回，則每個節(jié)點只能用本地數(shù)據(jù)提供服務(wù)，而這樣會導致全局數(shù)據(jù)的不一致性?，F(xiàn)如今應(yīng)該大多數(shù)場景都是會選擇可用性，而去犧牲一致性(保持最終一致性)，就像我們春節(jié)搶紅包的時候，它不會立馬告訴你搶了多少金額，只是提示你過多久再去查看。以及我們春節(jié)搶票的時候，明明看到這輛高鐵還是郵票的但是等你填完驗證碼，以及乘客信息真正提交訂單的時候就告訴你沒票了，你再返回列表頁查看該車次的時候，也還繼續(xù)顯示著有票 。這些雖然用戶體驗有那么一丟丟的不友好，但是也能接受。

小結(jié)

CAP的選擇的話沒有哪種更好，只有根據(jù)自己的業(yè)務(wù)場景來選擇，選擇適合自己的才是最好的。

Base理論

BASE：全稱：Basically Available(基本可用)，Soft state(軟狀態(tài)),和 Eventually consistent(最終一致性)三個短語的縮寫，來自 ebay 的架構(gòu)師提出。Base 理論是對 CAP 中一致性和可用性權(quán)衡的結(jié)果，其來源于對大型互聯(lián)網(wǎng)分布式實踐的總結(jié)，是基于 CAP 定理逐步演化而來的。其核心思想是：

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

Basically Available(基本可用)

什么是基本可用?犧牲性能(服務(wù)響應(yīng)時間)、體驗(部分功能體驗)以保證基本可用。犧牲性能：比如我們查詢商品正常情況響應(yīng)時間都是1s左右返回結(jié)果，但是基本可用的話返回結(jié)果都是10s返回結(jié)果。犧牲體驗：比如雙十一的時候，淘寶只會保證核心功能可用(下單、支付等)，其他非核心(退貨、修改地址等)的功能都會進行降級，關(guān)于降級可以看下以前這個文章《高并發(fā)系統(tǒng)三大利器之降級》

Soft State(軟狀態(tài))

允許不影響整體可用性的中間狀態(tài) 即允許系統(tǒng)在多個不同節(jié)點的數(shù)據(jù)副本存在數(shù)據(jù)延時。

Eventual Consistency(最終一致性)

上面說軟狀態(tài)，然后不可能一直是軟狀態(tài)，必須有個時間期限。在期限過后，應(yīng)當保證所有副本保持數(shù)據(jù)一致性。從而達到數(shù)據(jù)的最終一致性。這個時間期限取決于網(wǎng)絡(luò)延時，系統(tǒng)負載，數(shù)據(jù)復制方案設(shè)計等等因素。

系統(tǒng)能夠保證在沒有其他新的更新操作的情況下，數(shù)據(jù)最終一定能夠達到一致的狀態(tài)，因此所有客戶端對系統(tǒng)的數(shù)據(jù)訪問最終都能夠獲取到最新的值。

結(jié)束

由于自己才疏學淺，難免會有紕漏，假如你發(fā)現(xiàn)了錯誤的地方，還望留言給我指出來,我會對其加以修正。

本文轉(zhuǎn)載自微信公眾號「 java金融」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系java金融公眾號。