分散式事物SAGA

• 2021 年 10 月 21 日
• 筆記

概述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。