事務 - Saga模式

時間 2019-12-07

原文原文鏈接

Saga

1987年普林斯頓大學的Hector Garcia-Molina和Kenneth Salem發表了一篇Paper Sagas，講述的是如何處理long lived transaction（長活事務）。聽起來是否是以爲和分佈式事務很像？沒錯，下面來看看這個來自1987年的解決方案是如何啓發當今的分佈式事務問題的。github

協議介紹

Saga的組成：apache

每一個Saga由一系列sub-transaction T_i 組成
每一個T_i 都有對應的補償動做C_i，補償動做用於撤銷T_i形成的結果

能夠看到，和TCC相比，Saga沒有「預留」動做，它的T_i就是直接提交到庫。segmentfault

Saga的執行順序有兩種：分佈式

T₁, T₂, T₃, ..., T_n
T₁, T₂, ..., T_j, C_j,..., C₂, C₁，其中0 < j < n

Saga定義了兩種恢復策略：中間件

backward recovery，向後恢復，即上面提到的第二種執行順序，其中j是發生錯誤的sub-transaction，這種作法的效果是撤銷掉以前全部成功的sub-transation，使得整個Saga的執行結果撤銷。
forward recovery，向前恢復，適用於必需要成功的場景，執行順序是相似於這樣的：T₁, T₂, ..., T_j(失敗), T_j(重試),..., T_n，其中j是發生錯誤的sub-transaction。該狀況下不須要C_i。

對於ACID的保證

Saga對於ACID的保證和TCC同樣：接口

A，正常狀況下保證。
C，在某個時間點，會出現A庫和B庫的數據違反一致性要求的狀況，可是最終是一致的。
I，在某個時間點，A事務可以讀到B事務部分提交的結果。
D，和本地事務同樣，只要commit則數據被持久。

和TCC對比

Saga相比TCC的缺點是缺乏預留動做，致使補償動做的實現比較麻煩：T_i就是commit，好比一個業務是發送郵件，在TCC模式下，先保存草稿（Try）再發送（Confirm），撤銷的話直接刪除草稿（Cancel）就好了。而Saga則就直接發送郵件了（T_i），若是要撤銷則得再發送一份郵件說明撤銷（C_i），實現起來有一些麻煩。事務

若是把上面的發郵件的例子換成：A服務在完成T_i後當即發送Event到ESB（企業服務總線，能夠認爲是一個消息中間件），下游服務監聽到這個Event作本身的一些工做而後再發送Event到ESB，若是A服務執行補償動做C_i，那麼整個補償動做的層級就很深。ci

不過沒有預留動做也能夠認爲是優勢：資源

有些業務很簡單，套用TCC須要修改原來的業務邏輯，而Saga只須要添加一個補償動做就好了。
TCC最少通訊次數爲2n，而Saga爲n（n=sub-transaction的數量）。
有些第三方服務沒有Try接口，TCC模式實現起來就比較tricky了，而Saga則很簡單。
沒有預留動做就意味着沒必要擔憂資源釋放的問題，異常處理起來也更簡單（請對比Saga的恢復策略和TCC的異常處理）。

實現Saga的注意事項

對於服務來講，實現Saga有如下這些要求：

T_i和C_i是冪等的。
C_i必須是可以成功的，若是沒法成功則須要人工介入。
T_i - C_i和C_i - T_i的執行結果必須是同樣的：sub-transaction被撤銷了。

第一點要求T_i和C_i是冪等的，舉個例子，假設在執行T_i的時候超時了，此時咱們是不知道執行結果的，若是採用forward recovery策略就會再次發送T_i，那麼就有可能出現T_i被執行了兩次，因此要求T_i冪等。若是採用backward recovery策略就會發送C_i，而若是C_i也超時了，就會嘗試再次發送C_i，那麼就有可能出現C_i被執行兩次，因此要求C_i冪等。