章節(jié)歸屬
1、背景
伴隨著高性能的分布式系統(tǒng)演進，我們必然會經(jīng)歷 通過橫向擴展節(jié)點 提高非熱點數(shù)據(jù)的并發(fā)性能杜秸；而橫向擴展節(jié)點實際是如下2方面的擴展變化：
- 擴展功能節(jié)點（對應(yīng)應(yīng)用的微服務(wù)化改造）
- 擴展數(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ù)一致性方面的堅持和不易（如今能快速使用他們的積累稼钩，幸甚至哉！）达罗，如下圖所示：
從官宣得知坝撑，螞蟻金服從微服務(wù)演進開始至今，大量的應(yīng)用采用了TCC事務(wù)模型粮揉，可能也是得益于：
TCC模式關(guān)注功能擴展巡李，在按照功能橫向擴展資源時，解決微服務(wù)間調(diào)用的一致性問題扶认，保證多資源訪問的事務(wù)屬性侨拦。
在早期沒有現(xiàn)成成熟的分布式框架的條件下，其事務(wù)模型運轉(zhuǎn)在業(yè)務(wù)層辐宾，不依賴底層數(shù)據(jù)資源的事務(wù)支持狱从，能靈活應(yīng)對服務(wù)的拆分。
也可能跟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ù)留資源的確認持偏；如果事務(wù)回滾驼卖，則釋放預(yù)留的資源。
4鸿秆、角色和職責(zé)
4.1酌畜、服務(wù)實現(xiàn)3個方法
根據(jù)自己的業(yè)務(wù)場景服務(wù)實現(xiàn)3個自定義的方法，把服務(wù)納入到全局事務(wù)的管理中谬莹，3個方法概述如下：
Try 方法：嘗試執(zhí)行檩奠；完成所有業(yè)務(wù)檢查（一致性）, 預(yù)留必須業(yè)務(wù)資源（準隔離性）桩了。
Confirm 方法：確認執(zhí)行真正執(zhí)行業(yè)務(wù)，不作任何業(yè)務(wù)檢查埠戳，只使用 Try 階段預(yù)留的業(yè)務(wù)資源井誉，只要try成功，那么confirm就必須成功整胃；Confirm 操作要求具備冪等設(shè)計颗圣，Confirm 失敗后需要進行重試。
Cancel 方法：取消執(zhí)行屁使，釋放 Try 階段預(yù)留的業(yè)務(wù)資源在岂。Cancel 階段的異常和 Confirm 階段異常處理方案基本上一致，要求滿足冪等設(shè)計蛮寂。
4.2蔽午、角色
Seata的實現(xiàn)中有3個重要角色
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é)分工
第一階段：
要求服務(wù)提供方RM必須接受一些不確定因素僧鲁，在1階段所提供的邏輯操作是臨時性的操作（try操作），調(diào)用方TM保留了后續(xù)取消這些操作的權(quán)利象泵。-
第二階段：
- 如果調(diào)用方?jīng)Q策認為整個事務(wù)應(yīng)該回滾寞秃，會要求取消之前的臨時性操作,對應(yīng)的是提供方的的Cancel操作。
- 如果調(diào)用方?jīng)Q策認為整個事務(wù)應(yīng)該提交单芜，會放棄取消的權(quán)利蜕该，對應(yīng)的是提供方的Confirm操作。
如轉(zhuǎn)賬作為例子洲鸠，通常會在Try里面凍結(jié)金額堂淡，但不扣款，Confirm里面扣款扒腕，Cancel里面解凍金額：
5绢淀、工作原理
5.1、整體架構(gòu)
Seata-TCC模式整體架構(gòu)如下圖所示：
5.2瘾腰、核心流程
Seata 框架管控整個事務(wù)皆的，業(yè)務(wù)只需要主動調(diào) Try 方法；TM 負責(zé)2件事情：1.發(fā)起全局事務(wù)蹋盆，2.提交或回滾全局事務(wù)到 TC费薄，然后TC 負責(zé)調(diào)用Confirm或Cancel的事（包括重試）硝全；核心流程如下:
- TM發(fā)起全局事務(wù)
- TM調(diào)用分支事務(wù)RM的try方法
- RM在Try 執(zhí)行前注冊分支事務(wù)到 TC
- RM在Try 執(zhí)行完后，上報事務(wù)狀態(tài)給 TC
- TM通知TC進行全局事務(wù)的提交或回滾
- TC調(diào)度楞抡，執(zhí)行分支事務(wù)RM的 Confirm 或 Cancel
5.3伟众、注意事項
- 空回滾
- 場景：Try 未執(zhí)行，Cancel 執(zhí)行了
- 原因：Try超時（丟包）了
- 解決：當(dāng) TC 發(fā)現(xiàn)少了一個 Try召廷，那它就會回滾整個分布式事務(wù)凳厢，于是觸發(fā)了 Cancel，直接 Cancel 可能出現(xiàn)數(shù)據(jù)一致性問題竞慢，所以就要記錄 Try 是否執(zhí)行先紫，沒執(zhí)行就要做空回滾（啥都不做直接返回成功）。
- 防懸掛
- 場景：Cancel 比 Try 先執(zhí)行
- 原因：Try超時（阻塞）了
- 解決：當(dāng) TC 發(fā)現(xiàn)少了一個 Try筹煮，那它就會回滾整個分布式事務(wù)遮精，于是觸發(fā)了 Cancel，然后擁堵的 Try 在 Cancel 處理完（空回滾）又來了寺谤，這時同樣要記錄下整個狀態(tài)仑鸥，要拒絕空回滾以后的 Try
- 冪等控制
- 現(xiàn)象：超時重試吮播、補償都會導(dǎo)致 TCC 服務(wù)的 Try变屁、Confirm 或 Cancel 操作被重復(fù)執(zhí)行
- 解決：Confirm 和 Cancel 開發(fā)時要考慮冪等控制（這是必須要做的）
6、總結(jié)
概括來看意狠，該模式有以下幾個特點:
該模式對代碼的嵌入性高粟关，開發(fā)工作較多，要求每個業(yè)務(wù)需要寫TCC三步驟的操作环戈。
無論有沒有本地事務(wù)控制都可以使用該模式闷板，與底層數(shù)據(jù)庫事務(wù)實現(xiàn)不相關(guān)，這個事務(wù)模式是抽象的基于服務(wù)層的概念院塞，無論DB層是否有JDBC支持遮晚，即使沒有JDBC的支持如redis、mongo拦止、es等县遣，只要將對他們的操作包裝成TCC的參與者，就可以接入到TCC的事務(wù)范圍內(nèi)汹族。
并發(fā)度高萧求，無需長期資源鎖定，但并發(fā)問題顶瞒、數(shù)據(jù)的一致性問題夸政，需由開發(fā)者自行根據(jù)業(yè)務(wù)場景控制，開發(fā)要求高榴徐、難度偏大守问。
適用于訂單類業(yè)務(wù)匀归，可以有中間狀態(tài)，但對中間狀態(tài)有約束的業(yè)務(wù)耗帕。
提供了更多的靈活性朋譬，因為是業(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模式
