分散式柔性事務的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的實施成本和資料一致性的犧牲帶來的相對高吞吐量，總體表現出來的價效比非常低，反而在市面上成熟的大型企業中幾乎沒有使用。

免費領取更多技術資料及影片