在電商領域等互聯網場景下，傳統的事務在數據庫性能和處理能力上都暴露出了瓶頸。在分布式領域基於CAP理論以及BASE理論，有人就提出了柔性事務的概念。在業內，關於柔性事務，最主要的有以下四種類型：兩階段型、補償型、異步確保型、最大努力通知型幾種。我們前邊講過的2PC和3PC都屬於兩階段型，兩階段型事務存在長期鎖定資源的情況，導致可用性差。接下來我們來介紹的TCC則是補償型分布式事務。
TCC
TCC 事務介紹
TCC方案是可能是目前最火的一種柔性事務方案了。關於TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland於2007年發表的一篇名為《Life beyond Distributed Transactions:an Apostate’s Opinion》的論文提出。在該論文中，TCC還是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作為名稱的是Atomikos公司，其注冊了TCC商標。國內最早關於TCC的報道，應該是InfoQ上對阿里程立博士的一篇采訪。經過程博士的這一次傳道之后，TCC在國內逐漸被大家廣為了解並接受。
TCC將事務提交分為Try-Confirm-Cancel 3個操作。
- Try：預留業務資源/數據效驗；
- Confirm：確認執行業務操作；
- Cancel：取消執行業務操作。
TCC事務處理流程和 2PC 二階段提交類似，不過2PC通常都是在跨庫的DB層面，而TCC本質就是一個應用層面的2PC，如下為TCC原理圖。
TCC示例
假設用戶下單操作來自3個系統下單系統、資金賬戶系統、紅包賬戶系統，下單成功需要同時調用資金賬戶服務和紅包服務完成支付
假設購買商品1000元，使用賬戶紅包200元，余額800元，確認支付。
Try操作
- tryX 下單系統創建待支付訂單
- tryY 凍結賬戶紅包200元
- tryZ 凍結資金賬戶800元
Confirm操作
- confirmX 訂單更新為支付成功
- confirmY 扣減賬戶紅包200元
- confirmZ 扣減資金賬戶800元
Cancel操作
- cancelX 訂單處理異常，資金紅包退回，訂單支付失敗
- cancelY 凍結紅包失敗，賬戶余額退回，訂單支付失敗
- cancelZ 凍結余額失敗，賬戶紅包退回，訂單支付失敗
TCC事務的優缺點：
優點：XA兩階段提交資源層面的，而TCC實際上把資源層面二階段提交上提到了業務層面來實現。有效了的避免了XA兩階段提交占用資源鎖時間過長導致的性能地下問題。
缺點：主業務服務和從業務服務都需要進行改造，從業務方改造成本更高。以上文中的訂單服務為例，2PC中只需要提供一個下單接口即可，而TCC中缺需要提供Try-Confirm-Cancel三個接口，大大增加了開發量。
TCC變種
國內廠商在TCC實戰中，提出了三種TCC變種實現：
- 通用型TCC，如果我們上面介紹的TCC模型實例，從業務服務需要提供try、confirm、cancel
- 補償性TCC，從業務服務只需要提供Do和Compensate兩個接口
- 異步確保型TCC，主業務服務的直接從業務服務是可靠消息服務，而真正的從業務服務則通過消息服務解耦，作為消息服務的消費端，異步地執行。
2PC實現分布式事務分為准備階段和提交階段，2PC的關鍵是在准備階段，在這個階段所有參與者必須完成約束檢查，達成關於分布式事務一致性的共識。第二階段，根據之前達成的共識，完成相應的操作。提交事務的過程中需要在很多個資源節點之間進行協調，而且每個節點對鎖資源的釋放必須等到事務最終提交的時候。這樣兩階段事務提交會耗費更長的時間。事務執行時間長意味着鎖資源發生沖突的概率增加，當事務的並發量積累到一定數量的時候，很可能出現事務積壓甚至出現死鎖。系統的性能和吞吐量就會下降。
而柔性事務(遵循BASE理論)放棄了隔離性，減小了事務中鎖的粒度，使得應用能夠更好的利用數據庫的並發性能，實現吞吐量的線性擴展。異步執行方式可以更好的適應分布式環境，在網絡抖動、節點故障的情況下能夠盡量保障服務的可用性 (Availability)。因此在高可用、高性能的應用場景，柔性事務是最佳的選擇。
我是御狐神，歡迎大家關注我的微信公眾號:wzm2zsd
參考文檔
本文最先發布至微信公眾號，版權所有，禁止轉載！