一、簡介

1、本地事務與分布式事務

1.1 事務

數據庫事務(簡稱：事務，Transaction)是指數據庫執?過程中的?個邏輯單位，由?個有限的數據庫操作序列構成。
事務擁有以下四個特性，習慣上被稱為ACID特性：
原?性(Atomicity)： 事務作為?個整體被執?，包含在其中的對數據庫的操作要么全部被執?，要么都不執?。
?致性(Consistency)： 事務應確保數據庫的狀態從?個?致狀態轉變為另?個?致狀態。?致狀態是指數據庫中的數據應滿?完整性約束。除此之外，?致性還有另外?層語義，就是事務的中間狀態不能被觀察到(這層語義也有說應該屬于原?性)。
隔離性(Isolation)： 多個事務并發執?時，?個事務的執?不應影響其他事務的執?，如同只有這?個操作在被數據庫所執??樣。
持久性(Durability)： 已被提交的事務對數據庫的修改應該永久保存在數據庫中。在事務結束時，此操作將不可逆轉。

1.2 本地事務

起初，事務僅限于對單?數據庫資源的訪問控制,架構服務化以后，事務的概念延伸到了服務中。倘若將?個單?的服務操作作為?個事務，那么整個服務操作只能涉及?個單?的數據庫資源,這類基于單個服務單?數據庫資源訪問的事務，被稱為本地事務(Local Transaction)。

1.3 分布式事務

? 分布式事務指事務的參與者、?持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統的不同節點之上,且屬于不同的應?，分布式事務需要保證這些操作要么全部成功，要么全部失敗。本質上來說，分布式事務就是為了保證不同數據庫的數據?致性。當?個服務操作訪問不同的數據庫資源，?希望對它們的訪問具有事務特性時，就需要采?分布式事務來協調所有的事務參與者。

下圖反映了這樣?個跨越多個服務的分布式事務：

如果將上?這兩種場景(?個服務可以調?多個數據庫資源，也可以調?其他服務)結合在?起，對此進?延伸，整個分布式事務的參與者將會組成如下圖所示的樹形拓撲結構。

2、分布式事務相關理論

2.1 CAP定理

CAP定理是在 1998年加州?學的計算機科學家 Eric Brewer （埃?克.布魯爾）提出，分布式系統有三個指標，這三個指標不可能同時做到。

• Consistency ?致性
• Availability 可?性
• Partition tolerance 分區容錯

分區容錯（Partition tolerance）

分布式系統集群中,?個機器壞掉不應該影響其他機器

?多數分布式系統都分布在多個??絡。每個??絡就叫做?個區（partition）。分區容錯的意思是，區間通信可能失敗。?如，?臺服務器放在中國，另?臺服務器放在美國，這就是兩個區，它們之間可能?法通信。

?般來說，分區容錯?法避免，因此可以認為 CAP 的 P 總是成?。CAP 定理告訴我們，剩下的 C 和 A ?法同時做到。

可?性（Availability）

只要收到?戶的請求，服務器就必須給出回應?戶可以選擇向 G1 或 G2 發起讀操作。不管是哪臺服務器，只要收到請求，就必須告訴?戶，到底是 v0 還是v1，否則就不滿?可?性。

?致性（Consistency）

?定能讀取到最新的數據

Consistency 中?叫做?致性。意思是，寫操作之后的讀操作，必須返回該值。

?致性和可?性的?盾
?致性?和可?性(A)，為什么不可能同時成?？答案很簡單，因為可能通信失敗（即出現分區容錯）。
如果保證 G2 的?致性，那么 G1 必須在寫操作時，鎖定 G2 的讀操作和寫操作。只有數據同步后，才能重新開放讀寫。鎖定期間，G2 不能讀寫，沒有可?性(CP)。
如果保證 G2 的可?性，那么勢必不能鎖定 G2，所以?致性不成?(AP)。
綜上所述，G2 ?法同時做到?致性和可?性。系統設計時只能選擇?個?標。如果追求?致性，那么?法保證所有節點的可?性；如果追求所有節點的可?性，那就沒法做到?致性。

2.2 Base理論

BASE：全稱：Basically Available(基本可?)，Soft state（軟狀態）,和 Eventually consistent（最終?致性）三個短語的縮寫，來? ebay 的架構師提出。BASE 理論是對 CAP 中?致性和可?性權衡的結果，其來源于對?型互聯?分布式實踐的總結，是基于 CAP 定理逐步演化?來的。其核?思想是：

既是?法做到強?致性（Strong consistency），但每個應?都可以根據?身的業務特點，采?適當的?式來使系統達到最終?致性（Eventual consistency）。

Basically Available(基本可?)

理解: 允許服務降級或者允許響應時間受到?定損失

什么是基本可?呢？假設系統，出現了不可預知的故障，但還是能?，相?較正常的系統??：

響應時間上的損失：正常情況下的搜索引擎 0.5 秒即返回給?戶結果，?基本可?的搜索引擎可以在 1 秒作?返回結果。

功能上的損失：在?個電商?站上，正常情況下，?戶可以順利完成每?筆訂單，但是到了?促期間，為了保護購物系統的穩定性，部分消費者可能會被引導到?個降級??。

Soft state（軟狀態）
理解: 允許同步數據的時候出現?定時間延遲
什么是軟狀態呢？相對于原?性??，要求多個節點的數據副本都是?致的，這是?種 “硬狀態”。
軟狀態指的是：允許系統中的數據存在中間狀態，并認為該狀態不影響系統的整體可?性，即允許系統在多個不同節點的數據副本存在數據延時。
Eventually consistent（最終?致性）

理解: 經過?段時間的同步數據之后，最終都能夠達到?個?致的狀態。

系統能夠保證在沒有其他新的更新操作的情況下，數據最終?定能夠達到?致的狀態，因此所有客戶端對系統的數據訪問最終都能夠獲取到最新的值。

3、分布式事務解決方案

3.1 基于XA協議的兩階段提交

可知XA規范中分布式事務有AP，RM，TM組成：

其中應?程序(Application Program ，簡稱AP)： AP定義事務邊界（定義事務開始和結束）并訪問事務邊界內的資源。

資源管理器(Resource Manager，簡稱RM)： Rm管理計算機共享的資源，許多軟件都可以去訪問這些資源，資源包含?如數據庫、?件系統、打印機服務器等。

事務管理器(Transaction Manager ，簡稱TM)： 負責管理全局事務，分配事務唯?標識，監控事務的執?進度，并負責事務的提交、回滾、失敗恢復等。

?階段協議:
第?階段TM： 要求所有的RM準備提交對應的事務分?，詢問RM是否有能?保證成功的提交事務分?，RM根據??的情況，如果判斷??進?的?作可以被提交，那就對?作內容進?持久化，并給TM回執OK；否者給TM的回執NO。RM在發送了否定答復并回滾了已經的?作后，就可以丟棄這個事務分?信息了。
第?階段TM： 根據階段1各個RM prepare的結果，決定是提交還是回滾事務。如果所有的RM都prepare成功，那么TM通知所有的RM進?提交；如果有RM prepare回執NO的話，則TM通知所有RM回滾??的事務分?。
也就是TM與RM之間是通過兩階段提交協議進?交互。

優點： 盡量保證了數據的強?致，適合對數據強?致要求很?的關鍵領域。（其實也不能100%保證強?致）
缺點： 實現復雜，犧牲了可?性，對性能影響較?，不適合?并發?性能場景。

3.2 TCC補償機制

TCC 其實就是采?的補償機制，其核?思想是：針對每個操作，都要注冊?個與其對應的確認和補償（撤銷）操作。它分為三個階段：

• Try 階段主要是對業務系統做檢測及資源預留。
• Confirm 階段主要是對業務系統做確認提交，Try階段執?成功并開始執? Confirm階段時，默認 Confirm階段是不會出錯的。即：只要Try成功，Confirm?定成功。
• Cancel 階段主要是在業務執?錯誤，需要回滾的狀態下執?的業務取消，預留資源釋放。

A要向 B 轉賬，思路?概是：

我們有?個本地?法，??依次調? 1、?先在 Try 階段，要先調?遠程接?把 B和 A的錢給凍結起來。 2、在 Confirm 階段，執?遠程調?的轉賬的操作，轉賬成功進?解凍。 3、如果第2步執?成功，那么轉賬成功，如果第?步執?失敗，則調?遠程凍結接?對應的解凍?法 (Cancel)。

優點： 相?兩階段提交，可?性?較強

缺點： 數據的?致性要差?些。TCC屬于應?層的?種補償?式，所以需要程序員在實現的時候多寫很多補償的代碼，在?些場景中，?些業務流程可能?TCC不太好定義及處理。

3.3 消息最終一致性

消息最終?致性應該是業界使?最多的，其核?思想是將分布式事務拆分成本地事務進?處理，這種思路是來源于ebay。我們可以從下?的流程圖中看出其中的?些細節：

基本思路就是：
消息?產?，需要額外建?個消息表，并記錄消息發送狀態。消息表和業務數據要在?個事務?提交，也就是說他們要在?個數據庫??。然后消息會經過MQ發送到消息的消費?。如果消息發送失敗，會進?重試發送。
消息消費?，需要處理這個消息，并完成??的業務邏輯。此時如果本地事務處理成功，表明已經處理成功了，如果處理失敗，那么就會重試執?。如果是業務上?的失敗，可以給?產?發送?個業務補償消息，通知?產?進?回滾等操作。
?產?和消費?定時掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發送?遍。如果有靠譜的?動對賬
補賬邏輯，這種?案還是?常實?的。
優點： ?種?常經典的實現，避免了分布式事務，實現了最終?致性。
缺點： 消息表會耦合到業務系統中，如果沒有封裝好的解決?案，會有很多雜活需要處理。

二、分布式事務 seata

1、簡介

Seata（原名Fescar） 是阿?18年開源的分布式事務的框架。Fescar的開源對分布式事務框架領域影響很?。作

為開源?戶，Fescar來?阿?的GTS，經歷了好?次雙??的考驗，?經開源便頗受關注。后來Fescar改名為

Seata。

Fescar雖然是?階段提交協議的分布式事務，但是其解決了XA的?些缺點:

• 單點問題： 雖然?前Fescar(0.4.2)還是單server的，但是Fescar官?預計將會在0.5.x中推出HA-Cluster，到時候就可以解決單點問題。

• 同步阻塞： Fescar的?階段，其再第?階段的時候本地事務就已經提交釋放資源了，不會像XA會再兩個prepare和commit階段資源都鎖住，并且Fescar,commit是異步操作，也是提升性能的??關鍵。

• 數據不?致： 如果出現部分commit失敗，那么fescar-server會根據當前的事務模式和分?事務的返回狀態的結果來進?不同的重試策略。并且fescar的本地事務會在?階段的時候進?提交，其實單看數據庫來說在commit的時候數據庫已經是?致的了。

• 只能?于單?數據庫： Fescar提供了兩種模式，AT和TCC。在AT模式下事務資源可以是任何?持ACID的數據庫，在TCC模式下事務資源沒有限制，可以是緩存，可以是?件，可以是其他的等等。當然這兩個模式也可以混?。

同時Fescar也保留了接近0業務?侵的優點，只需要簡單的配置Fescar的數據代理和加個注解，加?個Undolog表，就可以達到我們想要的?的。

2、實現原理

Fescar將?個本地事務做為?個分布式事務分?，所以若?個分布在不同微服務中的本地事務共同組成了?個全局事務，結構如下。

TM： 全局事務管理器，在標注開啟fescar分布式事務的服務端開啟，并將全局事務發送到TC事務控制端管理

TC： 事務控制中?，控制全局事務的提交或者回滾。這個組件需要獨?部署維護，?前只?持單機版本，后續迭代計劃會有集群版本

RM： 資源管理器，主要負責分?事務的上報，本地事務的管理

?段話簡述其實現過程：

服務起始?發起全局事務并注冊到TC。 在調?協同服務時，協同服務的事務分?事務會先完成階段?的事務提交或回滾，并?成事務回滾的undo_log?志， 同時注冊當前協同服務到TC并上報其事務狀態，歸并到同?個業務的全局事務中。 此時若沒有問題繼續下?個協同服務的調?，期間任何協同服務的分?事務回滾，都會通知到TC，TC在通知全局事務包含的所有已完成?階段提交的分?事務回滾。 如果所有分?事務都正常，最后回到全局事務發起?時，也會通知到TC，TC在通知全局事務包含的所有分?刪除回滾?志。 在這個過程中為了解決寫隔離和度隔離的問題會涉及到TC管理的全局鎖。

3、Fescar模式

Fescar對分布式事務的實現提供了2種模式，AT模式和TCC模式：

3.1 TCC模式

TCC模式： TCC補償機制，對代碼造成?定的侵?,實現難度較?，這種?式不推薦，不過TCC模式的特點是性能?。
TCC模式部分代碼如下： 可以看到執?事務回滾，都需要根據不同階段執?的狀態判斷，侵?了業務代碼。

@Override @GlobalTransactional public boolean transfer(final String from, final String to, final double amount) {//扣錢參與者，?階段執?boolean ret = firstTccAction.prepareMinus(null, from, amount);if (!ret) {//扣錢參與者，?階段失敗; 回滾本地事務和分布式事務throw new RuntimeException("賬號:[" + from + "] 預扣款失敗");}//加錢參與者，?階段執?ret = secondTccAction.prepareAdd(null, to, amount);if (!ret) {throw new RuntimeException("賬號:[" + to + "] 預收款失敗");}System.out.println(String.format("transfer amount[%s] from [%s] to [%s] finish.", String.valueOf(amount), from, to));return true; }

3.2 AT模式

AT模式： 主要關注多 DB 訪問的數據?致性，實現起來?較簡單，對業務的侵?較?，但性能沒有TCC?，這種模式推薦?家使?。
AT模式部分代碼如下： 不需要關注執?狀態，對業務代碼侵?較?。

@GlobalTransactional(timeoutMills = 300000, name = "dubbo-demo-tx") public void purchase(String userId, String commodityCode, int orderCount) {LOGGER.info("purchase begin ... xid: " + RootContext.getXID());storageService.deduct(commodityCode, orderCount);orderService.create(userId, commodityCode, orderCount);throw new RuntimeException("AT 模式發?異常，回滾事務"); }

3.3 AT 模式設計思路

AT模式的核?是對業務?侵?，是?種改進后的兩階段提交。

第一階段：

核?在于對業務sql進?解析，轉換成undolog，兩階段提交往往對資源的鎖定需要持續到第?階段實際的提交或者回滾操作，?有了回滾?志之后，可以在第?階段釋放對資源的鎖定，降低了鎖范圍，提?效率，即使第?階段發?異常需要回滾，只需找對undolog中對應數據并反解析成sql來達到回滾?的。Seata通過代理數據源將業務sql的執?解析成undolog來與業務數據的更新同時?庫，達到了對業務?侵?的效果。

第二階段：

如果決議是全局提交，此時分?事務此時已經完成提交，不需要同步協調處理（只需要異步清理回滾?志），Phase2 可以?常快速地完成。

如果決議是全局回滾，RM 收到協調器發來的回滾請求，通過 XID 和 Branch ID 找到相應的回滾?志記錄，通過回滾記錄?成反向的更新 SQL 并執?，以完成分?的回滾。

4、官方信息

官網
GitHub地址

https://seata.io/zh-cn/ https://github.com/seata/seata

5、快速開始

pom.xml

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-seata</artifactId><version>${spring-cloud-alibaba.version}</version> </dependency>

代碼：

package com.work.order.service;import com.work.order.model.Order; import io.seata.spring.annotation.GlobalTransactional; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional;import java.math.BigDecimal; @Service public class OrderService {@GlobalTransactional@Transactional(rollbackFor = Exception.class)public void placeOrder(String userId, String commodityCode, Integer count) {BigDecimal orderMoney = new BigDecimal(count).multiply(new BigDecimal(5));Order order = new Order().setUserId(userId).setCommodityCode(commodityCode).setCount(count).setMoney(orderMoney);orderDAO.insert(order);stockFeignClient.deduct(commodityCode, count);} }

總結

以上是生活随笔為你收集整理的分布式事务简介(seata)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。