ACID、CAP、BASE的概念是什么

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

1 案例背景

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

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

這種場景代碼實現并不難，我們只要利用數據庫事務特性，就可以保證兩張數據表要么同時成功，要么同時失敗：

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

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

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

2 理論知識

2.1 ACID

傳統數據事務具有四大特性：原子性，一致性，隔離性，持久性，這些特性首字母組合在一起簡稱ACID特性。

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

(1) 原子性

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

(2) 一致性

數據庫系統在運行過程中發生故障，有些事務尚未完成就被迫中斷，如果這些事務有一部分修改已經寫入數據庫，那么數據庫就處在不一致狀態，這種情況不能被允許

(3) 隔離性

事務之間相互隔離，一個事務執行不能被其它事務干擾

(4) 持久性

當事務執行成功后，對數據庫的修改將會永遠保留在數據庫。即使數據庫出現故障，只要數據庫能夠重新啟動，一定可以恢復到事務成功結束狀態

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

2.2 CAP

1998年加州大學計算機科學家Eric Brewer提出分布式系統有三個指標，這三個指標首字母組合在一起稱為CAP理論。

一致性（Consistency）可用性（Availability）分區容錯性（Partition tolerance）

(1) 分區容錯性

在分布式系統中不同節點（服務器）一般部署在不同子網絡中，每一個子網絡被稱為一個區，不同子網絡在網絡通信時可能會失敗，我們需要接受這種情況

(2) 可用性

只要收到用戶請求，服務器就必須給出響應，用戶在訪問數據時必須得到及時響應

(3) 一致性

在分布式系統中同一個數據可能在不同節點保存多份，當更新操作成功并返回客戶端完成后，所有節點（服務器）在同一時間數據必須完全一致

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

假設CAP都滿足則一定滿足C假設CAP都滿足則一定滿足P因為滿足C則節點間數據傳遞不能有網絡故障第三點與第二點矛盾，證明完畢

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

2.3 BASE

BASE理論擴展自CAP理論，核心思想是既然無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當方式來使系統達到最終一致性，這個理論也是我們分布式事務方案的理論基礎。BASE由三個短語組成：

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

(1) 基本可用

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

(2) 柔性狀態

CAP理論一致性這個指標不允許出現中間狀態，所有狀態必須保證強一致性。但是柔性狀態可以允許短時間節點間不一致狀態出現

(3) 最終一致

既然節點間存在短時間不一致狀態，那么在一段時間后通過業務手段，節點間狀態需要最終達成一致。分布式實踐中不追求強一致性，而追求最終一致性

3 事務性消息實踐

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

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

本章節就把事務性消息這個方案講透，還是使用訂單系統和支付系統這個案例。

3.1 場景一

假設你是支付團隊成員，訂單系統由訂單團隊維護。訂單團隊愿意配合你們做系統改造，那么可以使用如下事務性消息架構圖：

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

當保存成功事務性消息后，發送事務性消息進入消息隊列。訂單系統通過消息隊列訂閱到這個消息后，把對應訂單狀態設置為已支付，同時調用支付系統接口將這條消息設置為「已處理」，整個正向流程就結束了。

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

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

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

我們還要設置一個最大重試次數，假設重試十次后仍然不成功，那么系統要將消息設置為「已過期」，同時發送告警并進行人工干預。事務性消息場景一般不會像傳統事務方式出現異常時發生回滾，而是通過重試繼續進行鏈路，或者進行人工干預。

3.2 場景二

假設你是支付團隊成員，訂單系統由訂單團隊維護。訂單系統只是通過暴露接口的方式對外進行交互，沒有時間配合改造系統為監聽消息模式。面對這種場景我們就需要對場景一架構圖進行改造，但是核心思想不變。

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

當調用處理訂單業務接口失敗或者無響應，消息狀態仍然為「待處理」。定時補償器定時將之前一段時間，狀態為「待處理」的消息再次調用處理訂單業務接口，這需要訂單系統保證冪等性。

如果訂單系統沒有保證冪等性，在再次調用處理訂單業務接口時，需要先查詢訂單接口是否已經處理過，明確返回未處理時才進行調用，否則放棄本次補償調用，等待再次重試，補償重試策略與場景一相同。

4 RocketMQ

如果使用RocketMQ消息中間件，可以直接使用其事務消息機制，通過發送half消息、提交或回滾half消息、定時業務回查也可以實現最終一致性。

到此，相信大家對“ACID、CAP、BASE的概念是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！