分散式事務及其CAP和base理論
分散式事務的概念
- 首先來說一下本地事務,它是指我們單體應用單個資料庫中的事務,在計算機系統中,更多的是通過關係型資料庫來控制事務,這是利用資料庫本身的事務特性來實現的,因此叫資料庫事務,由於應用主要靠關聯式資料庫來控制事務,所以基於關係型資料庫的事務又被稱為本地事務。
- 相對於本地事務來說,分散式系統會把一個應用系統拆分為可獨立部署的多個服務,因此需要服務與服務之間遠端協作才能完成事務操作,這種分散式系統環境下由不同的服務之間通過網路遠端協作完成事務稱之為分散式事務,例如使用者註冊送積分事務、建立訂單減庫存事務,銀行轉賬事務等都是分散式事務。
- 總的來說,無論是多個服務之間遠端協作訪問同一個資料庫,還是單體應用訪問多個資料庫,只要是有一個出現了分散式部署,就會產生分散式事務。
CAP理論
CAP定理告訴我們,分散式系統不可能同時滿足一致性(C:Consistency)、可用性(A:Availability)和分割槽容錯性(P:Partition Tolerance),最多隻能同時滿足其中兩項。
- 一致性(Consistency):對於任何從客戶端傳送到分散式系統的資料讀取請求,要麼讀到最新的資料要麼失敗。換句話說,一致性是站在分散式系統的角度,對訪問本系統的客戶端的一種承諾:要麼我給您返回一個錯誤,要麼我給你返回絕對一致的最新資料,不難看出,其強調的是資料正確。
舉例來說:使用者註冊送積分事務,其中包含2個操作一個是使用者服務的使用者資訊註冊,另外一個積分服務的積分資料修改,如果使用者註冊成功,那麼使用者在積分服務中檢視積分的時候,積分資料一定是最新的即是贈送後的,絕對不可能是舊資料。
- 可用性(A:Availability) :對於任何求從客戶端發達到分散式系統的資料讀取請求,都一定會收到資料,不會收到錯誤,但不保證客戶端收到的資料一定是最新的資料。換句話說,可用性是站在分散式系統的角度,對訪問本系統的客戶的另一種承諾:我一定會給您返回資料,不會給你返回錯誤,但不保證資料最新,強調的是不出錯。
- 分割槽容錯性(Partition tolerance)分割槽容錯性約束了一個分散式系統需要具有如下特性:分散式系統在遇到任何網路分割槽故障的時候,仍然需要能夠保證對外提供滿足一致性和可用性的服務,除非是整個網路環境都發生了故障。換句話說,分割槽容忍性是站在分散式系統的角度,對訪問本系統的客戶端的再一種承諾:我會一直執行,不管我的內部出現何種資料同步問題,強調的是不掛掉,能夠對外提供服務。
結論:從CAP定理中我們可以看出,一個分散式系統不可能同時滿足一致性、可用性和分割槽容錯性這三個需求。另一方面,需要明確的一點是,對於一個分散式系統而言,分割槽容錯性可以說是一個最基本的要求(必須要滿足的)。為什麼這樣說,其實很簡單,因為既然是一個分散式系統,那麼分散式系統中的元件必然需要被部署到不同的節點,否則也就無所謂分散式系統了,因此必然出現子網路。而對於分散式系統而言,網路問題又是一個必定會出現的異常情況,因此分割槽容錯性也就成為了一個分散式系統必然需要面對和解決的問題。因此係統架構設計師往往需要把精力花在如何根據業務特點在C(一致性)和A(可用性)之間尋求平衡。
base理論
BASE是Basically Available(基本可用)、Soft state(軟狀態)和Eventually consistent(最終一致性)三個短語的簡寫,BASE是對CAP中一致性和可用性權衡的結果,其來源於對大規模網際網路系統分散式實踐的結論,是基於CAP定理逐步演化而來的,其核心思想是即使無法做到強一致性(Strong consistency),但每個應用都可以根據自身的業務特點,採用適當的方式來使系統達到最終一致性(Eventual consistency)
通過犧牲強一致性來獲得可用性,當出現故障允許部分不可用但要保證核心功能可用,允許資料在一段時間內是不一致的,但最終達到一致狀態。滿足BASE理論的事務,我們稱之為“柔性事務”。
- 基本可用:分散式系統在出現故障時,允許損失部分可用功能,保證核心功能可用。如,電商網站交易付款出現問題了,商品依然可以正常瀏覽。
- 軟狀態:由於不要求強一致性,所以BASE允許系統中存在中間狀態(也叫軟狀態),這個狀態不影響系統可用性,可以存著延遲,如訂單的"支付中"、“資料同步中”等狀態,待資料最終一致後狀態改為“成功”狀態
- 最終一致:最終一致是指經過一段時間後,所有節點資料都將會達到一致。如訂單的"支付中"狀態,最終會變為“支付成功”或者"支付失敗",使訂單狀態與實際交易結果達成一致,但需要一定時間的延遲、等待。
結論:
ACID 要求強一致性,通常運用在傳統的資料庫系統上。而 BASE 要求最終一致性,通過犧牲強一致性來達到可用性,通常運用在大型分散式系統中。
在實際的分散式場景中,不同業務單元和元件對一致性的要求是不同的,因此 ACID 和 BASE 往往會結合在一起使用
相關文章
- 分散式必備理論基礎:CAP和BASE分散式
- 【分散式】CAP理論及其應用分散式
- 10分鐘瞭解分散式CAP、BASE理論分散式
- 分散式事務--CAP分散式
- 分散式從 ACID、CAP、BASE 的理論推進分散式
- 從分散式一致性談到CAP理論、BASE理論分散式
- Java分散式系統設計:CAP定理與BASE理論Java分散式
- 分散式理論(二) - BASE理論分散式
- 看《大明王朝1566》聊分散式中的CAP和BASE理論分散式
- 分散式理論(一) - CAP定理分散式
- 分散式系列七: 分散式事務理論分散式
- 分散式系統的 CAP 理論分散式
- 分散式設計理論之CAP分散式
- 分散式事務(2)---TCC理論分散式
- 分散式系統理論基礎 - CAP分散式
- 分散式事務理論加實戰分散式
- (1)分散式事務理論基礎分散式
- 分散式系統理論基礎2 :CAP分散式
- 分散式系統:CAP 理論的前世今生分散式
- 分散式系統之CAP理論雜記分散式
- 4 在分散式資料庫中CAP原理CAP+BASE分散式資料庫
- 分散式事務(1)---2PC和3PC理論分散式
- 分散式:分散式事務(CAP、兩階段提交、三階段提交)分散式
- Linux下分散式系統以及CAP理論分析Linux分散式
- Asp.Net Core&CAP實現分散式事務ASP.NET分散式
- 分散式事務和分散式hash分散式
- 分散式系統中的CAP、ACID、BASE概念分散式
- 架構設計 | 分散式事務①概念簡介和基礎理論架構分散式
- Laravel 分散式事務處理Laravel分散式
- 分散式事務故障處理分散式
- 分散式事務處理方案,微服事務處理方案分散式
- CAP原理和BASE思想
- 分散式事務(一)—分散式事務的概念分散式
- 分散式事務 | 使用 dotnetcore/CAP 的本地訊息表模式分散式NetCore模式
- 本地事務和分散式事務的區別分散式
- springcloud分散式事務處理 LCNSpringGCCloud分散式
- Oracle分散式事務典型案例處理Oracle分散式
- CAP原理和BASE思想(轉)