引言

隨著業(yè)務(wù)量的不斷增長，單體架構(gòu)漸漸扛不住巨大的流量，此時(shí)就需要對服務(wù)進(jìn)行 拆分 ，數(shù)據(jù)庫、表做 分庫分表 處理。以訂單系統(tǒng)為例，也就產(chǎn)生了訂單中心、用戶中心、庫存中心等，由此帶來的問題就是業(yè)務(wù)間相互隔離，每個(gè)業(yè)務(wù)都維護(hù)著自己的數(shù)據(jù)庫，數(shù)據(jù)的交換只能進(jìn)行 RPC 調(diào)用。

當(dāng)用戶再次下單時(shí)，需同時(shí)對訂單庫 order、庫存庫 storage、用戶庫 account 進(jìn)行操作，可此時(shí)我們只能保證自己本地的數(shù)據(jù)一致性，無法保證調(diào)用其他服務(wù)的操作是否成功，所以為了保證整個(gè)下單流程的數(shù)據(jù)一致性，就需要分布式事務(wù)介入。

分布式事務(wù)方案一覽

實(shí)現(xiàn)分布式事務(wù)的方案比較多，常見的比如基于 XA 協(xié)議的 2PC、3PC，基于業(yè)務(wù)層的 TCC，還有應(yīng)用消息隊(duì)列 + 消息表實(shí)現(xiàn)的最終一致性方案。

• 2PC

基于 XA 協(xié)議實(shí)現(xiàn)的分布式事務(wù)，XA 協(xié)議中分為兩部分：事務(wù)管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫實(shí)現(xiàn)，比如 Oracle、MYSQL 這些數(shù)據(jù)庫都實(shí)現(xiàn)了 XA 接口，而事務(wù)管理器則作為一個(gè)全局的調(diào)度者。

兩階段提交（2PC），對業(yè)務(wù)侵?很小，它最?的優(yōu)勢就是對使??透明，用戶可以像使?本地事務(wù)?樣使?基于 XA 協(xié)議的分布式事務(wù)，能夠嚴(yán)格保障事務(wù) ACID 特性。

2PC的缺點(diǎn)也是顯而易見，它是一個(gè)強(qiáng)一致性的同步阻塞協(xié)議，事務(wù)執(zhí)?過程中需要將所需資源全部鎖定，也就是俗稱的 剛性事務(wù)。所以它比較適?于執(zhí)?時(shí)間確定的短事務(wù)，整體性能比較差。

一旦事務(wù)協(xié)調(diào)者宕機(jī)或者發(fā)生網(wǎng)絡(luò)抖動(dòng)，會(huì)讓參與者一直處于鎖定資源的狀態(tài)或者只有一部分參與者提交成功，導(dǎo)致數(shù)據(jù)的不一致。因此，在?并發(fā)性能?上的場景中，基于 XA 協(xié)議的分布式事務(wù)并不是最佳選擇。

• 3PC

三段提交（3PC）是二階段提交（2PC）的一種改進(jìn)版本 ，為解決兩階段提交協(xié)議的阻塞問題，上邊提到兩段提交，當(dāng)協(xié)調(diào)者崩潰時(shí)，參與者不能做出最后的選擇，就會(huì)一直保持阻塞鎖定資源。

2PC 中只有協(xié)調(diào)者有超時(shí)機(jī)制，3PC 在協(xié)調(diào)者和參與者中都引入了超時(shí)機(jī)制，協(xié)調(diào)者出現(xiàn)故障后，參與者就不會(huì)一直阻塞。而且在第一階段和第二階段中又插入了一個(gè)準(zhǔn)備階段（如下圖），保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

雖然 3PC 用超時(shí)機(jī)制，解決了協(xié)調(diào)者故障后參與者的阻塞問題，但與此同時(shí)卻多了一次網(wǎng)絡(luò)通信，性能上反而變得更差，也不太推薦。

• TCC

所謂的 TCC 編程模式，也是兩階段提交的一個(gè)變種，不同的是 TCC 為在業(yè)務(wù)層編寫代碼實(shí)現(xiàn)的兩階段提交。TCC 分別指 Try、Confirm、Cancel ，一個(gè)業(yè)務(wù)操作要對應(yīng)的寫這三個(gè)方法。

以下單扣庫存為例，Try 階段去占庫存，Confirm 階段則實(shí)際扣庫存，如果庫存扣減失敗 Cancel 階段進(jìn)行回滾，釋放庫存。

TCC 不存在資源阻塞的問題，因?yàn)槊總€(gè)方法都直接進(jìn)行事務(wù)的提交，一旦出現(xiàn)異常通過則 Cancel 來進(jìn)行回滾補(bǔ)償，這也就是常說的補(bǔ)償性事務(wù)。

原本一個(gè)方法，現(xiàn)在卻需要三個(gè)方法來支持，可以看到 TCC 對業(yè)務(wù)的侵入性很強(qiáng)，而且這種模式并不能很好地被復(fù)用，會(huì)導(dǎo)致開發(fā)量激增。還要考慮到網(wǎng)絡(luò)波動(dòng)等原因，為保證請求一定送達(dá)都會(huì)有重試機(jī)制，所以考慮到接口的冪等性。

• 消息事務(wù)（最終一致性）

消息事務(wù)其實(shí)就是基于消息中間件的兩階段提交，將本地事務(wù)和發(fā)消息放在同一個(gè)事務(wù)里，保證本地操作和發(fā)送消息同時(shí)成功。

下單扣庫存原理圖：

• 訂單系統(tǒng)向 MQ 發(fā)送一條預(yù)備扣減庫存消息，MQ 保存預(yù)備消息并返回成功 ACK
• 接收到預(yù)備消息執(zhí)行成功 ACK，訂單系統(tǒng)執(zhí)行本地下單操作，為防止消息發(fā)送成功而本地事務(wù)失敗，訂單系統(tǒng)會(huì)實(shí)現(xiàn) MQ 的回調(diào)接口，其內(nèi)不斷的檢查本地事務(wù)是否執(zhí)行成功，如果失敗則 rollback 回滾預(yù)備消息；成功則對消息進(jìn)行最終 commit 提交。
• 庫存系統(tǒng)消費(fèi)扣減庫存消息，執(zhí)行本地事務(wù)，如果扣減失敗，消息會(huì)重新投，一旦超出重試次數(shù)，則本地表持久化失敗消息，并啟動(dòng)定時(shí)任務(wù)做補(bǔ)償。

基于消息中間件的兩階段提交方案，通常用在高并發(fā)場景下使用，犧牲數(shù)據(jù)的強(qiáng)一致性換取性能的大幅提升，不過實(shí)現(xiàn)這種方式的成本和復(fù)雜度是比較高的，還要看實(shí)際業(yè)務(wù)情況。

基于RokectMQ實(shí)現(xiàn)最終一致性具體實(shí)現(xiàn)可參考：訂單系統(tǒng)中的數(shù)據(jù)一致性方案及RocketMQ事務(wù)消息詳解

分布式事務(wù)Seata

Seata 也是從兩段提交演變而來的一種分布式事務(wù)解決方案，提供了 AT、TCC、SAGA 和 XA 等事務(wù)模式。

• XA模式：強(qiáng)一致性分階段事務(wù)模式，犧牲了一定的可用性，無業(yè)務(wù)侵入
• TCC模式：最終一致的分階段事務(wù)模式，有業(yè)務(wù)侵入
• AT模式：最終一致的分階段事務(wù)模式，無業(yè)務(wù)侵入，也是Seata的默認(rèn)模式
• SAGA模式：長事務(wù)模式，有業(yè)務(wù)侵入

Seata事務(wù)管理中有三個(gè)重要的角色：

• TC (Transaction Coordinator) - 事務(wù)協(xié)調(diào)者：維護(hù)全局和分支事務(wù)的狀態(tài)，協(xié)調(diào)全局事務(wù)提交或回滾。
• TM (Transaction Manager) - 事務(wù)管理器：定義全局事務(wù)的范圍、開始全局事務(wù)、提交或回滾全局事務(wù)。
• RM (Resource Manager) - 資源管理器：管理分支事務(wù)處理的資源，與TC交談以注冊分支事務(wù)和報(bào)告分支事務(wù)的狀態(tài)，并驅(qū)動(dòng)分支事務(wù)提交或回滾。

Seata實(shí)現(xiàn)原理

（1）XA模式

seata的XA模式做了一些調(diào)整，但大體相似：

RM一階段的工作：

• 注冊分支事務(wù)到TC
• 執(zhí)行分支業(yè)務(wù)sql但不提交
• 報(bào)告執(zhí)行狀態(tài)到TC

TC二階段的工作：

• TC檢測各分支事務(wù)執(zhí)行狀態(tài)：如果都成功，通知所有RM提交事務(wù)；如果有失敗，通知所有RM回滾事務(wù)

RM二階段的工作：

• 接收TC指令，提交或回滾事務(wù)

XA模式

【XA模式實(shí)現(xiàn)】

Seata的starter已經(jīng)完成了XA模式的自動(dòng)裝配，實(shí)現(xiàn)非常簡單，步驟如下：

1、修改application.yml文件，開啟XA模式：

seata:
	data-source-proxy-mode: XA # 開啟數(shù)據(jù)源代理的XA模式

2、給發(fā)起全局事務(wù)的入口方法添加@GlobalTransactional注解，

@GlobalTransactional
public Long create(Order order) {    
    // 創(chuàng)建訂單    
    orderMapper.insert(order);    
    // 扣余額 ...略 
    // 扣減庫存 ...略    
    return order.getId();
}

（2）AT模式

AT模式同樣是分階段提交的事務(wù)模型，但缺彌補(bǔ)了XA模型中資源鎖定周期過長的缺陷。

階段一RM的工作：

• 注冊分支事務(wù)
• 記錄undo-log（數(shù)據(jù)快照）
• 執(zhí)行業(yè)務(wù)sql并提交
• 報(bào)告事務(wù)狀態(tài)

階段二提交時(shí)RM的工作：

• 刪除undo-log即可

階段二回滾時(shí)RM的工作：

• 根據(jù)undo-log恢復(fù)數(shù)據(jù)到更新前

AT模式

執(zhí)行流程如下：

（3）TCC模式

TCC模式與AT模式非常相似，每階段都是獨(dú)立事務(wù)，不同的是TCC通過人工編碼來實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。需要實(shí)現(xiàn)三個(gè)方法：

• Try：資源的檢測和預(yù)留；
• Confirm：完成資源操作業(yè)務(wù)；要求 Try 成功 Confirm 一定要能成功。
• Cancel：預(yù)留資源釋放，可以理解為try的反向操作。

TCC的工作模型圖：

TCC模式

【TCC的空回滾和業(yè)務(wù)懸掛】

當(dāng)某分支事務(wù)的try階段阻塞時(shí)，可能導(dǎo)致全局事務(wù)超時(shí)而觸發(fā)二階段的cancel操作。在未執(zhí)行try操作時(shí)先執(zhí)行了cancel操作，這時(shí)cancel不能做回滾，就是空回滾。

對于已經(jīng)空回滾的業(yè)務(wù)，如果以后繼續(xù)執(zhí)行try，就永遠(yuǎn)不可能confirm或cancel，這就是業(yè)務(wù)懸掛。應(yīng)當(dāng)阻止執(zhí)行空回滾后的try操作，避免懸掛。

（4）Saga模式

Saga模式是SEATA提供的長事務(wù)解決方案。也分為兩個(gè)階段：

• 一階段：直接提交本地事務(wù)
• 二階段：成功則什么都不做；失敗則通過編寫補(bǔ)償業(yè)務(wù)來回滾

Saga模式優(yōu)點(diǎn)：

• 事務(wù)參與者可以基于事件驅(qū)動(dòng)實(shí)現(xiàn)異步調(diào)用，吞吐高
• 一階段直接提交事務(wù)，無鎖，性能好
• 不用編寫TCC中的三個(gè)階段，實(shí)現(xiàn)簡單

缺點(diǎn)：

• 軟狀態(tài)持續(xù)時(shí)間不確定，時(shí)效性差
• 沒有鎖，沒有事務(wù)隔離，會(huì)有臟寫

（5）模式對比

參考&感謝

https://www.cnblogs.com/chengxy-nds/p/14046856.html