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