章節(jié)歸屬

分布式事務(wù)系列

1、背景

伴隨著高性能的分布式系統(tǒng)演進，我們必然會經(jīng)歷 通過橫向擴展節(jié)點 提高非熱點數(shù)據(jù)的并發(fā)性能；而橫向擴展節(jié)點實際是如下2方面的擴展變化：

1. 擴展功能節(jié)點（對應(yīng)應(yīng)用的微服務(wù)化改造）
2. 擴展數(shù)據(jù)節(jié)點（對應(yīng)增加數(shù)據(jù)分片）

這些變化自然就引發(fā) 原來調(diào)用一個服務(wù)的一個接口就完成的功能，現(xiàn)在需要協(xié)同調(diào)用多個服務(wù)的多個接口才能完成。相信我們都遇到過因網(wǎng)絡(luò)、機器、程序等不可靠，引發(fā)的數(shù)據(jù)一致性的問題。而數(shù)據(jù)的一致性與系統(tǒng)的可擴展性和高可用同樣重要 是【基礎(chǔ)IT架構(gòu)】支撐業(yè)務(wù)高質(zhì)量轉(zhuǎn)型升級的重點也是難點。從螞蟻金服的分布事務(wù)產(chǎn)品十幾年的Roadmap可以看出其在數(shù)據(jù)一致性方面的堅持和不易（如今能快速使用他們的積累，幸甚至哉?。?，如下圖所示：

image.png

從官宣得知，螞蟻金服從微服務(wù)演進開始至今，大量的應(yīng)用采用了TCC事務(wù)模型，可能也是得益于：

1. TCC模式關(guān)注功能擴展，在按照功能橫向擴展資源時，解決微服務(wù)間調(diào)用的一致性問題，保證多資源訪問的事務(wù)屬性。

2. 在早期沒有現(xiàn)成成熟的分布式框架的條件下，其事務(wù)模型運轉(zhuǎn)在業(yè)務(wù)層，不依賴底層數(shù)據(jù)資源的事務(wù)支持，能靈活應(yīng)對服務(wù)的拆分。

3. 也可能跟2007年TCC概念的提出有重大關(guān)聯(lián)

2、起源

TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年發(fā)表的一篇名為《Life beyond Distributed Transactions:an Apostate’s Opinion》的論文提出。

3、核心思想

其核心思想是是：通過對資源進行預(yù)留，盡量減少對資源的鎖定時間；如果事務(wù)提交則完成對預(yù)留資源的確認(rèn)；如果事務(wù)回滾，則釋放預(yù)留的資源。

4、角色和職責(zé)

4.1、服務(wù)實現(xiàn)3個方法

根據(jù)自己的業(yè)務(wù)場景服務(wù)實現(xiàn)3個自定義的方法，把服務(wù)納入到全局事務(wù)的管理中，3個方法概述如下：

1. Try 方法：嘗試執(zhí)行；完成所有業(yè)務(wù)檢查（一致性）, 預(yù)留必須業(yè)務(wù)資源（準(zhǔn)隔離性）。

2. Confirm 方法：確認(rèn)執(zhí)行真正執(zhí)行業(yè)務(wù)，不作任何業(yè)務(wù)檢查，只使用 Try 階段預(yù)留的業(yè)務(wù)資源，只要try成功，那么confirm就必須成功；Confirm 操作要求具備冪等設(shè)計，Confirm 失敗后需要進行重試。

3. Cancel 方法：取消執(zhí)行，釋放 Try 階段預(yù)留的業(yè)務(wù)資源。Cancel 階段的異常和 Confirm 階段異常處理方案基本上一致，要求滿足冪等設(shè)計。

4.2、角色

Seata的實現(xiàn)中有3個重要角色

image.png

TC (Transaction Coordinator) - 事務(wù)協(xié)調(diào)者

維護全局和分支事務(wù)的狀態(tài)，驅(qū)動全局事務(wù)提交或回滾。

TM (Transaction Manager) - 事務(wù)管理器（發(fā)起方）

定義全局事務(wù)的范圍：開始全局事務(wù)、提交或回滾全局事務(wù)。

RM (Resource Manager) - 資源管理器（參與者）

提供TCC服務(wù)，與TC交談以注冊分支事務(wù)和報告分支事務(wù)的狀態(tài)，并驅(qū)動分支事務(wù)提交或回滾。

4.3、二階段的職責(zé)分工

image.png

1. 第一階段：
   要求服務(wù)提供方RM必須接受一些不確定因素，在1階段所提供的邏輯操作是臨時性的操作（try操作），調(diào)用方TM保留了后續(xù)取消這些操作的權(quán)利。

2. 第二階段：

   • 如果調(diào)用方?jīng)Q策認(rèn)為整個事務(wù)應(yīng)該回滾，會要求取消之前的臨時性操作,對應(yīng)的是提供方的的Cancel操作。
   • 如果調(diào)用方?jīng)Q策認(rèn)為整個事務(wù)應(yīng)該提交，會放棄取消的權(quán)利，對應(yīng)的是提供方的Confirm操作。

如轉(zhuǎn)賬作為例子，通常會在Try里面凍結(jié)金額，但不扣款，Confirm里面扣款，Cancel里面解凍金額：

image.png

5、工作原理

5.1、整體架構(gòu)

Seata-TCC模式整體架構(gòu)如下圖所示：

image.png

5.2、核心流程

Seata 框架管控整個事務(wù)，業(yè)務(wù)只需要主動調(diào) Try 方法；TM 負(fù)責(zé)2件事情：1.發(fā)起全局事務(wù)，2.提交或回滾全局事務(wù)到 TC，然后TC 負(fù)責(zé)調(diào)用Confirm或Cancel的事（包括重試）；核心流程如下:

image.png

1. TM發(fā)起全局事務(wù)
2. TM調(diào)用分支事務(wù)RM的try方法
3. RM在Try 執(zhí)行前注冊分支事務(wù)到 TC
4. RM在Try 執(zhí)行完后，上報事務(wù)狀態(tài)給 TC
5. TM通知TC進行全局事務(wù)的提交或回滾
6. TC調(diào)度，執(zhí)行分支事務(wù)RM的 Confirm 或 Cancel

5.3、注意事項

1. 空回滾

• 場景：Try 未執(zhí)行，Cancel 執(zhí)行了
• 原因：Try超時（丟包）了
• 解決：當(dāng) TC 發(fā)現(xiàn)少了一個 Try，那它就會回滾整個分布式事務(wù)，于是觸發(fā)了 Cancel，直接 Cancel 可能出現(xiàn)數(shù)據(jù)一致性問題，所以就要記錄 Try 是否執(zhí)行，沒執(zhí)行就要做空回滾（啥都不做直接返回成功）。

2. 防懸掛

• 場景：Cancel 比 Try 先執(zhí)行
• 原因：Try超時（阻塞）了
• 解決：當(dāng) TC 發(fā)現(xiàn)少了一個 Try，那它就會回滾整個分布式事務(wù)，于是觸發(fā)了 Cancel，然后擁堵的 Try 在 Cancel 處理完（空回滾）又來了，這時同樣要記錄下整個狀態(tài)，要拒絕空回滾以后的 Try

3. 冪等控制

• 現(xiàn)象：超時重試、補償都會導(dǎo)致 TCC 服務(wù)的 Try、Confirm 或 Cancel 操作被重復(fù)執(zhí)行
• 解決：Confirm 和 Cancel 開發(fā)時要考慮冪等控制（這是必須要做的）

6、總結(jié)

概括來看，該模式有以下幾個特點:

1. 該模式對代碼的嵌入性高，開發(fā)工作較多，要求每個業(yè)務(wù)需要寫TCC三步驟的操作。

2. 無論有沒有本地事務(wù)控制都可以使用該模式，與底層數(shù)據(jù)庫事務(wù)實現(xiàn)不相關(guān)，這個事務(wù)模式是抽象的基于服務(wù)層的概念，無論DB層是否有JDBC支持，即使沒有JDBC的支持如redis、mongo、es等，只要將對他們的操作包裝成TCC的參與者，就可以接入到TCC的事務(wù)范圍內(nèi)。

3. 并發(fā)度高，無需長期資源鎖定，但并發(fā)問題、數(shù)據(jù)的一致性問題，需由開發(fā)者自行根據(jù)業(yè)務(wù)場景控制，開發(fā)要求高、難度偏大。

4. 適用于訂單類業(yè)務(wù)，可以有中間狀態(tài)，但對中間狀態(tài)有約束的業(yè)務(wù)。

5. 提供了更多的靈活性，因為是業(yè)務(wù)自主定義實現(xiàn)，用戶可以借助2階段的提交過程，容易實現(xiàn)在特定場景下的自定義優(yōu)化和特殊功能開發(fā)。這個模式幾乎能滿足任何想要的事務(wù)場景，自定義補償性，自定義資源預(yù)留型事務(wù)，消息事務(wù)等場景。

參考

6.0 柔性事務(wù) ：TCC兩階段補償型
分布式事務(wù)，阿里為什么鐘愛TCC
Seata-TCC模式 原理
第三篇-分布式事務(wù)之Seata-TCC和Saga模式