前提 前端業務(主服務)可以以同步或非同步調用TCC框架,或者TCC框架本身就是同步非同步兼備的. 假定TCC框架擁有斷電後的自動恢復能力.同時,在下游業務出現無限失敗的情況下,也會進行無限的重試,以達到最終一致 正式開始 正常流程 一切安好. 可以觀察到,confirm操作完全交由TCC調用.在同步狀 ...
前提
- 前端業務(主服務)可以以同步或非同步調用TCC框架,或者TCC框架本身就是同步非同步兼備的.
- 假定TCC框架擁有斷電後的自動恢復能力.同時,在下游業務出現無限失敗的情況下,也會進行無限的重試,以達到最終一致
正式開始
正常流程
一切安好.
可以觀察到,confirm操作完全交由TCC調用.在同步狀態下,無論最終成功與失敗,可能出現前端等待時間過長的問題.
個人認為,try階段,也可以直接註冊到TCC中,並完全交由TCC框架調用,客戶端只訪問其保留的介面.
預留失敗
因下游業務或網路問題導致了預留失敗.
與正常流程相同,不過此時調用了TCC的cancel操作
總結
- 實施TCC方案時,最好在立項伊始就要做好相應的資料庫設計與介面定義方案.能在資料庫中保存"預留"數據,同時相關代碼提供"預留","確認","取消"方法的介面定義以用作實現.
- 整體來說,業務級人員減小了業務開發難度(雖然工作量變大了).同時將重心轉移到了"TCC框架"的實現.它需要保證高可用,數據安全,冪等,甚至需要能處理代碼迭代引起的版本差異的問題
- 因為設計到事物管理問題,其框架開發難度也變大了,可以使用開源框架如:
