原創(chuàng)聲明
作者: 劉丹冰Aceld，微信公眾號(hào)同名

作為當(dāng)今互聯(lián)網(wǎng)后端技術(shù)棧工程師、無(wú)論Golang、Java或者其他系，分布式的理論概念都逐步成為必備理論基礎(chǔ)知識(shí)之一, 本文主要討論分布式的CAP理論的推進(jìn)，這是你走進(jìn)分布式大門的第一塊敲門磚。

提綱:
一、從本地事務(wù)到分布式理論
二、ACID理論
三、CAP理論
四、CAP理論“3選2”論證
五、BASE理論

附加:分布式概念

分布式實(shí)際上就是單一的本地一體解決方案，在硬件或者資源上不夠業(yè)務(wù)需求，而采取的一種分散式多節(jié)點(diǎn)，可以擴(kuò)容資源的一種解決思路。它研究如何把一個(gè)需要非常巨大的計(jì)算能力才能解決的問題分成許多小的部分，然后把這些部分分配給多個(gè)計(jì)算機(jī)進(jìn)行處理，最后把這些計(jì)算結(jié)果綜合起來(lái)得到最終的結(jié)果。

那么在了解分布式之前，我們應(yīng)該從一體式的構(gòu)造開始說(shuō)明。

一、從本地事務(wù)到分布式理論

理解第一個(gè)問題就是"事務(wù)"

事務(wù)提供一種機(jī)制將一個(gè)活動(dòng)涉及的所有操作納入到一個(gè)不可分割的執(zhí)行單元，組成事務(wù)的所有操作只有在所有操作均能正常執(zhí)行的情況下方能提交，只要其中任一操作執(zhí)行失敗，都將導(dǎo)致整個(gè)事務(wù)的回滾。

簡(jiǎn)單地說(shuō)，事務(wù)提供一種“ 要么什么都不做，要么做全套（All or Nothing）”機(jī)制。

二、ACID理論

? 事務(wù)是基于數(shù)據(jù)進(jìn)行操作，需要保證事務(wù)的數(shù)據(jù)通常存儲(chǔ)在數(shù)據(jù)庫(kù)中，所以介紹到事務(wù)，就不得不介紹數(shù)據(jù)庫(kù)事務(wù)的ACID特性，指數(shù)據(jù)庫(kù)事務(wù)正確執(zhí)行的四個(gè)基本特性的縮寫。包含：

• 原子性（Atomicity）

• 一致性（Consistency）

• 隔離性（Isolation）

• 持久性（Durability）

(1) 原子性（Atomicity）

? 整個(gè)事務(wù)中的所有操作，要么全部完成，要么全部不完成，不可能停滯在中間某個(gè)環(huán)節(jié)。

例如：銀行轉(zhuǎn)賬，從A賬戶轉(zhuǎn)100元至B賬戶：

A、從A賬戶取100元

B、存入100元至B賬戶。 這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會(huì)莫名其妙少了100元。

(2) 一致性（Consistency）

在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫(kù)數(shù)據(jù)的一致性約束沒有被破壞。

例如：現(xiàn)有完整性約束A+B=100，如果一個(gè)事務(wù)改變了A，那么必須得改變B，使得事務(wù)結(jié)束后依然滿足A+B=100，否則事務(wù)失敗。

(3) 隔離性（Isolation）

? 數(shù)據(jù)庫(kù)允許多個(gè)并發(fā)事務(wù)同時(shí)對(duì)數(shù)據(jù)進(jìn)行讀寫和修改的能力，如果一個(gè)事務(wù)要訪問的數(shù)據(jù)正在被另外一個(gè)事務(wù)修改，只要另外一個(gè)事務(wù)未提交，它所訪問的數(shù)據(jù)就不受未提交事務(wù)的影響。隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。

例如：現(xiàn)有有個(gè)交易是從A賬戶轉(zhuǎn)100元至B賬戶，在這個(gè)交易事務(wù)還未完成的情況下，如果此時(shí)B查詢自己的賬戶，是看不到新增加的100元的。

(4) 持久性（Durability）

? 事務(wù)處理結(jié)束后，對(duì)數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會(huì)丟失。

? 本地事務(wù)ACID實(shí)際上可用”統(tǒng)一提交，失敗回滾“幾個(gè)字總結(jié)，嚴(yán)格保證了同一事務(wù)內(nèi)數(shù)據(jù)的一致性！

而分布式事務(wù)不能實(shí)現(xiàn)這種ACID。因?yàn)橛蠧AP理論約束。接下來(lái)我們來(lái)了解一下，分布式中是如何保證以上特性的，那么就有了一個(gè)著名的CAP理論。

三、CAP理論

? 在設(shè)計(jì)一個(gè)大規(guī)模可擴(kuò)放的網(wǎng)絡(luò)服務(wù)時(shí)候會(huì)遇到三個(gè)特性：一致性（consistency）、可用性（Availability）、分區(qū)容錯(cuò)（partition-tolerance）都需要的情景.

? CAP定律說(shuō)的是在一個(gè)分布式計(jì)算機(jī)系統(tǒng)中，一致性，可用性和分區(qū)容錯(cuò)性這三種保證無(wú)法同時(shí)得到滿足，最多滿足兩個(gè)。

如上圖，CAP的三種特性只能同時(shí)滿足兩個(gè)。而且在不同的兩兩組合，也有一些成熟的分布式產(chǎn)品。

接下來(lái)，我們來(lái)介紹一下CAP的三種特性，我們采用一個(gè)應(yīng)用場(chǎng)景來(lái)分析CAP中的每個(gè)特點(diǎn)的含義。

該場(chǎng)景整體分為5個(gè)流程：

流程一、客戶端發(fā)送請(qǐng)求(如:添加訂單、修改訂單、刪除訂單)

流程二、Web業(yè)務(wù)層處理業(yè)務(wù)，并修改存儲(chǔ)成數(shù)據(jù)信息

流程三、存儲(chǔ)層內(nèi)部Master與Backup的數(shù)據(jù)同步

流程四、Web業(yè)務(wù)層從存儲(chǔ)層取出數(shù)據(jù)

流程五、Web業(yè)務(wù)層返回?cái)?shù)據(jù)給客戶端

(1) 一致性Consistency

“all nodes see the same data at the same time”

一旦數(shù)據(jù)更新完成并成功返回客戶端后，那么分布式系統(tǒng)中所有節(jié)點(diǎn)在同一時(shí)間的數(shù)據(jù)完全一致。

在CAP的一致性中還包括強(qiáng)一致性、弱一致性、最終一致性等級(jí)別，稍后我們?cè)诤罄m(xù)章節(jié)介紹。

一致性是指寫操作后的讀操作可以讀取到最新的數(shù)據(jù)狀態(tài)，當(dāng)數(shù)據(jù)分布在多個(gè)節(jié)點(diǎn)上，從任意結(jié)點(diǎn)讀取到的數(shù)據(jù)都是最新的狀態(tài)。

一致性實(shí)現(xiàn)目標(biāo)：

• Web業(yè)務(wù)層向主Master寫數(shù)據(jù)庫(kù)成功，從Backup讀數(shù)據(jù)也成功。

• Web業(yè)務(wù)層向主Master讀數(shù)據(jù)庫(kù)失敗，從Backup讀數(shù)據(jù)也失敗。

  
  

必要實(shí)現(xiàn)流程：

寫入主數(shù)據(jù)庫(kù)后，在向從數(shù)據(jù)庫(kù)同步期間要將從數(shù)據(jù)庫(kù)鎖定，待同步完成后再釋放鎖，以免在新數(shù)據(jù)寫入成功后，向從數(shù)據(jù)庫(kù)查詢到舊的數(shù)據(jù)。

分布式一致性特點(diǎn)：

1. 由于存在數(shù)據(jù)同步的過程，寫操作的響應(yīng)會(huì)有一定的延遲。
2. 為了保證數(shù)據(jù)一致性會(huì)對(duì)資源暫時(shí)鎖定，待數(shù)據(jù)同步完成釋放鎖定資源。
3. 如果請(qǐng)求數(shù)據(jù)同步失敗的結(jié)點(diǎn)則會(huì)返回錯(cuò)誤信息，一定不會(huì)返回舊數(shù)據(jù)。

(2) 可用性(Availability)

“Reads and writes always succeed”

服務(wù)一直可用，而且是正常響應(yīng)時(shí)間。

對(duì)于可用性的衡量標(biāo)準(zhǔn)如下：

可用性實(shí)現(xiàn)目標(biāo)：

• 當(dāng)Master正在被更新，Backup數(shù)據(jù)庫(kù)接收到數(shù)據(jù)查詢的請(qǐng)求則立即能夠響應(yīng)數(shù)據(jù)查詢結(jié)果。

• backup數(shù)據(jù)庫(kù)不允許出現(xiàn)響應(yīng)超時(shí)或響應(yīng)錯(cuò)誤。

必要實(shí)現(xiàn)流程：

1. 寫入Master主數(shù)據(jù)庫(kù)后要將數(shù)據(jù)同步到從數(shù)據(jù)庫(kù)。

2. 由于要保證Backup從數(shù)據(jù)庫(kù)的可用性，不可將Backup從數(shù)據(jù)庫(kù)中的資源進(jìn)行鎖定。

3. 即時(shí)數(shù)據(jù)還沒有同步過來(lái)，從數(shù)據(jù)庫(kù)也要返回要查詢的數(shù)據(jù)，哪怕是舊數(shù)據(jù)/或者默認(rèn)數(shù)據(jù)，但不能返回錯(cuò)誤或響應(yīng)超時(shí)。

分布式可用性特點(diǎn)：

所有請(qǐng)求都有響應(yīng)，且不會(huì)出現(xiàn)響應(yīng)超時(shí)或響應(yīng)錯(cuò)誤。

(3) 分區(qū)容錯(cuò)性(Partition tolerance)

“the system continues to operate despite arbitrary message loss or failure of part of the system”

分布式系統(tǒng)中，盡管部分節(jié)點(diǎn)出現(xiàn)任何消息丟失或者故障，系統(tǒng)應(yīng)繼續(xù)運(yùn)行。

通常分布式系統(tǒng)的各各結(jié)點(diǎn)部署在不同的子網(wǎng)，這就是網(wǎng)絡(luò)分區(qū)，不可避免的會(huì)出現(xiàn)由于網(wǎng)絡(luò)問題而導(dǎo)致結(jié)點(diǎn)之間通信失敗，此時(shí)仍可對(duì)外提供服務(wù)。

分區(qū)容錯(cuò)性實(shí)現(xiàn)目標(biāo)：

• 主數(shù)據(jù)庫(kù)向從數(shù)據(jù)庫(kù)同步數(shù)據(jù)失敗不影響讀寫操作。

• 其一個(gè)結(jié)點(diǎn)掛掉不影響另一個(gè)結(jié)點(diǎn)對(duì)外提供服務(wù)。

  
  

必要實(shí)現(xiàn)流程：

1. 盡量使用異步取代同步操作，例如使用異步方式將數(shù)據(jù)從主數(shù)據(jù)庫(kù)同步到從數(shù)據(jù)，這樣結(jié)點(diǎn)之間能有效的實(shí)現(xiàn)松耦合。
2. 添加Backup從數(shù)據(jù)庫(kù)結(jié)點(diǎn)，其中一個(gè)Backup從結(jié)點(diǎn)掛掉其它Backup從結(jié)點(diǎn)提供服務(wù)。

分區(qū)容錯(cuò)性特點(diǎn)：

分區(qū)容忍性分是布式系統(tǒng)具備的基本能力。

四、CAP的”3選2“證明

(1) 基本場(chǎng)景

在小結(jié)中，我們主要介紹CAP的理論為什么不能夠3個(gè)特性同時(shí)滿足。

如上圖，是我們證明CAP的基本場(chǎng)景，分布式網(wǎng)絡(luò)中有兩個(gè)節(jié)點(diǎn)Host1和Host2，他們之間網(wǎng)絡(luò)可以連通，Host1中運(yùn)行Process1程序和對(duì)應(yīng)的數(shù)據(jù)庫(kù)Data，Host2中運(yùn)行Process2程序和對(duì)應(yīng)數(shù)據(jù)庫(kù)Data。

(2) CAP特性

如果滿足一致性(C)：那么Data(0) = Data(0).

如果滿足可用性(A): 用戶不管請(qǐng)求Host1或Host2，都會(huì)立刻響應(yīng)結(jié)果。

如果滿足分區(qū)容錯(cuò)性(P): Host1或Host2有一方脫離系統(tǒng)(故障)， 都不會(huì)影響Host1和Host2彼此之間正常運(yùn)作。

(3) 分布式系統(tǒng)正常運(yùn)行流程

如上圖，是分布式系統(tǒng)正常運(yùn)轉(zhuǎn)的流程。

A、用戶向Host1主機(jī)請(qǐng)求數(shù)據(jù)更新，程序Process1更新數(shù)據(jù)庫(kù)Data(0)為Data(1)

B、分布式系統(tǒng)將數(shù)據(jù)進(jìn)行同步操作，將Host1中的Data(1)同步的Host2中``Data(0),使Host2中的數(shù)據(jù)也變?yōu)?/code>Data(1)`

C、當(dāng)用戶請(qǐng)求主機(jī)Host2時(shí)，則Process2則響應(yīng)最新的Data(1)數(shù)據(jù)

根據(jù)CAP的特性：

• Host1和Host2的數(shù)據(jù)庫(kù)Data之間的數(shù)據(jù)是否一樣為一致性(C)

• 用戶對(duì)Host1和Host2的請(qǐng)求響應(yīng)為可用性(A)

• Host1和Host2之間的各自網(wǎng)絡(luò)環(huán)境為分區(qū)容錯(cuò)性(P)

當(dāng)前是一個(gè)正常運(yùn)作的流程，目前CAP三個(gè)特性可以同時(shí)滿足，也是一個(gè)理想狀態(tài),但是實(shí)際應(yīng)用場(chǎng)景中，發(fā)生錯(cuò)誤在所難免，那么如果發(fā)生錯(cuò)誤CAP是否能同時(shí)滿足，或者該如何取舍？

---

(4) 分布式系統(tǒng)異常運(yùn)行流程

假設(shè)Host1和Host2之間的網(wǎng)絡(luò)斷開了，我們要支持這種網(wǎng)絡(luò)異常，相當(dāng)于要滿足分區(qū)容錯(cuò)性(P)，能不能同時(shí)滿足一致性(C)和可用響應(yīng)性(A)呢？

假設(shè)在N1和N2之間網(wǎng)絡(luò)斷開的時(shí)候，

A、用戶向Host1發(fā)送數(shù)據(jù)更新請(qǐng)求，那Host1中的數(shù)據(jù)Data(0)將被更新為Data(1)

B、弱此時(shí)Host1和Host2網(wǎng)絡(luò)是斷開的，所以分布式系統(tǒng)同步操作將失敗，Host2中的數(shù)據(jù)依舊是Data(0)

C、有用戶向Host2發(fā)送數(shù)據(jù)讀取請(qǐng)求，由于數(shù)據(jù)還沒有進(jìn)行同步，Process2沒辦法立即給用戶返回最新的數(shù)據(jù)V1，那么將面臨兩個(gè)選擇。

第一，犧牲數(shù)據(jù)一致性(c)，響應(yīng)舊的數(shù)據(jù)Data(0)給用戶；

第二，犧牲可用性(A)，阻塞等待，直到網(wǎng)絡(luò)連接恢復(fù)，數(shù)據(jù)同步完成之后，再給用戶響應(yīng)最新的數(shù)據(jù)Data(1)。

這個(gè)過程，證明了要滿足分區(qū)容錯(cuò)性(p)的分布式系統(tǒng)，只能在一致性(C)和可用性(A)兩者中，選擇其中一個(gè)。

(5) "3選2"的必然性

通過CAP理論，我們知道無(wú)法同時(shí)滿足一致性、可用性和分區(qū)容錯(cuò)性這三個(gè)特性，那要舍棄哪個(gè)呢？

CA 放棄 P：

一個(gè)分布式系統(tǒng)中，不可能存在不滿足P，放棄分區(qū)容錯(cuò)性(p)，即不進(jìn)行分區(qū)，不考慮由于網(wǎng)絡(luò)不通或結(jié)點(diǎn)掛掉的問題，則可以實(shí)現(xiàn)一致性和可用性。那么系統(tǒng)將不是一個(gè)標(biāo)準(zhǔn)的分布式系統(tǒng)。我們最常用的關(guān)系型數(shù)據(jù)就滿足了CA，如下：

主數(shù)據(jù)庫(kù)和從數(shù)據(jù)庫(kù)中間不再進(jìn)行數(shù)據(jù)同步，數(shù)據(jù)庫(kù)可以響應(yīng)每次的查詢請(qǐng)求，通過事務(wù)(原子性操作)隔離級(jí)別實(shí)現(xiàn)每個(gè)查詢請(qǐng)求都可以返回最新的數(shù)據(jù)。

注意：

對(duì)于一個(gè)分布式系統(tǒng)來(lái)說(shuō)。P是一個(gè)基本要求，CAP三者中，只能在CA兩者之間做權(quán)衡，并且要想盡辦法提升P。

CP 放棄 A

如果一個(gè)分布式系統(tǒng)不要求強(qiáng)的可用性，即容許系統(tǒng)停機(jī)或者長(zhǎng)時(shí)間無(wú)響應(yīng)的話，就可以在CAP三者中保障CP而舍棄A。

放棄可用性，追求一致性和分區(qū)容錯(cuò)性，如Redis、HBase等，還有分布式系統(tǒng)中常用的Zookeeper也是在CAP三者之中選擇優(yōu)先保證CP的。

場(chǎng)景：

跨行轉(zhuǎn)賬，一次轉(zhuǎn)賬請(qǐng)求要等待雙方銀行系統(tǒng)都完成整個(gè)事務(wù)才算完成。

AP 放棄 C

放棄一致性，追求分區(qū)容忍性和可用性。這是很多分布式系統(tǒng)設(shè)計(jì)時(shí)的選擇。實(shí)現(xiàn)AP，前提是只要用戶可以接受所查詢的到數(shù)據(jù)在一定時(shí)間內(nèi)不是最新的即可。

通常實(shí)現(xiàn)AP都會(huì)保證最終一致性，后面講的BASE理論就是根據(jù)AP來(lái)擴(kuò)展的。

場(chǎng)景1

淘寶訂單退款。今日退款成功，明日賬戶到賬，只要用戶可以接受在一定時(shí)間內(nèi)到賬即可。

場(chǎng)景2：

12306的買票。都是在可用性和一致性之間舍棄了一致性而選擇可用性。

在12306買票的時(shí)候提示有票（但是可能實(shí)際已經(jīng)沒票了），用戶正常去輸入驗(yàn)證碼，下單。但是過了一會(huì)系統(tǒng)提示下單失敗，余票不足。這其實(shí)就是先在可用性方面保證系統(tǒng)可以正常的服務(wù)，然后在數(shù)據(jù)的一致性方面做了些犧牲，會(huì)影響一些用戶體驗(yàn)，但是也不至于造成用戶流程的嚴(yán)重阻塞。

但是，我們說(shuō)很多網(wǎng)站犧牲了一致性，選擇了可用性，這其實(shí)也不準(zhǔn)確的。就比如上面的買票的例子，其實(shí)舍棄的只是強(qiáng)一致性。退而求其次保證了最終一致性。也就是說(shuō)，雖然下單的瞬間，關(guān)于車票的庫(kù)存可能存在數(shù)據(jù)不一致的情況，但是過了一段時(shí)間，還是要保證最終一致性的。

(6) 總結(jié):

CA 放棄 P：如果不要求P（不允許分區(qū)），則C（強(qiáng)一致性）和A（可用性）是可以保證的。這樣分區(qū)將永遠(yuǎn)不會(huì)存在，因此CA的系統(tǒng)更多的是允許分區(qū)后各子系統(tǒng)依然保持CA。

CP 放棄 A：如果不要求A（可用），相當(dāng)于每個(gè)請(qǐng)求都需要在Server之間強(qiáng)一致，而P（分區(qū)）會(huì)導(dǎo)致同步時(shí)間無(wú)限延長(zhǎng)，如此CP也是可以保證的。很多傳統(tǒng)的數(shù)據(jù)庫(kù)分布式事務(wù)都屬于這種模式。

AP 放棄 C：要高可用并允許分區(qū)，則需放棄一致性。一旦分區(qū)發(fā)生，節(jié)點(diǎn)之間可能會(huì)失去聯(lián)系，為了高可用，每個(gè)節(jié)點(diǎn)只能用本地?cái)?shù)據(jù)提供服務(wù)，而這樣會(huì)導(dǎo)致全局?jǐn)?shù)據(jù)的不一致性。現(xiàn)在眾多的NoSQL都屬于此類。

五、思考

思考：按照CAP理論如何設(shè)計(jì)一個(gè)電商系統(tǒng)？

• 首先個(gè)電商網(wǎng)站核心模塊有用戶，訂單，商品，支付，促銷管理等

1、對(duì)于用戶模塊，包括登錄，個(gè)人設(shè)置，個(gè)人訂單，購(gòu)物車，收藏夾等，這些模塊保證AP，數(shù)據(jù)短時(shí)間不一致不影響使用。
2、訂單模塊的下單付款扣減庫(kù)存操作是整個(gè)系統(tǒng)的核心，CA都需要保證，極端情況下面犧牲A保證C
3、商品模塊的商品上下架和庫(kù)存管理保證CP
4、搜索功能因?yàn)楸旧砭筒皇菍?shí)時(shí)性非常高的模塊，所以保證AP就可以了。
5、促銷是短時(shí)間的數(shù)據(jù)不一致，結(jié)果就是優(yōu)惠信息看不到，但是已有的優(yōu)惠要保證可用，而且優(yōu)惠可以提前預(yù)計(jì)算，所以可以保證AP。
6、支付這一塊是獨(dú)立的系統(tǒng)，或者使用第三方的支付寶，微信。其實(shí)CAP是由第三方來(lái)保證的，支付系統(tǒng)是一個(gè)對(duì)CAP要求極高的系統(tǒng)，C是必須要保證的，AP中A相對(duì)更重要，不能因?yàn)榉謪^(qū)，導(dǎo)致所有人都不能支付

六、分布式BASE理論

? CAP 不可能同時(shí)滿足，而分區(qū)容錯(cuò)性(P)是對(duì)于分布式系統(tǒng)而言是必須的。如果系統(tǒng)能夠同時(shí)實(shí)現(xiàn) CAP 是再好不過的了，所以出現(xiàn)了 BASE 理論。

(1) BASE理論

通用定義

BASE是Basically Available(基本可用）、Soft state(軟狀態(tài)）和Eventually consistent(最終一致性）三個(gè)短語(yǔ)的簡(jiǎn)寫。

BASE是對(duì)CAP中一致性和可用性權(quán)衡的結(jié)果，其來(lái)源于對(duì)大規(guī)模互聯(lián)網(wǎng)系統(tǒng)分布式實(shí)踐的總結(jié)，是基于CAP定理逐步演化而來(lái)的，其核心思想是即使無(wú)法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆椒▉?lái)使系統(tǒng)達(dá)到最終一致性。

兩個(gè)對(duì)沖理念：ACID和BASE

ACID是傳統(tǒng)數(shù)據(jù)庫(kù)常用的設(shè)計(jì)理念，追求強(qiáng)一致性模型。

BASE支持的是大型分布式系統(tǒng)，提出通過犧牲強(qiáng)一致性獲得高可用性。

(2) Basically Available(基本可用)

實(shí)際上就是兩個(gè)妥協(xié)。

• 對(duì)響應(yīng)上時(shí)間的妥協(xié)：正常情況下，一個(gè)在線搜索引擎需要在0.5秒之內(nèi)返回給用戶相應(yīng)的查詢結(jié)果，但由于出現(xiàn)故障（比如系統(tǒng)部分機(jī)房發(fā)生斷電或斷網(wǎng)故障），查詢結(jié)果的響應(yīng)時(shí)間增加到了1~2秒。

• 對(duì)功能損失的妥協(xié)：正常情況下，在一個(gè)電子商務(wù)網(wǎng)站（比如淘寶）上購(gòu)物，消費(fèi)者幾乎能夠順利地完成每一筆訂單。但在一些節(jié)日大促購(gòu)物高峰的時(shí)候（比如雙十一、雙十二），由于消費(fèi)者的購(gòu)物行為激增，為了保護(hù)系統(tǒng)的穩(wěn)定性（或者保證一致性），部分消費(fèi)者可能會(huì)被引導(dǎo)到一個(gè)降級(jí)頁(yè)面，如下：

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

• 原子性（硬狀態(tài)） -> 要求多個(gè)節(jié)點(diǎn)的數(shù)據(jù)副本都是一致的,這是一種"硬狀態(tài)"

• 軟狀態(tài)（弱狀態(tài)） -> 允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài),并認(rèn)為該狀態(tài)不影響系統(tǒng)的整體可用性,即允許系統(tǒng)在多個(gè)不同節(jié)點(diǎn)的數(shù)據(jù)副本存在數(shù)據(jù)延遲。

(4) Eventually consistent（最終一致性）

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

稍微官方一點(diǎn)的說(shuō)法就是：

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

(5) BASE總結(jié)

總的來(lái)說(shuō)，BASE 理論面向的是大型高可用可擴(kuò)展的分布式系統(tǒng)，和傳統(tǒng)事務(wù)的 ACID 是相反的，它完全不同于 ACID 的強(qiáng)一致性模型，而是通過犧牲強(qiáng)一致性來(lái)獲得可用性，并允許數(shù)據(jù)在一段時(shí)間是不一致的。

參考：

https://blog.csdn.net/weixin_44062339/article/details/99710968

https://blog.csdn.net/w372426096/article/details/80437198

https://www.solves.com.cn/it/cxkf/bk/2019-09-24/5229.html

http://www.itdecent.cn/p/46b90dfc7c90

http://www.itdecent.cn/p/9cb2a6fa4e0e

http://www.itdecent.cn/p/68c7c16b3fbd

---

關(guān)于作者：

mail: danbing.at@gmail.com
github: https://github.com/aceld
原創(chuàng)書籍: https://www.kancloud.cn/@aceld

---

文章推薦

開源軟件作品

(原創(chuàng)開源)Zinx-基于Golang輕量級(jí)服務(wù)器并發(fā)框架-完整版(附教程視頻)

(原創(chuàng)開源)Lars-基于C++負(fù)載均衡遠(yuǎn)程調(diào)度系統(tǒng)-完整版

精選文章

典藏版-Golang調(diào)度器GMP原理與調(diào)度全分析

Golang三色標(biāo)記、混合寫屏障GC模式圖文全分析

最常用的調(diào)試 golang 的 bug 以及性能問題的實(shí)踐方法？

Golang中的Defer必掌握的7知識(shí)點(diǎn)

Golang中的局部變量“何時(shí)棧?何時(shí)堆?”

使用Golang的interface接口設(shè)計(jì)原則

流？I/O操作？阻塞？epoll?

深入淺出Golang的協(xié)程池設(shè)計(jì)

Go語(yǔ)言構(gòu)建微服務(wù)一站式解決方案

---