前言

CAP一張圖

概述：互聯(lián)網(wǎng)最重要任務(wù)莫過于海量數(shù)據(jù)處理，即大規(guī)模分布式系統(tǒng)，分布式是互聯(lián)網(wǎng)的核心技術(shù)！！！

一、概念

CAP原則又稱CAP原理，指的是在一個分布式系統(tǒng)，(指互相連接并共享數(shù)據(jù)的節(jié)點(diǎn)的集合）中，當(dāng)涉及讀寫操作時，只能保證一致性（Consistency）、可用性（Availability）、分區(qū)容錯性（Partition Tolerance）三者中的兩個，另外一個必須被犧牲。
也就是說在分布式系統(tǒng)的設(shè)計(jì)中，沒有一種設(shè)計(jì)可以同時滿足這3個特性，要么CA，要么CP，要么AP！

1.1 關(guān)鍵詞解讀

上述中我們提及了2個關(guān)鍵詞：

1. 互聯(lián)和共享數(shù)據(jù)的分布式系統(tǒng)（CAP原則探討的對象）

   分布式系統(tǒng)并不一定會互聯(lián)和共享數(shù)據(jù)。
   例如 Memcache 的集群，相互之間就沒有連接和共享數(shù)據(jù)，因此 Memcache 集群這類分布式系統(tǒng)就不符合 CAP 理論探討的對象；而 MySQL 集群就是互聯(lián)和進(jìn)行數(shù)據(jù)復(fù)制的，所以才是 CAP 理論探討的對象。（傳統(tǒng)的關(guān)系型數(shù)據(jù)庫DBMS：Oracle、MySQL都是CA。）

2. 數(shù)據(jù)讀寫

   CAP 關(guān)注的是對數(shù)據(jù)的讀寫操作，而不是分布式系統(tǒng)的所有功能。

1.2 關(guān)于CAP（拆分解讀）

• 一致性（C）：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否有同樣的值，即寫操作之后的讀操作，必須返回該值。

  注意，這里的一致性指的是強(qiáng)一致性，也就是數(shù)據(jù)更新完，訪問任何節(jié)點(diǎn)看到的數(shù)據(jù)完全一致，要和弱一致性，最終一致性區(qū)分開來。

• 高可用性（A）：在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性）

• 分區(qū)容忍性（P）：以實(shí)際效果而言，分區(qū)相當(dāng)于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。

1.3 CAP原理精髓

CAP原理的精髓：就是一個數(shù)據(jù)分布式系統(tǒng)不可能同時滿足C和A和P這3個條件。（CAP理論提出就是針對分布式數(shù)據(jù)庫環(huán)境的，所以，P這個屬性必須容忍它的存在，而且是必須具備的。）

所以系統(tǒng)架構(gòu)師在設(shè)計(jì)系統(tǒng)時，不要將精力浪費(fèi)在如何設(shè)計(jì)能滿足三者的完美分布式系統(tǒng)，而是應(yīng)該進(jìn)行取舍。由于網(wǎng)絡(luò)的不可靠性，大多數(shù)開源的分布式系統(tǒng)都會實(shí)現(xiàn)P，也就是分區(qū)容忍性，之后在C和A中做抉擇。

---

二、CAP模擬場景舉例理解

以電商環(huán)境為例

假設(shè)某電商公司，在北京、杭州、上海三個城市建立了倉庫，同時建立了對應(yīng)的服務(wù)器{A, B, C}用于存儲商品信息。比如，某電吹風(fēng)在北京倉庫有 20 個，在杭州倉庫有 10 個，在上海倉庫有 30 個。那么，CAP 這三個字母在這個例子中分別代表什么呢？

• 首先，我們來看一下C。C 代表 Consistency，一致性，是指所有節(jié)點(diǎn)在同一時刻的數(shù)據(jù)是相同的，即更新操作執(zhí)行結(jié)束并響應(yīng)用戶完成后，所有節(jié)點(diǎn)存儲的數(shù)據(jù)會保持相同。在電商系統(tǒng)中，A、B、C 中存儲的該電吹風(fēng)的數(shù)量應(yīng)該是 20+10+30=60。假設(shè)，現(xiàn)在有一個北京用戶買走一個電吹風(fēng)，服務(wù)器 A 會更新數(shù)據(jù)為 60-1=59，與此同時要求 B 和 C 也更新為 59，以保證在同一時刻，無論訪問 A、B、C 中的哪個服務(wù)器，得到的數(shù)據(jù)均是 59。

• 接著，看一下 A。A 代表 Availability，可用性，是指系統(tǒng)提供的服務(wù)一直處于可用狀態(tài)，對于用戶的請求可即時響應(yīng)。在電商系統(tǒng)中，用戶在任一時刻向 A、B、C 中的任一服務(wù)器發(fā)出請求時，均可得到即時響應(yīng)，比如查詢商品信息等。

• 最后，我們看一下 P。P 代表 Partition Tolerance，分區(qū)容錯性，是指在分布式系統(tǒng)遇到網(wǎng)絡(luò)分區(qū)的情況下，仍然可以響應(yīng)用戶的請求。網(wǎng)絡(luò)分區(qū)是指因?yàn)榫W(wǎng)絡(luò)故障導(dǎo)致網(wǎng)絡(luò)不連通，不同節(jié)點(diǎn)分布在不同的子網(wǎng)絡(luò)中，各個子網(wǎng)絡(luò)內(nèi)網(wǎng)絡(luò)正常。在電商系統(tǒng)中，假設(shè) C 與 A 和 B 的網(wǎng)絡(luò)都不通了，A 和 B 是相通的。也就是說，形成了兩個分區(qū){A, B}和{C}，在這種情況下，系統(tǒng)仍能響應(yīng)用戶請求。

---

三、CAP原理證明

重溫概念

CAP原則：在分布式系統(tǒng)中 C（一致性）、A（可用性）、P（分區(qū)容錯性） 這三個特征不能同時滿足，只能滿足其中兩個；

為什么不能同時滿足（下面舉例說明）

如下圖所示，有兩臺服務(wù)器Server1、Server2，它們分別部署了數(shù)據(jù)庫 DB1 和 DB2，這兩臺機(jī)器組成一個服務(wù)集群，DB1 和 DB2 兩個數(shù)據(jù)庫中的數(shù)據(jù)要保持一致，共同為用戶提供服務(wù)。

• 用戶 User1 可以向 Server1 發(fā)起查詢數(shù)據(jù)的請求；
• 用戶 User2 可以向服務(wù)器 Server2 發(fā)起查詢數(shù)據(jù)的請求，它們共同組成了一個分布式系統(tǒng)。
  
  以此系統(tǒng)為例，分別滿足 C、A 和 P 指的是：
• 在滿足一致性 C 的情況下，Server1 和 Server2 中的數(shù)據(jù)庫始終保持一致，即 DB1 和 DB2 內(nèi)容要始終保持相同；
• 在滿足可用性 A 的情況下，用戶無論訪問 Server1 還是 Server2，都會得到即時響應(yīng)；
• 在滿足分區(qū)容錯性 P 的情況下，Server1 和 Server2 之間即使出現(xiàn)網(wǎng)絡(luò)故障也不會影響 Server1 和 Server2 分別處理用戶的請求。

當(dāng)用戶發(fā)起請求時，收到請求的服務(wù)器會及時響應(yīng)，并將用戶更新的數(shù)據(jù)同步到另一臺服務(wù)器，保證數(shù)據(jù)一致性。具體的工作流程，如下圖和流程所示：（在網(wǎng)絡(luò)環(huán)境穩(wěn)定、系統(tǒng)無故障的情況下的工作流程）

• 用戶 User1 向服務(wù)器 Server1 發(fā)起請求，將數(shù)據(jù)庫 DB1 中的數(shù)據(jù) a 由 1 改為 2；

• 系統(tǒng)會進(jìn)行數(shù)據(jù)同步，即圖中的 S 操作，將 Server1 中 DB1 的修改同步到服務(wù)器 Server2 中，使得 DB2 中的數(shù)據(jù) a 也被修改為 2；

• 當(dāng) User2 向 Server2 發(fā)起讀取數(shù)據(jù) a 的請求時，會得到 a 最新的數(shù)據(jù)值 2。
  
  在實(shí)際場景中，網(wǎng)絡(luò)環(huán)境不可能百分之百不出故障，比如網(wǎng)絡(luò)擁塞、網(wǎng)卡故障等，會導(dǎo)致網(wǎng)絡(luò)故障或不通，從而導(dǎo)致節(jié)點(diǎn)之間無法通信，或者集群中節(jié)點(diǎn)被劃分為多個分區(qū)，分區(qū)中（內(nèi)）的節(jié)點(diǎn)之間可通信，分區(qū)之間不可通信。

3.1 必須滿足分區(qū)容錯性P下的處理方式

這種由網(wǎng)絡(luò)故障導(dǎo)致的集群分區(qū)情況，通常被稱為“網(wǎng)絡(luò)分區(qū)”。在分布式系統(tǒng)中，網(wǎng)絡(luò)分區(qū)不可避免，因此分區(qū)容錯性 P 必須滿足。否則user1向server1已經(jīng)做了更改，而user2從server2請求的時候還是之前的數(shù)據(jù)，所以一般來說，分布式系統(tǒng)必須滿足分區(qū)容錯性P。

接下來，我們就來討論一下在滿足分區(qū)容錯性 P 的情況下，一致性 C 和可用性 A 是否可以同時滿足。

假設(shè)Server1 和 Server2 之間網(wǎng)絡(luò)出現(xiàn)故障，User1 向 Server1 發(fā)送請求，將數(shù)據(jù)庫 DB1 中的數(shù)據(jù) a 由 1 修改為 2，而 Server2 由于與 Server1 無法連接導(dǎo)致數(shù)據(jù)無法同步，所以 DB2 中 a 依舊是 1。這時，User2 向 Server2 發(fā)送讀取數(shù)據(jù) a 的請求時，Server2 無法給用戶返回最新數(shù)據(jù)，那么該如何處理呢？

這里闡述兩種處理方式

• 第一種處理方式是，保證一致性 C，犧牲可用性 A：Server2 選擇讓 User2 的請求阻塞，一直等到網(wǎng)絡(luò)恢復(fù)正常，Server1 被修改的數(shù)據(jù)同步更新到 Server2 之后，即 DB2 中數(shù)據(jù) a 修改成最新值 2 后，再給用戶 User2 響應(yīng)。
  
• 第二種處理方式是，保證可用性 A，犧牲一致性 C：Server2 選擇將舊的數(shù)據(jù) a=1 返回給用戶，等到網(wǎng)絡(luò)恢復(fù)，再進(jìn)行數(shù)據(jù)同步。
  -

總結(jié)
除了以上這兩種方案，沒有其他方案可以選擇?？梢钥闯?#xff1a;在滿足分區(qū)容錯性 P 的前提下，一致性 C 和可用性 A 只能選擇一個，無法同時滿足。

3.2 不是必須滿足分區(qū)容錯性P

還是上面的例子，我們分3個場景分析：

• 在保證C（一致性）和P（分區(qū)容錯性）的情況下

  為了保證數(shù)據(jù)一致性，server1需要將數(shù)據(jù)復(fù)制給server2，即server1和server2需要進(jìn)行通信。但是由于網(wǎng)絡(luò)是不可靠的，我們系統(tǒng)又保證了分區(qū)容忍性，也就是說這個系統(tǒng)是可以容忍網(wǎng)絡(luò)的不可靠的。這時候server2就不一定能及時的收到server1的數(shù)據(jù)復(fù)制消息，當(dāng)有請求向server2訪問a數(shù)據(jù)時，為了保證數(shù)據(jù)的一致性，server2只能阻塞等待數(shù)據(jù)真正同步完成后再返回，這時候就沒辦法保證高可用性了。

  所以，在保證C和P的情況下，是無法同時保證A的。

• 在保證A（高可用性）和P（分區(qū)容錯性）的情況下

  為了保證高可用性，server1和server2都有在有限時間內(nèi)返回。同樣由于網(wǎng)絡(luò)的不可靠，在有限時間內(nèi)，server2有可能還沒收到server1發(fā)來的數(shù)據(jù)更新消息，這時候返回給客戶端的可能是舊的數(shù)據(jù)，和訪問server1的數(shù)據(jù)是不一致的，也就是違法了C（一致性）。

  所以，在保證A和P的情況下，是無法同時保證C的。

• 在保證A（高可用性）和C（一致性）的情況下

  如果要保證高可用和一致性，只有在網(wǎng)絡(luò)情況良好且可靠的情況下才能實(shí)現(xiàn)。這樣server1才能立即將更新消息發(fā)送給server2。但是我們都知道網(wǎng)絡(luò)是不可靠的，是會存在丟包的情況的。所以要滿足即時可靠更新，只有將server1和server2放到一個區(qū)內(nèi)才可以，也就喪失了P（分區(qū)容錯性）這個保證。其實(shí)這時候整個系統(tǒng)也不能算是一個分布式系統(tǒng)了。

  所以，在保證A和P的情況下，是無法同時保證C的。

3.3 總結(jié)

如上所述，分布式系統(tǒng)是無法同時滿足CAP三個特性的。

---

四、CAP取舍策略（如何選擇策略及應(yīng)用）

CAP三個特性，沒有誰優(yōu)誰劣，只是在不同的分布式場景適用不同的策略，而取舍策略就是幫助我們面對不同的分布式場景時，知道如何權(quán)衡這三個特征，
舉例：對于涉及錢的交易時，數(shù)據(jù)的一致性至關(guān)重要，因此保 CP 棄 A 應(yīng)該是最佳選擇。

而對于其他場景，大多數(shù)情況下的做法是選擇 AP 而犧牲 C（強(qiáng)一致性），因?yàn)楹芏嗲闆r下不需要太強(qiáng)的一致性（數(shù)據(jù)始終保持一致），只要滿足最終一致性即可；

• 最終一致性：不要求集群中節(jié)點(diǎn)數(shù)據(jù)每時每刻保持一致，在可接受的時間內(nèi)最終能達(dá)到一致就可以了；

• 強(qiáng)一致性：任何一次讀都能讀到某個數(shù)據(jù)的最近一次寫的數(shù)據(jù)，即復(fù)制是同步的；

• 弱一致性：數(shù)據(jù)更新后，如果能容忍后續(xù)的訪問只能訪問到部分或者全部訪問不到，則是弱一致性；

注：關(guān)于一致性的具體描述，請參考這篇帖子：

CAP三個特性只能滿足其中兩個，那么取舍的策略排列組合后也就共有三種：CP、CA、AP

4.1 CA無P

在分布式系統(tǒng)中，現(xiàn)在的網(wǎng)絡(luò)基礎(chǔ)設(shè)施無法做到始終保持穩(wěn)定，網(wǎng)絡(luò)分區(qū)（網(wǎng)絡(luò)不連通）難以避免。犧牲分區(qū)容錯性 P，就相當(dāng)于放棄使用分布式系統(tǒng)。因此，在分布式系統(tǒng)中，這種策略不需要過多討論。

如果不要求P（不允許分區(qū)），則C（強(qiáng)一致性）和A（可用性）是可以保證的。但放棄P的同時也就意味著放棄了系統(tǒng)的擴(kuò)展性，也就是分布式節(jié)點(diǎn)受限，沒辦法部署子節(jié)點(diǎn)，這是違背分布式系統(tǒng)設(shè)計(jì)的初衷的。單點(diǎn)系統(tǒng)滿足 CA 特性：比如 關(guān)系型數(shù)據(jù)庫 DBMS（比如 MySQL、Oracle）部署在單臺機(jī)器上，因?yàn)椴淮嬖诰W(wǎng)絡(luò)通信問題，所以保證 CA 就可以了。

4.2 CP無A

如果一個分布式場景需要很強(qiáng)的數(shù)據(jù)一致性，或者該場景可以容忍系統(tǒng)長時間無響應(yīng)的情況下，保 CP 棄 A 這個策略就比較適合。

若不要求A（高可用性），相當(dāng)于每個請求都需要在服務(wù)器之間保持強(qiáng)一致，而P（分區(qū)）會導(dǎo)致同步時間無限延長(也就是等待數(shù)據(jù)同步完才能正常訪問服務(wù))，一個保證 CP 而舍棄 A 的分布式系統(tǒng)，一旦發(fā)生網(wǎng)絡(luò)分區(qū)會導(dǎo)致數(shù)據(jù)無法同步情況，就要犧牲系統(tǒng)的可用性，降低用戶體驗(yàn)，直到節(jié)點(diǎn)數(shù)據(jù)達(dá)到一致后再響應(yīng)用戶。

設(shè)計(jì)成CP的系統(tǒng)其實(shí)不少，最典型的就是分布式數(shù)據(jù)庫，如 Redis、HBase、ZooKeeper等。對于這些分布式數(shù)據(jù)庫來說，數(shù)據(jù)的一致性是最基本的要求。

4.3 AP無C

如果一個分布式場景需要很高的可用性A，或者說在網(wǎng)絡(luò)狀況不太好的情況下，該場景允許數(shù)據(jù)暫時不一致，那這種情況下就可以犧牲一定的一致性C了。

目前，采用保 AP 棄 C 的系統(tǒng)也有很多，比如 ==CoachDB、Eureka、Cassandra、DynamoDB ==等。

網(wǎng)絡(luò)分區(qū)出現(xiàn)后，各個節(jié)點(diǎn)之間數(shù)據(jù)無法馬上同步，為了保證高可用，分布式系統(tǒng)需要即刻響應(yīng)用戶的請求。但此時可能某些節(jié)點(diǎn)還沒有拿到最新數(shù)據(jù)，只能將本地舊的數(shù)據(jù)返回給用戶，從而導(dǎo)致數(shù)據(jù)不一致的情況。

適合保證 AP 放棄 C 的場景有很多。比如，很多查詢網(wǎng)站、電商系統(tǒng)中的商品查詢等，用戶體驗(yàn)非常重要，所以大多會保證系統(tǒng)的可用性，而犧牲一定的數(shù)據(jù)一致性。典型的應(yīng)用就如搶購手機(jī)場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當(dāng)你選擇完商品準(zhǔn)備下單的時候，系統(tǒng)提示你下單失敗，商品已售完。
舉例：

假如，上海的網(wǎng)絡(luò)出現(xiàn)了問題，與北京和杭州網(wǎng)絡(luò)均不通，此時北京的用戶通過北京服務(wù)器 A 下單購買了一個電吹風(fēng)，電吹風(fēng)數(shù)量減少到 59，并且同步給了杭州服務(wù)器 B。也就是說，現(xiàn)在用戶的查詢請求如果是提交到服務(wù)器 A 和 B，那么查詢到的數(shù)量為 59。但通過上海服務(wù)器 C 進(jìn)行查詢的結(jié)果，卻是 60。
待網(wǎng)絡(luò)恢復(fù)后，服務(wù)器 A 和 B 的數(shù)據(jù)會同步到 C，C 更新數(shù)據(jù)為 59，最終三臺服務(wù)器數(shù)據(jù)保持一致，用戶刷新一下查詢界面或重新提交一下查詢，就可以得到最新的數(shù)據(jù)。而對用戶來說，他們并不會感知到前后數(shù)據(jù)的差異，到底是因?yàn)槠渌脩糍徺I導(dǎo)致的，還是因?yàn)榫W(wǎng)絡(luò)故障導(dǎo)致數(shù)據(jù)不同步而產(chǎn)生的。

這其實(shí)就是先在 A（可用性）方面保證系統(tǒng)可以正常的服務(wù)，然后在數(shù)據(jù)的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗(yàn)，但也不至于造成用戶購物流程的嚴(yán)重阻塞，因?yàn)槿绻鹊綌?shù)據(jù)一致之后再給用戶返回的話，用戶的響應(yīng)太慢，可能會造成嚴(yán)重的用戶流失。

4.4 總結(jié)

五、其他

5.1 事務(wù)的ACID與分布式系統(tǒng)的CAP

5.1.1 事務(wù)的ACID

1.Atomicity（原子性）
一個事務(wù)中的所有操作，要么全部完成，要么全部不完成，不會在中間某個環(huán)節(jié)結(jié)束。事務(wù)在執(zhí)行過程中發(fā)生錯誤，會被回滾到事務(wù)開始前的狀態(tài)，就像這個事務(wù)從來沒有執(zhí)行過一樣。

2.Consistency（一致性）
在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性沒有被破壞。

3.Isolation（隔離性）
數(shù)據(jù)庫允許多個并發(fā)事務(wù)同時對數(shù)據(jù)進(jìn)行讀寫和修改的能力。隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。事務(wù)隔離分為不同級別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重復(fù)讀（repeatable read）和串行化（Serializable）。

4.Durability（持久性）
事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失。

5.1.2 區(qū)別

可以看到，ACID 中的 A（Atomicity）和 CAP 中的 A（Availability）意義完全不同，而 ACID 中的 C 和 CAP 中的 C 名稱雖然都是一致性，但含義也完全不一樣。ACID 中的 C 是指數(shù)據(jù)庫的數(shù)據(jù)完整性，而 CAP 中的 C 是指分布式節(jié)點(diǎn)中的數(shù)據(jù)一致性。

ACID 的應(yīng)用場景是數(shù)據(jù)庫事務(wù)，CAP 關(guān)注的是分布式系統(tǒng)數(shù)據(jù)讀寫；

5.1.3 CAP 和 ACID 的“C、A”是一樣的嗎？

首先，我們看一下 CAP 中的 C 和 ACID 中的 C 是否一致。

• CAP 中的 C 強(qiáng)調(diào)的是數(shù)據(jù)的一致性，也就是集群中節(jié)點(diǎn)之間通過復(fù)制技術(shù)保證每個節(jié)點(diǎn)上的數(shù)據(jù)在同一時刻是相同的。
• ACID 中的 C 強(qiáng)調(diào)的是事務(wù)執(zhí)行前后，數(shù)據(jù)的完整性保持一致或滿足完整性約束。也就是不管在什么時候，不管并發(fā)事務(wù)有多少，事務(wù)在分布式系統(tǒng)中的狀態(tài)始終保持一致。
• 總結(jié)：事務(wù)中的一致性，是指滿足完整性約束條件，CAP中的一致性，是指讀寫一致性。

其次，我們看一下 CAP 中的 A 和 ACID 中的 A。

• CAP 中的 A 指的是可用性（Availability），也就是系統(tǒng)提供的服務(wù)一直處于可用狀態(tài)，即對于用戶的請求可即時響應(yīng)。
• ACID 中的 A 指的是原子性（Atomicity），強(qiáng)調(diào)的是事務(wù)要么執(zhí)行成功，要么執(zhí)行失敗。

因此，CAP 和 ACID 中的“C”和“A”是不一樣的，不能混為一談。

5.2 關(guān)于BASE 理論

BASE是對CAP中一致性C 和高可用性A權(quán)衡的結(jié)果

5.2.1概念

BASE是Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）三個短語的簡寫；

5.2.2 核心思想

核心思想：即使無法做到強(qiáng)一致性（Strong consistency），但每個應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性（Eventual consistency）。

5.2.3 關(guān)于BASE

1. Basically Available（基本可用）

基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時候，允許損失部分可用性，但請注意，這絕不等價于系統(tǒng)不可用，以下兩個就是“基本可用”的典型例子：

• 響應(yīng)時間上的損失：正常情況下，一個在線搜索引擎需要0.5秒內(nèi)返回給用戶相應(yīng)的查詢結(jié)果，但由于出現(xiàn)異常（比如系統(tǒng)部分機(jī)房發(fā)生斷電或斷網(wǎng)故障），查詢結(jié)果的響應(yīng)時間增加到了1~2秒。
• 功能上的損失：正常情況下，在一個電子商務(wù)網(wǎng)站上進(jìn)行購物，消費(fèi)者幾乎能夠順利地完成每一筆訂單，但是在一些節(jié)日大促購物高峰的時候，由于消費(fèi)者的購物行為激增，為了保護(hù)購物系統(tǒng)的穩(wěn)定性，部分消費(fèi)者可能會被引導(dǎo)到一個降級頁面。

2. Soft state（軟狀態(tài)）

軟狀態(tài)也稱弱狀態(tài)，和硬狀態(tài)相對，是指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認(rèn)為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點(diǎn)的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)同步的過程存在延時。

3. Eventually consistent（最終一致性）

最終一致性強(qiáng)調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步后，最終能夠達(dá)到一個一致的狀態(tài)。

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

5.3 BASE理論和CAP原則的區(qū)別與聯(lián)系

BASE 理論本質(zhì)上是對 CAP 的延伸和補(bǔ)充，更具體地說，是對 CAP 中 AP 方案的一個補(bǔ)充。是對一致性C 和高可用性A權(quán)衡的結(jié)果

前面在剖析 CAP 理論時，提到了其實(shí)和 BASE 相關(guān)的兩點(diǎn)：

• CAP 理論是忽略延時的，而實(shí)際應(yīng)用中延時是無法避免的。
  這一點(diǎn)就意味著完美的 CP 場景是不存在的，即使是幾毫秒的數(shù)據(jù)復(fù)制延遲，在這幾毫秒時間間隔內(nèi)，系統(tǒng)是不符合 CP 要求的。因此 CAP 中的 CP 方案，實(shí)際上也是實(shí)現(xiàn)了最終一致性，只是“一定時間”是指幾毫秒而已。

• AP 方案中犧牲一致性只是指分區(qū)期間，而不是永遠(yuǎn)放棄一致性。

  這一點(diǎn)其實(shí)就是 BASE 理論延伸的地方，分區(qū)期間犧牲一致性，但分區(qū)故障恢復(fù)后，系統(tǒng)應(yīng)該達(dá)到最終一致性。

綜合上面的分析，ACID 是數(shù)據(jù)庫事務(wù)完整性的理論，CAP 是分布式系統(tǒng)設(shè)計(jì)理論，BASE 是 CAP 理論中 AP 方案的延伸。

5.4 CAP原則注意事項(xiàng)

1. CAP關(guān)注的粒度是數(shù)據(jù)（對數(shù)據(jù)的讀寫操作），而不是整個系統(tǒng)；

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

3. CAP 是忽略網(wǎng)絡(luò)延遲的。

   當(dāng)事務(wù)提交時，數(shù)據(jù)能夠瞬間復(fù)制到所有節(jié)點(diǎn)。但實(shí)際情況下，從節(jié)點(diǎn) A 復(fù)制數(shù)據(jù)到節(jié)點(diǎn) B，總是需要花費(fèi)一定時間的。如果是跨地域的機(jī)房，例如北京機(jī)房同步到廣州機(jī)房，耗費(fèi)的時間就可能是幾十毫秒。這就意味著，CAP 理論中的 C 在實(shí)踐中是不可能完美實(shí)現(xiàn)的，在數(shù)據(jù)復(fù)制的過程中，節(jié)點(diǎn) A 和節(jié)點(diǎn) B 的數(shù)據(jù)并不一致。

4. 取舍（放棄）并不等于什么都不做，需要為分區(qū)恢復(fù)后做準(zhǔn)備

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

六、總結(jié)

1. CAP順口溜：三者不可共存，通常選AP

• C要求數(shù)據(jù)完全一致
• A要求返回及時
• P要求分布式和數(shù)據(jù)同步

2. 一致性高，可用性低
   一致性低，可用性高

3. 取舍策略
   CA - 單點(diǎn)集群，滿足一致性，可用性的系統(tǒng)，通常在可擴(kuò)展性上不太強(qiáng)大。
   CP - 滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。
   AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)，通?？赡軐σ恢滦砸蟮鸵恍?/p>