柔性事務解決方案：TCC
實現
一個完整的業務活動由一個主業務服務與若干從業務服務組成
主業務服務負責發起並完成整個業務活動
從業務服務提供TCC型業務操作
業務活動管理器控制業務活動的一致性，它登記業務活動中的操作， 並在
業務活動提交時確認所有的TCC型操作的confirm操作，在業務活動取消
時調用所有TCC型操作的cancel操作
成本
實現TCC操作的成本
業務活動結束時confirm或cancel操作的執行成本
業務活動日誌成本
適用範圍
強隔離性、嚴格一致性要求的業務活動
適用於執行時間較短的業務（比如處理賬戶、收費等業務）
用到的服務模式
TCC操作、冪等操作、可補償操作、可查詢操作
方案特點
不與具體的服務框架耦合（在RPC架構中通用）
位於業務服務層，而非資源層
可以靈活選擇業務資源的鎖定粒度
TCC事務注意事項
1、業務操作分兩階段完成：
接入 TCC 前，業務操作只需要一步就能完成。但是在接入 TCC 之後，需要考慮如何將其分成兩個階段完成：把資源的檢查和預留放在一階段的 Try 操作中進行，把真正的業務操作的執行放在二階段的 Confirm 操作中進行。
以下舉例說明業務模式如何分成兩階段進行設計，舉例場景：“賬戶 A 的餘額中有 100 元，需要扣除其中 30 元”。
在接入 TCC 之前，用戶編寫 SQL：“update 賬戶表 set 餘額 = 餘額 -20 where 賬戶 = A”，便能一步完成扣款操作。
在接入 TCC 之後，就需要考慮如何將扣款操作分成兩步完成：
Try 操作：資源的檢查和預留。
在扣款場景，Try 操作要做的事情就是先檢查 A 賬戶餘額是否足夠，再凍結要扣款的 30 元（預留資源）；此階段不會發生真正的扣款。
Confirm 操作：執行真正業務的提交。
在扣款場景下，Confirm 階段做的事情就是發生真正的扣款，把 A 賬戶中已經凍結的 30 元錢扣掉。
Cancel 操作：預留資源的釋放。
在扣款場景下，扣款取消，Cancel 操作執行的任務是釋放 Try 操作凍結的 30 元錢，使 A 賬戶回到初始狀態。
2、併發控制
用戶在實現 TCC 時，應當考慮併發性問題，將鎖的粒度降到最低，以最大限度提高分佈式事務的併發性。
以下還是以 A 賬戶扣款爲例，“賬戶 A 上有 100 元，事務 T1 要扣除其中的 30 元，事務 T2 也要扣除 30 元，出現併發”。
在一階段 Try 操作中，分佈式事務 T1 和分佈式事務 T2 分別凍結資金的那一部分資金，相互之間無干擾。這樣在分佈式事務的二階段，無論 T1 是提交還是回滾，都不會對 T2 產生影響，這樣 T1 和 T2 可以在同一筆業務數據上並行執行。
3、允許空回滾
如下圖所示，事務協調器在調用 TCC 服務的一階段 Try 操作時，可能會出現因爲丟包而導致的網絡超時。此時事務管理器會觸發二階段回滾，調用 TCC 服務的 Cancel 操作，而 Cancel 操作調用未出現超時。
TCC 服務在未收到 Try 請求的情況下收到 Cancel 請求，這種場景被稱爲空回滾。空回滾在生產環境經常出現，用戶在實現 TCC 服務時，應允許空回滾的執行，即收到空回滾時返回成功。
4、防懸掛控制
如下圖所示，事務協調器在調用 TCC 服務的一階段 Try 操作時，可能會出現因網絡擁堵而導致的超時。此時事務管理器會觸發二階段回滾，調用 TCC 服務的 Cancel 操作，Cancel 調用未超時。在此之後，擁堵在網絡上的一階段 Try 數據包被 TCC 服務收到，出現二階段 Cancel 請求比一階段 Try 請求先執行的情況，此 TCC 服務在執行晚到的 Try 之後，將永遠不會再收到二階段的 Confirm 或者 Cancel，造成 TCC 服務懸掛。
用戶在實現 TCC 服務時，要允許空回滾，但是要拒絕執行空回滾之後 Try 請求，要避免出現懸掛。
5、冪等控制
無論是網絡數據包重傳，還是異常事務的補償執行，都會導致 TCC 服務的 Try、Confirm 或者 Cancel 操作被重複執行；用戶在實現 TCC 服務時，需要考慮冪等控制，即 Try、Confirm、Cancel 執行一次和執行多次的業務結果是一樣的。
1、所有的參與者都需要實現三個方法
2、事務活動管理器