一、分布式理論

1.CAP理論

CAP理論是說對于分布式數(shù)據(jù)存儲，最多只能同時滿足一致性（C，Consistency）、可用性（A， Availability）、分區(qū)容忍性（P，Partition Tolerance）中的兩者。

CAP 理論又叫 Brewer 理論，這是加州大學(xué)伯克利分校的埃里克 · 布魯爾（Eric Brewer）教授，在 2000 年 7 月“ACM 分布式計算原理研討會（PODC）”上提出的一個猜想。

然后到了 2002 年，麻省理工學(xué)院的賽斯 · 吉爾伯特（Seth Gilbert）和南希 · 林奇（Nancy Lynch）就以嚴謹?shù)臄?shù)學(xué)推理證明了這個 CAP 猜想。在這之后，CAP 理論就正式成為了分布式計算領(lǐng)域公認的著名定理。

1.一致性

是指對于每一次讀操作，都能夠讀到最新寫入的數(shù)據(jù)，且每個節(jié)點讀取到的數(shù)據(jù)是一致的。

對于客戶端來說，一致性指的是并發(fā)訪問更新過的數(shù)據(jù)如何獲取的問題。

從服務(wù)端來看，則是更新如何復(fù)制分布到整個節(jié)點，以保證數(shù)據(jù)最終一致。

從多個應(yīng)用系統(tǒng)來看，是保證各個業(yè)務(wù)系統(tǒng)冗余的數(shù)據(jù)和主數(shù)據(jù)系統(tǒng)的數(shù)據(jù)一致性。

1.一致性級別

1、強一致性

這種一致性級別是最符合用戶直覺的，它要求系統(tǒng)寫入什么，讀出來的也會是什么，用戶體驗好，但實現(xiàn)起來往往對系統(tǒng)的性能影響大

2、弱一致性

這種一致性級別約束了系統(tǒng)在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數(shù)據(jù)能夠達到一致，但會盡可能地保證到某個時間級別（比如秒級別）后，數(shù)據(jù)能夠達到一致狀態(tài)

3、最終一致性

最終一致性是弱一致性的一個特例，系統(tǒng)會保證在一定時間內(nèi)，能夠達到一個數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨提出來，是因為它是弱一致性中非常推崇的一種一致性模型，也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型。

在實踐中，多個系統(tǒng)要實現(xiàn)最終一致性的兜底解決辦法多數(shù)是通過數(shù)據(jù)比對來實現(xiàn)的，如多個業(yè)務(wù)系統(tǒng)通過比對將生產(chǎn)者數(shù)據(jù)備份的大數(shù)據(jù)平臺進行比對，從而實現(xiàn)各個業(yè)務(wù)系統(tǒng)的最終一致性。

2.可用性

可用性：是指對于每一次請求，都能夠得到一個及時的、非錯的響應(yīng)。
系統(tǒng)能夠很好的為用戶服務(wù)，不出現(xiàn)用戶訪問服務(wù)時服務(wù)器不可用，或者訪問超時等用戶體驗不好的情況。

3.分區(qū)容忍性

The system will continue to function when network partitions occur.

即分布式系統(tǒng)在遇到某節(jié)點或網(wǎng)絡(luò)分區(qū)故障的時候，仍然能夠?qū)ν馓峁M足一致性和可用性的服務(wù)。

分區(qū)容錯性要求能夠使應(yīng)用雖然是一個分布式系統(tǒng)，而看上去卻好像是在一個可以運轉(zhuǎn)正常的整體。

它跟趨向于單機模式的對比，如一臺機器宕機了，其他機器一樣能夠提供同等的服務(wù)。但機器部署得越多，一致性和可用性就越難保證。

比如現(xiàn)在的分布式系統(tǒng)中有某一個或者幾個機器宕掉了，其他剩下的機器還能夠正常運轉(zhuǎn)滿足系統(tǒng)需求，對于用戶而言并沒有什么體驗上的影響。

2. CAP的選型

當然，單純只看這個概念的話，CAP 是比較抽象的，我還是事例場景來說明一下，這三種特性對分布式系統(tǒng)來說都意味著什么。

事例場景：Fenix's Bookstore 是一個在線書店。一份商品成功售出，需要確保以下三件事情被正確地處理：

1.用戶的賬號扣減相應(yīng)的商品款項；

2.商品倉庫中扣減庫存，將商品標識為待配送狀態(tài)；

3.商家的賬號增加相應(yīng)的商品款項。

假設(shè)，Fenix's Bookstore 的服務(wù)拓撲如下圖所示，一個來自最終用戶的交易請求，將交由賬號、商家和倉庫服務(wù)集群中的某一個節(jié)點來完成響應(yīng)：

你可以看到，在這套系統(tǒng)中，每一個單獨的服務(wù)節(jié)點都有著自己的數(shù)據(jù)庫。

假設(shè)某次交易請求分別由“賬號節(jié)點 1”“商家節(jié)點 2”“倉庫節(jié)點 N”來進行響應(yīng)，當用戶購買一件價值 100 元的商品后，賬號節(jié)點 1 首先應(yīng)該給用戶賬號扣減 100 元貨款。賬號節(jié)點 1 在自己的數(shù)據(jù)庫扣減 100 元是很容易的，但它還要把這次交易變動告知賬號節(jié)點 2 到 N，以及確保能正確變更商家和倉庫集群其他賬號節(jié)點中的關(guān)聯(lián)數(shù)據(jù)。

那么此時，我們可能會面臨以下幾種情況：?

1.如果該變動信息沒有及時同步給其他賬號節(jié)點，那么當用戶購買其他商品時，會被分配給另一個節(jié)點處理，因為沒有及時同步，此時系統(tǒng)會看到用戶賬戶上有不正確的余額，從而錯誤地發(fā)生了原本無法進行的交易。此為一致性問題。

2.如果因為要把該變動信息同步給其他賬號節(jié)點，就必須暫停對該用戶的交易服務(wù)，直到數(shù)據(jù)同步一致后再重新恢復(fù)，那么當用戶在下一次購買商品時，可能會因為系統(tǒng)暫時無法提供服務(wù)而被拒絕交易。此為可用性問題。

3.如果由于賬號服務(wù)集群中某一部分節(jié)點，因出現(xiàn)網(wǎng)絡(luò)問題，無法正常與另一部分節(jié)點交換賬號變動信息，那么此時的服務(wù)集群中，無論哪一部分節(jié)點對外提供的服務(wù)，都可能是不正確的，我們需要考慮能否接受由于部分節(jié)點之間的連接中斷，而影響整個集群的正確性的情況。此為分區(qū)容忍性問題。

以上還只是涉及到了賬號服務(wù)集群自身的 CAP 問題，而對于整個 Bookstore 站點來說，它更是面臨著來自于賬號、商家和倉庫服務(wù)集群帶來的 CAP 問題。

比如，用戶賬號扣款后，由于沒有及時通知倉庫服務(wù)，導(dǎo)致另一次交易中看到倉庫中有不正確的庫存數(shù)據(jù)而發(fā)生了超售。再比如，因為倉庫中某個商品的交易正在進行當中，為了同步用戶、商家和倉庫此時的交易變動，而暫時鎖定了該商品的交易服務(wù)，導(dǎo)致了可用性問題，等等。

不過既然 CAP 理論已經(jīng)有了數(shù)學(xué)證明，也成為了業(yè)界公認的計算定理，我們就不去討論為何 CAP 特性會存在不可兼得的問題了，直接來分析下在實際的應(yīng)用場景中，我們要如何權(quán)衡取舍 CAP，然后看看這些不同取舍都會帶來哪些問題。

如果放棄分區(qū)容錯性（CA without P）

這意味著，我們將假設(shè)節(jié)點之間的通訊永遠是可靠的。可是永遠可靠的通訊在分布式系統(tǒng)中必定是不成立的，這不是你想不想的問題，而是網(wǎng)絡(luò)分區(qū)現(xiàn)象始終會存在。在現(xiàn)實場景中，主流的 RDBMS（關(guān)系數(shù)據(jù)庫管理系統(tǒng)）集群通常就是采用放棄分區(qū)容錯性的工作模式。以 Oracle 的 RAC 集群為例，它的每一個節(jié)點都有自己的 SGA（系統(tǒng)全局區(qū)）、重做日志、回滾日志等，但各個節(jié)點是共享磁盤中的同一份數(shù)據(jù)文件和控制文件的，也就是說，RAC 集群是通過共享磁盤的方式來避免網(wǎng)絡(luò)分區(qū)的出現(xiàn)。

如果放棄可用性（CP without A）

這意味著，我們將假設(shè)一旦發(fā)生分區(qū)，節(jié)點之間的信息同步時間可以無限制地延長，那么這個問題就相當于退化到了上一講所討論的全局事務(wù)的場景之中，即一個系統(tǒng)可以使用多個數(shù)據(jù)源。我們可以通過 2PC/3PC 等手段，同時獲得分區(qū)容錯性和一致性。在現(xiàn)實中，除了 DTP 模型的分布式數(shù)據(jù)庫事務(wù)外，著名的 HBase 也是屬于 CP 系統(tǒng)。以它的集群為例，假如某個 RegionServer 宕機了，這個 RegionServer 持有的所有鍵值范圍都將離線，直到數(shù)據(jù)恢復(fù)過程完成為止，這個時間通常會是很長的。

如果放棄一致性（AP without C）

這意味著，我們將假設(shè)一旦發(fā)生分區(qū)，節(jié)點之間所提供的數(shù)據(jù)可能不一致。AP 系統(tǒng)目前是分布式系統(tǒng)設(shè)計的主流選擇，大多數(shù)的 NoSQL 庫和支持分布式的緩存都是 AP 系統(tǒng)。因為 P 是分布式網(wǎng)絡(luò)的天然屬性，你不想要也無法丟棄；而 A 通常是建設(shè)分布式的目的，如果可用性隨著節(jié)點數(shù)量增加反而降低的話，很多分布式系統(tǒng)可能就沒有存在的價值了（除非銀行這些涉及到金錢交易的服務(wù)，寧可中斷也不能出錯）。以 Redis 集群為例，如果某個 Redis 節(jié)點出現(xiàn)網(wǎng)絡(luò)分區(qū)，那也不妨礙每個節(jié)點仍然會以自己本地的數(shù)據(jù)對外提供服務(wù)。但這時有可能出現(xiàn)這種情況，即請求分配到不同節(jié)點時，返回給客戶端的是不同的數(shù)據(jù)。

1.cap無法同時滿足原因

CP和AP：分區(qū)容錯是必須保證的，當發(fā)生網(wǎng)絡(luò)分區(qū)的時候，如果要繼續(xù)服務(wù)，那么強一致性和可用性只能 2 選 1

C A 滿足的情況下，P不能滿足的原因：
數(shù)據(jù)同步?需要時間，也要正常的時間內(nèi)響應(yīng)(A)，那么機器數(shù)量就要少，所以P就不滿足。
若p不能滿足，就已經(jīng)趨向于單機了。

CP 滿足的情況下，A不能滿足的原因：
數(shù)據(jù)同步?需要時間, 機器數(shù)量也多§，但是同步數(shù)據(jù)需要時間，所以不能再正常時間內(nèi)響應(yīng)，所以A就不滿足

AP 滿足的情況下，C不能滿足的原因：
機器數(shù)量也多§，正常的時間內(nèi)響應(yīng)(A)，那么數(shù)據(jù)就不能及時同步到其他節(jié)點，所以C不滿足
?

2.CAP 關(guān)注的粒度是數(shù)據(jù)，而不是整個系統(tǒng)。

原文就只有一句話：

C 與 A 之間的取舍可以在同一系統(tǒng)內(nèi)以非常細小的粒度反復(fù)發(fā)生，而每一次的決策可能因為具體的操作，乃至因為牽涉到特定的數(shù)據(jù)或用戶而有所不同。

但這句話是理解和應(yīng)用 CAP 理論非常關(guān)鍵的一點。CAP 理論的定義和解釋中，用的都是 system、node 這類系統(tǒng)級的概念，這就給很多人造成了很大的誤導(dǎo)，認為我們在進行架構(gòu)設(shè)計時，整個系統(tǒng)要么選擇 CP，要么選擇 AP。但在實際設(shè)計過程中，每個系統(tǒng)不可能只處理一種數(shù)據(jù)，而是包含多種類型的數(shù)據(jù)，有的數(shù)據(jù)必須選擇 CP，有的數(shù)據(jù)必須選擇 AP。而如果我們做設(shè)計時，從整個系統(tǒng)的角度去選擇 CP 還是 AP，就會發(fā)現(xiàn)顧此失彼，無論怎么做都是有問題的。

以一個最簡單的用戶管理系統(tǒng)為例，用戶管理系統(tǒng)包含用戶賬號數(shù)據(jù)（用戶 ID、密碼）、用戶信息數(shù)據(jù)（昵稱、興趣、愛好、性別、自我介紹等）。通常情況下，用戶賬號數(shù)據(jù)會選擇 CP，而用戶信息數(shù)據(jù)會選擇 AP，如果限定整個系統(tǒng)為 CP，則不符合用戶信息數(shù)據(jù)的應(yīng)用場景；如果限定整個系統(tǒng)為 AP，則又不符合用戶賬號數(shù)據(jù)的應(yīng)用場景。

所以在 CAP 理論落地實踐時，我們需要將系統(tǒng)內(nèi)的數(shù)據(jù)按照不同的應(yīng)用場景和要求進行分類，每類數(shù)據(jù)選擇不同的策略（CP 還是 AP），而不是直接限定整個系統(tǒng)所有數(shù)據(jù)都是同一策略。

• 正常運行情況下，不存在 CP 和 AP 的選擇，可以同時滿足 CA。

CAP 理論告訴我們分布式系統(tǒng)只能選擇 CP 或者 AP，但其實這里的前提是系統(tǒng)發(fā)生了“分區(qū)”現(xiàn)象。如果系統(tǒng)沒有發(fā)生分區(qū)現(xiàn)象，也就是說 P 不存在的時候（節(jié)點間的網(wǎng)絡(luò)連接一切正常），我們沒有必要放棄 C 或者 A，應(yīng)該 C 和 A 都可以保證，這就要求架構(gòu)設(shè)計的時候既要考慮分區(qū)發(fā)生時選擇 CP 還是 AP，也要考慮分區(qū)沒有發(fā)生時如何保證 CA。

同樣以用戶管理系統(tǒng)為例，即使是實現(xiàn) CA，不同的數(shù)據(jù)實現(xiàn)方式也可能不一樣：用戶賬號數(shù)據(jù)可以采用“消息隊列”的方式來實現(xiàn) CA，因為消息隊列可以比較好地控制實時性，但實現(xiàn)起來就復(fù)雜一些；而用戶信息數(shù)據(jù)可以采用“數(shù)據(jù)庫同步”的方式來實現(xiàn) CA，因為數(shù)據(jù)庫的方式雖然在某些場景下可能延遲較高，但使用起來簡單。

• 放棄并不等于什么都不做，需要為分區(qū)恢復(fù)后做準備，即補償機制

CAP 理論告訴我們?nèi)咧荒苋蓚€，需要“犧牲”（sacrificed）另外一個，這里的“犧牲”是有一定誤導(dǎo)作用的，因為“犧牲”讓很多人理解成什么都不做。實際上，CAP 理論的“犧牲”只是說在分區(qū)過程中我們無法保證 C 或者 A，但并不意味著什么都不做。因為在系統(tǒng)整個運行周期中，大部分時間都是正常的，發(fā)生分區(qū)現(xiàn)象的時間并不長。例如，99.99% 可用性（俗稱 4 個 9）的系統(tǒng)，一年運行下來，不可用的時間只有 50 分鐘；99.999%（俗稱 5 個 9）可用性的系統(tǒng)，一年運行下來，不可用的時間只有 5 分鐘。分區(qū)期間放棄 C 或者 A，并不意味著永遠放棄 C 和 A，我們可以在分區(qū)期間進行一些操作，從而讓分區(qū)故障解決后，系統(tǒng)能夠重新達到 CA 的狀態(tài)。

最典型的就是在分區(qū)期間記錄一些日志，當分區(qū)故障解決后，系統(tǒng)根據(jù)日志進行數(shù)據(jù)恢復(fù)，使得重新達到 CA 狀態(tài)。

同樣以用戶管理系統(tǒng)為例，對于用戶賬號數(shù)據(jù)，假設(shè)我們選擇了 CP，則分區(qū)發(fā)生后，節(jié)點 1 可以繼續(xù)注冊新用戶，節(jié)點 2 無法注冊新用戶（這里就是不符合 A 的原因，因為節(jié)點 2 收到注冊請求后會返回 error），此時節(jié)點 1 可以將新注冊但未同步到節(jié)點 2 的用戶記錄到日志中。當分區(qū)恢復(fù)后，節(jié)點 1 讀取日志中的記錄，同步給節(jié)點 2，當同步完成后，節(jié)點 1 和節(jié)點 2 就達到了同時滿足 CA 的狀態(tài)。

而對于用戶信息數(shù)據(jù)，假設(shè)我們選擇了 AP，則分區(qū)發(fā)生后，節(jié)點 1 和節(jié)點 2 都可以修改用戶信息，但兩邊可能修改不一樣。例如，用戶在節(jié)點 1 中將愛好改為“旅游、美食、跑步”，然后用戶在節(jié)點 2 中將愛好改為“美食、游戲”，節(jié)點 1 和節(jié)點 2 都記錄了未同步的愛好數(shù)據(jù)，當分區(qū)恢復(fù)后，系統(tǒng)按照某個規(guī)則來合并數(shù)據(jù)。例如，按照“最后修改優(yōu)先規(guī)則”將用戶愛好修改為“美食、游戲”，按照“字數(shù)最多優(yōu)先規(guī)則”則將用戶愛好修改為“旅游，美食、跑步”，也可以完全將數(shù)據(jù)沖突報告出來，由人工來選擇具體應(yīng)該采用哪一條。

3.分區(qū)的分布式架構(gòu)

我們可以將用戶 id 為 0 ~ 100 的數(shù)據(jù)存儲在 Node 1，將用戶 id 為 101 ~ 200 的數(shù)據(jù)存儲在 Node 2，Client 根據(jù)用戶 id 來決定訪問哪個 Node。對于單個用戶來說，讀寫操作都只能在某個節(jié)點上進行；對所有用戶來說，有一部分用戶的讀寫操作在 Node 1 上，有一部分用戶的讀寫操作在 Node 2 上。

這樣的設(shè)計有一個很明顯的問題就是某個節(jié)點故障時，這個節(jié)點上的用戶就無法進行讀寫操作了，但站在整體上來看，這種設(shè)計可以降低節(jié)點故障時受影響的用戶的數(shù)量和范圍，畢竟只影響 20% 的用戶肯定要比影響所有用戶要好。這也是為什么挖掘機挖斷光纜后，支付寶只有一部分用戶會出現(xiàn)業(yè)務(wù)異常，而不是所有用戶業(yè)務(wù)異常的原因。

即這樣設(shè)計能夠保證CAP（其實更多的是CA，因為基本上是一個節(jié)點進行讀寫了），但是當節(jié)點發(fā)生故障時，會犧牲一定時間的無法寫的操作，讀操作當發(fā)現(xiàn)系統(tǒng)故障時可以路由到其他節(jié)點讀取。

3. BASE理論

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

BASE理論的核心思想是對 CAP 的延伸和補充，更具體地說，是對 CAP 中 AP 方案的一個補充。即使無法做到強一致性，但每個應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。

總的來說，BASE理論面向的是大型高可用可擴展的分布式系統(tǒng)，和傳統(tǒng)的事物ACID特性是相反的，它完全不同于ACID的強一致性模型，而是通過犧牲強一致性來獲得可用性，并允許數(shù)據(jù)在一段時間內(nèi)是不一致的，但最終達到一致狀態(tài)。

但同時，在實際的分布式場景中，不同業(yè)務(wù)單元和組件對數(shù)據(jù)一致性的要求是不同的，因此在具體的分布式系統(tǒng)架構(gòu)設(shè)計過程中，ACID特性和BASE理論往往又會結(jié)合在一起。

接下來看一下BASE中的三要素：

1.基本可用

分布式系統(tǒng)在出現(xiàn)故障時，允許損失部分可用性，即保證核心可用，這意味著，系統(tǒng)可以出現(xiàn)暫時不可用的狀態(tài)，而后面會快速恢復(fù)。

注意：這絕不等價于系統(tǒng)不可用。

比如：

（1）響應(yīng)時間上的損失–超時機制。正常情況下，一個在線搜索引擎需要在0.5秒之內(nèi)返回給用戶相應(yīng)的查詢結(jié)果，但由于出現(xiàn)故障，查詢結(jié)果的響應(yīng)時間增加了1~2秒

（2）系統(tǒng)功能上的損失–服務(wù)降級機制：正常情況下，在一個電子商務(wù)網(wǎng)站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單，但是在一些節(jié)日大促購物高峰的時候，由于消費者的購物行為激增，為了保護購物系統(tǒng)的穩(wěn)定性，部分消費者可能會被引導(dǎo)到一個降級頁面

這里的關(guān)鍵詞是“部分”和“核心”，具體選擇哪些作為可以損失的業(yè)務(wù)，哪些是必須保證的業(yè)務(wù)，是一項有挑戰(zhàn)的工作。

例如，對于一個用戶管理系統(tǒng)來說，“登錄”是核心功能，而“注冊”可以算作非核心功能。因為未注冊的用戶本來就還沒有使用系統(tǒng)的業(yè)務(wù)，注冊不了最多就是流失一部分用戶，而且這部分用戶數(shù)量較少。如果用戶已經(jīng)注冊但無法登錄，那就意味用戶無法使用系統(tǒng)。例如，充了錢的游戲不能玩了、云存儲不能用了……這些會對用戶造成較大損失，而且登錄用戶數(shù)量遠遠大于新注冊用戶，影響范圍更大。

2.軟狀態(tài)

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

即數(shù)據(jù)同步允許一定的延遲，此時可能存在不同節(jié)點的數(shù)據(jù)暫時不一致情況。

它是我們前面的“有狀態(tài)”和“無狀態(tài)”的服務(wù)的一種中間狀態(tài)。也就是說，為了提高性能，我們可以讓服務(wù)暫時保存一些狀態(tài)或數(shù)據(jù)，這些狀態(tài)和數(shù)據(jù)不是強一致性的。

3.最終一致性

最終一致性強調(diào)的是所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步之后，最終都能夠達到一個一致的狀態(tài)而不要求實時。

因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性。

這里的關(guān)鍵詞是“一定時間” 和 “最終”，“一定時間”和數(shù)據(jù)的特性是強關(guān)聯(lián)的，不同的數(shù)據(jù)能夠容忍的不一致時間是不同的。

舉一個微博系統(tǒng)的例子，用戶賬號數(shù)據(jù)最好能在 1 分鐘內(nèi)就達到一致狀態(tài)，因為用戶在 A 節(jié)點注冊或者登錄后，1 分鐘內(nèi)不太可能立刻切換到另外一個節(jié)點，但 10 分鐘后可能就重新登錄到另外一個節(jié)點了；而用戶發(fā)布的最新微博，可以容忍 30 分鐘內(nèi)達到一致狀態(tài)，因為對于用戶來說，看不到某個明星發(fā)布的最新微博，用戶是無感知的，會認為明星沒有發(fā)布微博?！白罱K”的含義就是不管多長時間，最終還是要達到一致性的狀態(tài)。

4.BASE理論和ACID的應(yīng)用場景分析

舉個例子，網(wǎng)上賣書的場景。

ACID 的玩法就是，大家在買同一本書的過程中，每個用戶的購買請求都需要把庫存鎖住，等減完庫存后，把鎖釋放出來，后續(xù)的人才能進行購買。于是，在 ACID 的玩法下，我們在同一時間不可能有多個用戶下單，我們的訂單流程需要有排隊的情況，這樣一來，我們就不可能做出性能比較高的系統(tǒng)來。

BASE 的玩法是，大家都可以同時下單，這個時候不需要去真正地分配庫存，然后系統(tǒng)異步地處理訂單，而且是批量的處理。因為下單的時候沒有真正去扣減庫存，所以，有可能會有超賣的情況。而后臺的系統(tǒng)會異步地處理訂單時，發(fā)現(xiàn)庫存沒有了，于是才會告訴用戶你沒有購買成功。

BASE 這種玩法，其實就是亞馬遜的玩法，因為要根據(jù)用戶的地址去不同的倉庫查看庫存，這個操作非常耗時，所以，不想做成異步的都不行。

在亞馬遜上買東西，你會收到一封郵件說，系統(tǒng)收到你的訂單了，然后過一會兒你會收到你的訂單被確認的郵件，這時候才是真正地分配了庫存。所以，有某些時候，你會遇到你先收到了下單的郵件，過一會又收到了沒有庫存的致歉的郵件。

有趣的是，ACID 的意思是酸，而 BASE 卻是堿的意思，因此這是一個對立的東西。其實，從本質(zhì)上來講，酸（ACID）強調(diào)的是一致性（CAP 中的 C），而堿（BASE）強調(diào)的是可用性（CAP 中的 A）。