在電商領域等互聯網場景下，傳統的事務在資料庫性能和處理能力上都暴露出了瓶頸，在分布式領域基于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
參考檔案
分布式事務之柔性事務
柔性事務 ：TCC兩階段補償型
本文最先發布至微信公眾號，著作權所有，禁止轉載！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/351911.html
標籤：Java