在電商領域等網際網路場景下，傳統的事務在資料庫效能和處理能力上都暴露出了瓶頸。在分散式領域基於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
參考文件
本文最先發布至微信公眾號，版權所有，禁止轉載！