概述SAGA
SAGA是1987 Hector & Kenneth 發表的論文，主要是解決長事務執行的問題。有的系統比較舊同時也需要長事物，不能改造，那么比較適用這種場景處理，還有金融行業比較適合用這種事務，主要也是流程會比較長。
SAGA的執行方式
SAGA是兩層執行的，事物按流程T1,T2,,,TN。那么與之對應的就是C1,C2,,,CN。也就是由N個分布式事務組織，同時也有N個回滾事務與之對應。如下圖，3個服務，A,B,C，這3個服務是按順序執行的，如果B事務執行失敗了，那么就會執行B事務的回滾操作。
當事務執行的時間比較長的話，那么需要與之對應的回滾服務。
存在的問題
我們舉個轉賬的例子吧，A賬戶向B賬戶進行轉賬，A、B賬戶各100元，B賬戶需要+50元，A賬戶需要-50元，這個時候假如有兩個不同的銀行，那么會有兩個服務。當B賬戶增加了50元的時候，A賬戶還沒有-50元，也就意味着，此時已經將B賬戶增加增加好了，事務已經執行成功了。我們還需要執行回滾操作，將B賬戶增加的錢減回去。
因為金融行業，可以多出來錢，不能少錢，因為錢少了就找不回來了這種特性，所以在設計的時候需要先將賬戶加錢。
再一個SAGA只允許兩層嵌套，因為流程已經很長了，嵌套多了在深度和性能上都不允許。
重試機制
還是如上例子，當A賬戶轉賬完了之后，往B賬戶轉賬失敗了，那么需要將失敗的情況記錄下來。並且服務需要設計成冪等的，這個時候有個程序來檢查任務，然后再進行重試，重試次數多了也不會對結果造成影響。
重試可以采用指數形式進行，且重試到一定次數的時候將進行預警，然后人工介入。
SAGA VS TCC
- TCC采用的中間的狀態進行的數據存儲，中間如果有數據查詢的話不會影響結果。而SAGA會直接將事務進行提交，沒有中間的結果。整個事務執行完了之后可能對結果造成變化。
- TCC需要編寫try,confirm,cancel三個服務的邏輯，這樣代碼會非常多。但是因為邏輯代碼可以控制且中間態也不影響結果，處理速度會比較快，高並發執行效率高，深受互聯網歡迎。而SAGA對業務的侵入會較低，通過注解的方式可以
- 流程較長的時候需要采用SAGA，業務流程長，業務流程復雜，當針對舊代碼不能改造成分布式事務的代碼可以選擇SAGA。TCC比較適合流程少，對實時結果要求比較高，高並發的場景比較適合。
實現SAGA的框架
支持SAGA的有 seata, Easytransaction。