Sagas的業務實現邏輯是什么

今天就跟大家聊聊有關Sagas的業務實現邏輯是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

在上圖中，TDB會有兩個表。也就是說，事務補償能夠成功實現，主要靠TDB中的這兩張表！：

• 事務狀態表（記錄事務組狀態；txid、state、timestap）、

• 事務調用組表（記錄事務組中每一次調用和相關參數；txid、actionid、callmethod、pramatype、params）。
  

接下來，我們介紹上面兩個表每個字段的含義：txid是主鍵、state表示事務狀態（例如：1開始 2成功  3失敗  4補償成功 ）、actionid是操作次數的id、callmethod是補償接口、調用服務的類型（如web/RPC）、params是具體數據包的調度參數。

而事務補償，就是當事務調用失敗，事務攔截器修改事務組狀態（state）。然后由TM發起，分布式事務補償服務異步執行補償。

上面的內容比較抽象，我們結合場景進行說明，還是以下圖為例。

大魏在京東購物，這是一個分布式事務。這個時候，proxy生成事務組表的一行數據，并且記錄（t1代表分布式事務1）：

接下來，要正式干活兒了。Proxy記錄事務A的調用信息，寫入事務組表：

記錄完畢后，A做本地事務：

A執行成功后，Proxy用類似的方式管理B，以此類推C。

Proxy在事務調用表中記錄B的調用內容：

B本地事務執行：

Proxy在事務調用表中記錄C的調用內容：

然后C執行。

當C本地事務執行成功后，Proxy將會修改TDB中的信息：

修改前：

修改后：

也就是說，標記分布式事務執行成功。

但是，如果在上面的步驟中，C執行失敗呢？

首先，Proxy會將TDB中的事務組表進行如下修改，將狀態從1開始修改為3失敗：

修改前：

修改后：

接下來，Schedule（即TM）會掃描到（定期掃描）t1失敗（狀態為3）。然后Schedule發現T1在事務調用表有2個關聯的本地事務（C做失敗已經自動rollback）

接下來，根據事務調用表中的pramatype字段，RPC Client調用補償接口，對事務進行補償。

先補償B：

再補償A：

最后，補償完畢后，proxy修改TBD中的事務組表，將state從3改成4，代表補償成功。

我們上述邏輯，結合業務邏輯組件進行結合。這次我們把業務邏輯模塊換一下。京東購物，選中貨物后，庫存會被鎖住（A）、然后支付的時候，會選擇紅包或者京東卡，會有減紅包或減京東卡余額的操作（C）、最后成功創建訂單（C）。

具體參考下圖：

總結：在本文中，我們介紹了Saga的業務實現邏輯。關于Proxy的作用：

Proxy的實現，在Java中是通過@around實現的。

• 交易業務邏輯層加注解，SpringBoot可以基于@tx（可以和@around協同工作）和@Transactional（通過攔截器TransactionInterceptor實現）。

• Proxy 作為攔截器，它在真正業務邏輯被調用之前 , 生成一 個全局唯一TXID 標示事務組， TXID 保存在全局變量里，  事前攔截器寫入，并向 TDB 寫入 TXID 并把事務組置為開始狀態，完成業務操作后清除 TXID 標 識.

• 交易業務邏輯層調用數據訪問前，通過 RPCProxy代理記錄當前調用請求上下文參數。

• 如果業務成功，調用記錄刪除

• 如果調用異常，根據記錄反向補償

看完上述內容，你們對Sagas的業務實現邏輯是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。