分佈式事務之TCC服務設計和實現注意事項

摘要： 一、TCC簡介 TCC是一種比較成熟的分佈式事務解決方案，可用於解決跨庫操做的數據一致性問題； TCC是服務化的兩階段編程模型，其Try、Confirm、Cancel 3個方法均由業務編碼實現； 其中Try操做做爲一階段，負責資源的檢查和預留，Confirm操做做爲二階段提交操做，執行真正的業務，...

一、TCC簡介

TCC是一種比較成熟的分佈式事務解決方案，可用於解決跨庫操做的數據一致性問題；

TCC是服務化的兩階段編程模型，其Try、Confirm、Cancel 3個方法均由業務編碼實現；

其中Try操做做爲一階段，負責資源的檢查和預留，Confirm操做做爲二階段提交操做，執行真正的業務，Cancel是預留資源的取消；

以下圖所示，業務實現TCC服務以後，該TCC服務將做爲分佈式事務的其中一個資源，參與到整個分佈式事務中；事務管理器分2階段協調TCC服務，在第一階段調用全部TCC服務的Try方法，在第二階段執行全部TCC服務的Confirm或者Cancel方法；

二、用戶在實現TCC服務時，有如下注意事項

一、業務操做分兩階段完成：
以下圖所示，接入TCC前，業務操做只須要一步就能完成，可是在接入TCC以後，須要考慮如何將其分紅2階段完成，把資源的檢查和預留放在一階段的Try操做中進行，把真正的業務操做的執行放在二階段的Confirm操做中進行；

TCC服務要保證第一階段Try操做成功以後，二階段Confirm操做必定能成功；

二、容許空回滾；

以下圖所示，事務協調器在調用TCC服務的一階段Try操做時，可能會出現由於丟包而致使的網絡超時，此時事務協調器會觸發二階段回滾，調用TCC服務的Cancel操做；

TCC服務在未收到Try請求的狀況下收到Cancel請求，這種場景被稱爲空回滾；TCC服務在實現時應當容許空回滾的執行；

三、防懸掛控制；

以下圖所示，事務協調器在調用TCC服務的一階段Try操做時，可能會出現因網絡擁堵而致使的超時，此時事務協調器會觸發二階段回滾，調用TCC服務的Cancel操做；在此以後，擁堵在網絡上的一階段Try數據包被TCC服務收到，出現了二階段Cancel請求比一階段Try請求先執行的狀況；

用戶在實現TCC服務時，應當容許空回滾，可是要拒絕執行空回滾以後到來的一階段Try請求；

四、冪等控制：

不管是網絡數據包重傳，仍是異常事務的補償執行，都會致使TCC服務的Try、Confirm或者Cancel操做被重複執行；用戶在實現TCC服務時，須要考慮冪等控制，即Try、Confirm、Cancel 執行一次和執行屢次的業務結果是同樣的；

五、業務數據可見性控制；

TCC服務的一階段Try操做會作資源的預留，在二階段操做執行以前，若是其餘事務須要讀取被預留的資源數據，那麼處於中間狀態的業務數據該如何向用戶展現，須要業務在實現時考慮清楚；一般的設計原則是「寧肯不展現、少展現，也很少展現、錯展現」；

六、業務數據併發訪問控制；

TCC服務的一階段Try操做預留資源以後，在二階段操做執行以前，預留的資源都不會被釋放；若是此時其餘分佈式事務修改這些業務資源，會出現分佈式事務的併發問題；

用戶在實現TCC服務時，須要考慮業務數據的併發控制，儘可能將邏輯鎖粒度降到最低，以最大限度的提升分佈式事務的併發性；

三、總結

螞蟻金服使用TCC有10年曆史，在TCC應用方面積累了大量實踐經驗；除了上述TCC服務的設計注意事項外，咱們在解決用戶高併發、高可用需求方面也提供瞭解決方案，咱們對分佈式事務作了極致的性能優化以支持雙11等大促的高併發需求，咱們基於螞蟻LDC架構的高可用方案能使分佈式事務服務達到99.99%的可用性；

螞蟻金服大部分業務系統均採用TCC的方式接入分佈式事務，但設計TCC服務時要遵循大量設計規範，這無疑對用戶提了很是高的要求；爲了簡化用戶接入分佈式事務的門檻，螞蟻金服的分佈式事務框架（SOFA-DTX）推出了FMT（Framework-managed transactions）模式和XA模式，這兩種模式均不須要用戶實現TCC服務，用戶只須要關注自身業務SQL即可；DTX的三種模式：TCC、FMT和XA相互之間是功能互補，相輔相成的，造成了螞蟻金服完善的分佈式事務解決方案。

SOFA-DTX全面覆蓋金融場景，金融級容災保障、提供豐富的接入模式而且使用簡潔易於接入；目前已經應用在支付寶、網上銀行、螞蟻財富、芝麻信用、南京銀行等項目中。

文章做者：紹輝

原文連接本文爲雲棲社區原創內容，未經容許不得轉載。