本文主要介紹 seata-go 中 TCC 的設(shè)計(jì)思路、異常處理以及在實(shí)戰(zhàn)中的使用。

Seata 是一款開源的分布式事務(wù)解決方案，致力于為現(xiàn)代化微服務(wù)架構(gòu)下的分布式事務(wù)提供高性能和簡(jiǎn)單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 等多種事務(wù)模式，幫助用戶解決不同場(chǎng)景下的業(yè)務(wù)問題。同時(shí)，Seata 還支持多語言編程，并且提供了簡(jiǎn)易的 API 接口、豐富的文檔以及快速上手的 samples 示例項(xiàng)目，也能快速幫助開發(fā)者入門并上手 Seata 的使用。

Seata-go 是 Seata 多語言生態(tài)中 golang 語言的實(shí)現(xiàn)方案，它致力于幫助 golang 開發(fā)者也能使用 Seata 的能力來解決分布式事務(wù)場(chǎng)景的問題。Seata-go 復(fù)用了 Seata TC 的能力，client 的功能和 Seata 保持一致。目前 Seata-go 已經(jīng)支持了 TCC 和 AT 模式，XA 模式正在測(cè)試中，預(yù)計(jì)會(huì)在 5 月份發(fā)版。Saga 模式正在設(shè)計(jì)和規(guī)劃中，后面也會(huì)和 Seata 的 Saga 功能保持一致。

本文主要從以下幾個(gè)角度，介紹 Seata-go 中的 TCC 模式的設(shè)計(jì)與使用：

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

Sata-go TCC 異常處理

Seata-go 的展望

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

Seata-go 采用了 getty 做 TCP 網(wǎng)絡(luò)通信，完全實(shí)現(xiàn)了 Seata 的通信協(xié)議。下層實(shí)現(xiàn)了配置中心和注冊(cè)中心，也支持了很多的第三方框架的接入，比如 dubbo、grpc、gorm 等等，目前也正在積極和各個(gè)社區(qū)溝通，以支持更多框架的接入。Seata-go 簡(jiǎn)易的系統(tǒng)架構(gòu)圖如下：

先來簡(jiǎn)單回顧下 TCC 模式的含義。TCC 是分布式事務(wù)方案的一種實(shí)現(xiàn)，它采用了二階段提交協(xié)議，TCC 的全稱是 Try-Confirm-Cancel，Try 是預(yù)留資源操作，Confirm 是提交操作，Cancel 是回滾操作。在 TCC 的一階段中，先觸發(fā)所有的子事務(wù)執(zhí)行 Try 操作，如果所有的子事務(wù)的一階段都執(zhí)行成功，那么會(huì)觸發(fā)所有子事務(wù)二階段執(zhí)行 Confirm 操作，否則二階段執(zhí)行 Cancel 操作，以此來保證各個(gè)子事務(wù)狀態(tài)的一致性。

TCC 是一種侵入式的分布式事務(wù)方案，Try、Confirm 和 Cancel 三個(gè)階段的邏輯，都需要用戶自己去實(shí)現(xiàn)。這樣做意味著更多的代碼量，以及對(duì)業(yè)務(wù)很大的入侵性；而優(yōu)點(diǎn)是則比較靈活，能由用戶隨意發(fā)揮以解決更復(fù)雜的分布式事務(wù)場(chǎng)景的問題。

在介紹 Seata-go 的 TCC 模式之前，先來回顧下 Seata 中的三個(gè)核心角色，即 TC、TM 和 RM。TC 是事務(wù)協(xié)調(diào)者，負(fù)責(zé)維護(hù)全局事務(wù)的狀態(tài)，以及觸發(fā)分支事務(wù)的提交和回滾動(dòng)作；TM 是事務(wù)管理器，負(fù)責(zé)子事務(wù)的編排，以及全局事務(wù)的提交和回滾動(dòng)作；RM 是資源管理器，管理分支事務(wù)處理的資源，比如 MySQL 數(shù)據(jù)庫的操作等。

了解了這三個(gè)核心角色，就可以大致的理解下 TCC 的事務(wù)流程，大致分為以下幾個(gè)步驟：

• TM 向 TC 發(fā)送請(qǐng)求，開啟全局事務(wù)，TC 側(cè)記錄下全局事務(wù)的狀態(tài)信息；
• TM 分別向所有的 RM 發(fā)送請(qǐng)求，RM 會(huì)向 TC 注冊(cè)分支事務(wù)，然后執(zhí)行 Try 階段的邏輯；
• 如果當(dāng)中某個(gè) RM 給 TM 返回 Try 階段執(zhí)行失敗，那 TM 就向 TC 發(fā)送“回滾全局事務(wù)” 的請(qǐng)求。TC 收到后，就會(huì)向所有已執(zhí)行 Try 的 RM 發(fā)送 Rollback 指令，觸發(fā) RM 執(zhí)行 Cancel 邏輯；
• 如果所有的 RM 都給 TM 返回 Try 階段執(zhí)行成功，那 TM 就向 TC 發(fā)送“提交全局事務(wù)” 的請(qǐng)求。TC 收到后，就會(huì)向所有已執(zhí)行 Try 的 RM 發(fā)送 Commit 指令，觸發(fā) RM 執(zhí)行 Commit 邏輯。

至此，一個(gè)完整的分布式事務(wù)就執(zhí)行完了，以下是這個(gè)過程的流程圖：

在 Seata-go 中，為了方便用戶使用，提供了兩種定義 TCC 服務(wù)方法，一種是實(shí)現(xiàn) TwoPhaseInterface 接口，具體如下：

另一種是通過 tag 的方式來定義 TCC 服務(wù)，這種方式會(huì)相對(duì)復(fù)雜點(diǎn)，但是也更加的靈活：

第二種 tag 的方案，主要是為了滿足一些特殊的場(chǎng)景，比如說，dubbo-go 的 server 和 client 是使用 tag 的方式來定義的，這個(gè)時(shí)候就需要使用 tag 的方式來定義 TCC 的服務(wù)。一般情況推薦使用第一種繼承接口的方式來做，比較簡(jiǎn)單。

在實(shí)際使用的時(shí)候，用戶只需要做以下幾件事情即可：

• 定義好自己的 TCC 服務(wù)，可以參考上面介紹的這兩種方式之一都可以；
• 調(diào)用 TCC 的代理方法 NewTCCServiceProxy ，將 TCC 服務(wù)的封裝成代理；
• 編排好自己的子事務(wù)，傳入到分布式事務(wù)的入口方法 WithGlobalTx 方法即可。

這里截圖給大家看個(gè)例子，更詳細(xì)的 samples 請(qǐng)參考 seata-go-samples 項(xiàng)目，地址為：

https://github.com/seata/seata-go-samples

Seata-go TCC 異常處理

在實(shí)際使用 TCC 的時(shí)候，由于網(wǎng)絡(luò)或是業(yè)務(wù)代碼邏輯執(zhí)行時(shí)間等因素，可能會(huì)出現(xiàn)以下的問題：

• 冪等：在事務(wù)的一、二階段，由于網(wǎng)絡(luò)延遲或是其他原因，RM 沒有及時(shí)給 TC 或 TM 響應(yīng)，導(dǎo)致 RM 被重復(fù)觸發(fā)執(zhí)行一、二階段的邏輯，這個(gè)時(shí)候，需要考慮業(yè)務(wù)的冪等；
• 空回滾：由于網(wǎng)絡(luò)延遲或是其他原因，RM 在未收到 Try 請(qǐng)求的情況下，卻收到了 Rollback 請(qǐng)求，造成空回滾的問題；
• 懸掛：由于網(wǎng)絡(luò)延遲或是其他原因，RM 在未收到 Try 請(qǐng)求的情況下，收到了 Rollback 請(qǐng)求，處理完 Rollback 請(qǐng)求后，又收到了 Try 請(qǐng)求。這時(shí)全局事務(wù)已結(jié)束，會(huì)導(dǎo)致事務(wù)預(yù)留的資源一直無法釋放。

在 Seata-go 中，提供了兩種解決方案，來幫助用戶解決這個(gè)問題。

第一種方式的原理和 Seata Java 的處理邏輯是一樣的，都是借助 tcc_fence_log 事務(wù)狀態(tài)表來做的：

用戶需要在自己的業(yè)務(wù)數(shù)據(jù)庫中，創(chuàng)建這個(gè)表，RM 在提交業(yè)務(wù) SQL 的時(shí)候，同時(shí)會(huì)在這個(gè)表里面插入一條記錄，這倆 SQL 是在一個(gè)本地事務(wù)中完成的。由于這個(gè)表中，“全局事務(wù)ID+分支事務(wù)ID”是一個(gè)聯(lián)合主鍵，導(dǎo)致重復(fù)執(zhí)行時(shí)會(huì)失敗，這樣就解決了 Try 階段的冪等問題。在 Commit 和 Cancel 階段時(shí)，會(huì)先查詢這個(gè)表中分支事務(wù)的狀態(tài)，然后才進(jìn)行實(shí)際的邏輯，最后再更新狀態(tài)。這樣也能保證 Commit 和 Cancel 階段的冪等性。

再來看看 Seata-go 是如何解決事務(wù)懸掛和空回滾的問題。假如一個(gè) Rollbback 請(qǐng)求過來，RM 去查詢 tcc_fence_log 表，發(fā)現(xiàn)沒有記錄（因?yàn)?RM 尚未收到 Try 請(qǐng)求），此時(shí)會(huì)往 tcc_fence_log 表插入一條記錄，并標(biāo)記狀態(tài)為 suspend，然后直接退出，而不會(huì)去執(zhí)行 Rollback 的邏輯，這樣就避免了空回滾的問題。如果 RM 后面再收到 Try 請(qǐng)求，由于 tcc_fence_log 表已經(jīng)有一條記錄，就會(huì)導(dǎo)致事務(wù) SQL 無法提交而失敗（tcc_fence_log 會(huì)出現(xiàn)主鍵沖突的問題），這樣就避免了防懸掛的問題。

要實(shí)現(xiàn)這種方式，需要使用 Seata-go 提供的代理數(shù)據(jù)源，這些操作都會(huì)由代理數(shù)據(jù)源來完成，用戶只需要開啟開關(guān)，關(guān)注自己的業(yè)務(wù) SQL 即可，這個(gè)功能已經(jīng)實(shí)現(xiàn)，會(huì)在后續(xù)進(jìn)行發(fā)版。

第二種方式，是通過用戶手動(dòng)的方式來實(shí)現(xiàn)的。原理和上面類似，但是 tcc_fence_log 的操作邏輯需要由用戶自己實(shí)現(xiàn)，下面的截圖描述了大致的使用方式，詳情可以參考這個(gè) samples 代碼：

https://github.com/seata/seata-go-samples/tree/main/tcc/fence

Seata-go 展望

Seata-go 社區(qū)近期與不少國內(nèi) go 語言微服務(wù)框架以及 ORM 框架背后的開發(fā)社區(qū)達(dá)成合作，比如 GORM 框架，已經(jīng)集成到了 Sample 中，后續(xù)會(huì)將更多的 ORM 框架集成在 Seata-go-Samples 項(xiàng)目中。與 MOSN 社區(qū)的合作也在推進(jìn)中，可實(shí)現(xiàn)真正的基于 Seata 的 Transaction Mesh。

Seata-go 的 XA 模式會(huì)在5月份進(jìn)行發(fā)版，屆時(shí) Seata-go 將支持 TCC、XA 和 AT 三種事務(wù)模式。Seata-go 后續(xù)的中心將會(huì)在 Saga 模式功能的開發(fā)上。

當(dāng)前的 Saga 模式僅實(shí)現(xiàn)了服務(wù)編排的正向推進(jìn)與反向 Rollback 能力，更進(jìn)一步的服務(wù)編排則可以實(shí)現(xiàn) DAG、定時(shí)任務(wù)、任務(wù)批量調(diào)度，覆蓋工作流的所有流程，提升用戶在 Seata 這個(gè)平臺(tái)上的使用體驗(yàn)。目前 Seata-go 依賴于 Seata Java 的 TC，按照這個(gè)工作計(jì)劃，可能需要在未來的 Seata-go 版本中實(shí)現(xiàn)一個(gè)功能更強(qiáng)大的 TC 調(diào)度。