ACID、CAP、BASE的概念是什么

本篇內(nèi)容主要講解“ACID、CAP、BASE的概念是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“ACID、CAP、BASE的概念是什么”吧!

1 案例背景

用戶在電商網(wǎng)站購買了一件衣服，在支付成功后，支付系統(tǒng)需要將訂單狀態(tài)改為支付完成。需要注意支付結(jié)果和訂單結(jié)果需要保持一致，不能出現(xiàn)支付成功后，訂單狀態(tài)卻修改失敗類似情況，否則用戶就會很疑惑：明明支付成功了訂單卻是待支付狀態(tài)。

對于這種要么同時成功，要么同時失敗的場景，最容易想到的是使用事務(wù)。我們假設(shè)支付表和訂單表屬于同一個數(shù)據(jù)庫。

這種場景代碼實現(xiàn)并不難，我們只要利用數(shù)據(jù)庫事務(wù)特性，就可以保證兩張數(shù)據(jù)表要么同時成功，要么同時失?。?/p>

public class PayServiceImpl implements PayService {  @Transactional  public void pay() {    updatePayInfo();    updateOrderInfo();  }}

但是在分布式場景中可沒有這么簡單。在分布式場景中訂單是由訂單團(tuán)隊維護(hù)，支付是由支付團(tuán)隊維護(hù)，所以訂單系統(tǒng)和支付系統(tǒng)根本是兩個系統(tǒng)，分別部署在不同服務(wù)器，分別提供服務(wù)，更不可能使用一個數(shù)據(jù)庫：

所以在分布式場景中上述代碼已經(jīng)不適用了，我們需要新方案。在談具體方案之前我們需要講解一些理論知識。

2 理論知識

2.1 ACID

傳統(tǒng)數(shù)據(jù)事務(wù)具有四大特性：原子性，一致性，隔離性，持久性，這些特性首字母組合在一起簡稱ACID特性。

原子性（Atomicity）一致性（Consistency）隔離性（Isolation）持久性（Durability）

(1) 原子性

一個事務(wù)要么全部提交成功，要么全部失敗回滾，不能只執(zhí)行其中一部分操作

(2) 一致性

數(shù)據(jù)庫系統(tǒng)在運行過程中發(fā)生故障，有些事務(wù)尚未完成就被迫中斷，如果這些事務(wù)有一部分修改已經(jīng)寫入數(shù)據(jù)庫，那么數(shù)據(jù)庫就處在不一致狀態(tài)，這種情況不能被允許

(3) 隔離性

事務(wù)之間相互隔離，一個事務(wù)執(zhí)行不能被其它事務(wù)干擾

(4) 持久性

當(dāng)事務(wù)執(zhí)行成功后，對數(shù)據(jù)庫的修改將會永遠(yuǎn)保留在數(shù)據(jù)庫。即使數(shù)據(jù)庫出現(xiàn)故障，只要數(shù)據(jù)庫能夠重新啟動，一定可以恢復(fù)到事務(wù)成功結(jié)束狀態(tài)

在上述電商系統(tǒng)同一個數(shù)據(jù)庫場景，正是使用了ACID這些特性才能達(dá)到我們預(yù)期業(yè)務(wù)要求。但是在分布式場景中就不再適用了，而且在分布式場景中解決分布式事務(wù)問題并不容易，這就引出了下一個概念：CAP理論。

2.2 CAP

1998年加州大學(xué)計算機(jī)科學(xué)家Eric Brewer提出分布式系統(tǒng)有三個指標(biāo)，這三個指標(biāo)首字母組合在一起稱為CAP理論。

一致性（Consistency）可用性（Availability）分區(qū)容錯性（Partition tolerance）

(1) 分區(qū)容錯性

在分布式系統(tǒng)中不同節(jié)點（服務(wù)器）一般部署在不同子網(wǎng)絡(luò)中，每一個子網(wǎng)絡(luò)被稱為一個區(qū)，不同子網(wǎng)絡(luò)在網(wǎng)絡(luò)通信時可能會失敗，我們需要接受這種情況

(2) 可用性

只要收到用戶請求，服務(wù)器就必須給出響應(yīng)，用戶在訪問數(shù)據(jù)時必須得到及時響應(yīng)

(3) 一致性

在分布式系統(tǒng)中同一個數(shù)據(jù)可能在不同節(jié)點保存多份，當(dāng)更新操作成功并返回客戶端完成后，所有節(jié)點（服務(wù)器）在同一時間數(shù)據(jù)必須完全一致

但是CAP理論三個指標(biāo)無法同時滿足，我們需要證明這個命題。我分析了很多證明文章，認(rèn)為反證法這種方法比較清晰。下面我使用反證法證明這個命題：

假設(shè)CAP都滿足則一定滿足C假設(shè)CAP都滿足則一定滿足P因為滿足C則節(jié)點間數(shù)據(jù)傳遞不能有網(wǎng)絡(luò)故障第三點與第二點矛盾，證明完畢

我們看到在分布式實踐中CAP理論有點不夠用了，這里我們就要引出下一個概念：BASE理論，這是眾多分布式實踐的指導(dǎo)理論。

2.3 BASE

BASE理論擴(kuò)展自CAP理論，核心思想是既然無法做到強(qiáng)一致性，但每個應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點，采用適當(dāng)方式來使系統(tǒng)達(dá)到最終一致性，這個理論也是我們分布式事務(wù)方案的理論基礎(chǔ)。BASE由三個短語組成：

基本可用（Basically Available）柔性狀態(tài)（Soft State）最終一致（Eventually Consistency）

(1) 基本可用

當(dāng)分布式系統(tǒng)發(fā)生故障時，允許損失部分系統(tǒng)可用性。例如電商系統(tǒng)在大促無法承受流量洪峰時，可能會將用戶引導(dǎo)至降級頁面，或者觸發(fā)服務(wù)熔斷，保證大部分用戶可用

(2) 柔性狀態(tài)

CAP理論一致性這個指標(biāo)不允許出現(xiàn)中間狀態(tài)，所有狀態(tài)必須保證強(qiáng)一致性。但是柔性狀態(tài)可以允許短時間節(jié)點間不一致狀態(tài)出現(xiàn)

(3) 最終一致

既然節(jié)點間存在短時間不一致狀態(tài)，那么在一段時間后通過業(yè)務(wù)手段，節(jié)點間狀態(tài)需要最終達(dá)成一致。分布式實踐中不追求強(qiáng)一致性，而追求最終一致性

3 事務(wù)性消息實踐

分布式事務(wù)解決方案有很多，例如兩階段提交，TCC，事務(wù)性消息。我在分布式事務(wù)實踐中最常使用事務(wù)性消息。首先我們用一個生活實例來描述什么是事務(wù)性消息。

小明去面館吃面條，有很多人在排隊。小明付過錢之后就找空位坐了下來，因為空位是隨機(jī)分布的，那么服務(wù)員怎么保證可以把面條準(zhǔn)確送到小明的桌上？答案是憑借小明手上的取餐小票。取餐小票是小明購物憑證和消費依據(jù)，有了小票就不用擔(dān)心吃不到面條。取餐小票就是事務(wù)性消息。

本章節(jié)就把事務(wù)性消息這個方案講透，還是使用訂單系統(tǒng)和支付系統(tǒng)這個案例。

3.1 場景一

假設(shè)你是支付團(tuán)隊成員，訂單系統(tǒng)由訂單團(tuán)隊維護(hù)。訂單團(tuán)隊愿意配合你們做系統(tǒng)改造，那么可以使用如下事務(wù)性消息架構(gòu)圖：

根據(jù)這張圖分析事務(wù)性消息如何工作：當(dāng)用戶支付成功后，支付系統(tǒng)將支付完成數(shù)據(jù)保存在數(shù)據(jù)庫，并且在同一個事務(wù)中新增一條消息，狀態(tài)是「待處理」。注意這個消息與支付數(shù)據(jù)保存具有強(qiáng)一致性，同時成功或者同時失敗，我們稱這種消息為事務(wù)性消息。

當(dāng)保存成功事務(wù)性消息后，發(fā)送事務(wù)性消息進(jìn)入消息隊列。訂單系統(tǒng)通過消息隊列訂閱到這個消息后，把對應(yīng)訂單狀態(tài)設(shè)置為已支付，同時調(diào)用支付系統(tǒng)接口將這條消息設(shè)置為「已處理」，整個正向流程就結(jié)束了。

但是訂單系統(tǒng)調(diào)用修改消息接口有可能失敗，也就是雖然業(yè)務(wù)處理成功了，事務(wù)性消息狀態(tài)依然是「待處理」，這時就需要定時補(bǔ)償器發(fā)揮作用了。定時補(bǔ)償器定時將之前一段時間，狀態(tài)為「待處理」的消息再次發(fā)送至消息隊列，由訂單系統(tǒng)再次訂閱處理，這需要訂單系統(tǒng)保證冪等性。

分析到這里事務(wù)性消息工作原理已經(jīng)講清楚了，但是不能就此止步。我們還要繼續(xù)分析一個問題：假設(shè)訂單系統(tǒng)很長時間一直處理不成功，導(dǎo)致消息一直「待處理」怎么辦？

出現(xiàn)這種原因可能是訂單系統(tǒng)宕機(jī)了，那么補(bǔ)償器一直頻繁重試是沒有結(jié)果的，所以我們要給消息重試一個階梯時間：第一次不成功過5分鐘重試，第二次不成功過15分鐘重試，第三次不成功30分鐘后重試，這樣可以給訂單系統(tǒng)恢復(fù)時間。

我們還要設(shè)置一個最大重試次數(shù)，假設(shè)重試十次后仍然不成功，那么系統(tǒng)要將消息設(shè)置為「已過期」，同時發(fā)送告警并進(jìn)行人工干預(yù)。事務(wù)性消息場景一般不會像傳統(tǒng)事務(wù)方式出現(xiàn)異常時發(fā)生回滾，而是通過重試?yán)^續(xù)進(jìn)行鏈路，或者進(jìn)行人工干預(yù)。

3.2 場景二

假設(shè)你是支付團(tuán)隊成員，訂單系統(tǒng)由訂單團(tuán)隊維護(hù)。訂單系統(tǒng)只是通過暴露接口的方式對外進(jìn)行交互，沒有時間配合改造系統(tǒng)為監(jiān)聽消息模式。面對這種場景我們就需要對場景一架構(gòu)圖進(jìn)行改造，但是核心思想不變。

我們根據(jù)這張圖分析事務(wù)性消息如何工作：當(dāng)用戶支付成功后，保存支付業(yè)務(wù)數(shù)據(jù)和新增消息原理和場景一相同。當(dāng)保存成功事務(wù)性消息后，直接調(diào)用處理訂單業(yè)務(wù)接口，調(diào)用成功后將這條消息設(shè)置為「已處理」，整個正向流程就結(jié)束了。

當(dāng)調(diào)用處理訂單業(yè)務(wù)接口失敗或者無響應(yīng)，消息狀態(tài)仍然為「待處理」。定時補(bǔ)償器定時將之前一段時間，狀態(tài)為「待處理」的消息再次調(diào)用處理訂單業(yè)務(wù)接口，這需要訂單系統(tǒng)保證冪等性。

如果訂單系統(tǒng)沒有保證冪等性，在再次調(diào)用處理訂單業(yè)務(wù)接口時，需要先查詢訂單接口是否已經(jīng)處理過，明確返回未處理時才進(jìn)行調(diào)用，否則放棄本次補(bǔ)償調(diào)用，等待再次重試，補(bǔ)償重試策略與場景一相同。

4 RocketMQ

如果使用RocketMQ消息中間件，可以直接使用其事務(wù)消息機(jī)制，通過發(fā)送half消息、提交或回滾half消息、定時業(yè)務(wù)回查也可以實現(xiàn)最終一致性。

到此，相信大家對“ACID、CAP、BASE的概念是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！