TCC 模式需要用戶根據自己的業務場景實現 Try、Confirm 和 Cancel 三個操作；事務發起方在一階段 執行 Try 方式，在二階段提交執行 Confirm 方法，二階段回滾執行 Cancel 方法  TCC 三個方法描述： * Try：資源的檢測和預留； * Confirm：執行的業務操作提交；要求 Try 成功 Confirm 一定要能成功； * Cancel：預留資源釋放。 **業務模型分 2 階段設計：** 用戶接入 TCC ，最重要的是考慮如何將自己的業務模型拆成兩階段來實現。 以“扣錢”場景為例，在接入 TCC 前，對 A 賬戶的扣錢，只需一條更新賬戶余額的 SQL 便能完成；但是在接入 TCC 之后，用戶就需要考慮如何將原來一步就能完成的扣錢操作，拆成兩階段，實現成三個方法，并且保證一階段 Try? 成功的話 二階段 Confirm 一定能成功  Try 方法作為一階段準備方法，需要做資源的檢查和預留。在扣錢場景下，Try 要做的事情是就是檢查賬戶余額是否充足，預留轉賬資金，預留的方式就是凍結 A 賬戶的 轉賬資金。Try 方法執行之后，賬號 A 余額雖然還是 100，但是其中 30 元已經被凍結了，不能被其他事務使用。 二階段 Confirm 方法執行真正的扣錢操作。Confirm 會使用 Try 階段凍結的資金，執行賬號扣款。Confirm 方法執行之后，賬號 A 在一階段中凍結的 30 元已經被扣除，賬號 A 余額變成 70 元 。 如果二階段是回滾的話，就需要在 Cancel 方法內釋放一階段 Try 凍結的 30 元，使賬號 A 的回到初始狀態，100 元全部可用。 用戶接入 TCC 模式，最重要的事情就是考慮如何將業務模型拆成 2 階段，實現成 TCC 的 3 個方法，并且保證 Try 成功 Confirm 一定能成功。相對于 AT 模式，TCC 模式對業務代碼有一定的侵入性，但是 TCC 模式無 AT 模式的全局行鎖，TCC 性能會比 AT 模式高很多