分佈式架構設計篇(八)-柔性事務之TCC詳解

                                                                                          -     起源     -

TCC概念由Pat Helland於2007年發表的一篇名爲《Life beyond Distributed Transactions:an Apostate’s Opinion》的論文提出, 在該論文中，TCC仍是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel做爲名稱的是Atomikos公司，而且還註冊了TCC商標。國內最先可查引進TCC概念，應是阿里程立2008年在 軟件開發2.0大會 上分享主題《大規模SOA系統中的分佈事務處理》中。

Atomikos公司在商業版本事務管理器ExtremeTransactions中提供了TCC方案的實現，可是因爲其是收費的，所以相應的不少的開源實現方案也就涌現出來，如：ByteTCC、Himly、TCC-transaction。可是筆者都不推薦使用，下文會詳細說明。

                                                                                          -     組成     -

TCC 是一種補償型事務，該模型要求應用的每一個服務提供 try、confirm、cancel 三個接口，它的核心思想是經過對資源的預留(提供中間態，如帳戶狀態、凍結金額等)，儘早釋放對資源的加鎖，若是事務能夠提交，則完成對預留資源的確認，若是事務要回滾，則釋放預留的資源。

TCC模型徹底交由業務實現，每一個子業務都須要實現Try-Confirm-Cancel三個接口，對業務侵入大，資源鎖定交由業務方。

1. Try：嘗試執行業務，完成全部業務檢查(一致性)，預留必要的業務資源(準隔離性)。
2. Confirm：確認執行業務，再也不作業務檢查。只使用Try階段預留的業務資源，Confirm操做知足冪等性。
3. Cancel：取消執行業務釋放Try階段預留業務資源。

一個完整的業務活動由一個主業務服務與若干子業務服務組成：

1. 主業務服務負責發起並完成整個業務活動
2. 業務服務提供TCC型業務操做。
3. 業務活動管理器控制業務活動的一致性，它登記業務活動中的操做，並在業務活動提交時確認全部的TCC型操做的Confirm操做，在業務活動取消時調用全部TCC型操做的Cancel操做。

成本：

1. 實現TCC操做的成本
2. 業務活動結束時Confirm或Cancel操做的執行成本。在Confirm和Cancel範圍內的操做成功性須要框架來保證，只能一直重試保證資源被消耗或者釋放。
3. 業務活動日誌成本

適用範圍：

1. 強隔離性、嚴格一致性要求的業務活動
2. 適用於執行時間較短的業務

                                                                                 -     TCC與2PC對比     -

TCC將事務提交劃分紅兩個階段，Try即爲一階段，Confirm 和 Cancel 是二階段並行的兩個分支，二選一。從階段劃分上很是像2PC，咱們是否能夠說TCC是一種2PC或者2PC變種呢？其實不能夠，緣由以下：

1. 2PC的操做對象在於資源層，對於開發人員無感知；而TCC的操做在於業務層，具備較高開發成本。
2. 2PC是一個總體的長事務，也是剛性事務；而TCC是一組的本地短事務，是柔性事務。
3. 2PC的Prepare(表決階段)進行了操做表決；而TCC的try並無表決準備，直接兼備資源操做與準備能力
4. 2PC是全局鎖定資源，全部參與者阻塞 交互等待TM通知；而TCC的資源鎖定在於Try操做，業務方能夠靈活選擇業務資源的鎖定粒度。

                                                                                  -     TCC注意事項     -

TCC爲了解決網絡不可靠引發的異常狀況，要求業務方在設計上要遵循三個策略：

1. 容許空回滾：緣由是異常發生在階段一時，部分參與方沒有收到 Try 請求從而觸發整個事務的Cancel 操做；Try 失敗或者沒有執行 Try 操做的參與方收到 Cancel 請求時，要進行空回滾操做。
2. 保持冪等性：緣由是異常發生在階段二時，好比網絡超時，則會重複調用參與方的 Confirm/Cancel 方法，所以Confirm/Cancel方法必須保證冪等性。
3. 防止資源懸掛：緣由網絡異常致使兩個階段沒法保證嚴格的順序執行，出現參與方側 Try 請求比 Cancel 請求更晚到達的狀況，Cancel 會執行空回滾而確保事務的正確性，可是此時 Try 方法也不能夠再被執行。

                                                                                          -     案例     -

匯款服務、收款服務案例：A用戶向B用戶匯款500元。

                                                                                          -     總結    -

由於TCC對業務的強侵入性，使用成本很是昂貴，雖然提供了更靈活的資源鎖粒度，對標2PC擁有更高的吞吐量。可是相對於2PC的強一致性來講，TCC的實施成本和數據一致性的犧牲帶來的相對高吞吐量，整體表現出來的性價比很是低，反而在市面上成熟的大型企業中幾乎沒有使用。

                                                                                      -     做者介紹    -

孫玄

畢業於浙江大學，奈學教育創始人兼CEO，前轉轉公司技術委員會主席，前58集團技術委員會主席，前百度資深研發工程師，騰訊雲TVP，阿里雲MVP，在線直播大課《百萬架構師》品牌創始人。

林淮川

畢業於西安交通大學；奈學教育《百萬架構師訓練營》講師及企業級源碼內源負責人，前大樹金融高級架構師；前大樹金融技術委員會開創者；前大樹金融供應鏈金融技術總監；前天陽宏業交易事業部技術主管；多年互聯網金融行業（ToB）經驗。