實時一致性

mcxiaoracle發表於2022-06-24

在 TCC 模式中，我們會把原來的一個介面分為 Try 介面、Confirm 介面、Cancel 介面。

  • Try 介面用來檢查資料、預留業務資源。

  • Confirm 介面用來確認實際業務操作、更新業務資源。

  • Cancel 介面是指釋放 Try 介面中預留的資源。

實時一致性


所以 TCC 模式是一個很麻煩的方案，除了每個業務程式碼的工作量 X3 之外，出錯的機率也高，因為我們需要透過相應邏輯保證上面的注意事項都被處理。

06 六、Seata 中 AT 模式的自動回滾

對於使用 Seata 的人來說操作比較簡單，只需要在觸發整個事務的業務發起方的方法中加入@GlobalTransactional 標註，且使用普通的 @Transactional 包裝好分散式事務中相關服務的相關方法即可。

在 Seata 內在機制中，AT 模式的自動回滾往往需要執行以下步驟：






（一）一階段

  1. 解析每個服務方法執行的 SQL，記錄 SQL 的型別（Update、Insert 或 Delete），修改表並更新 SQL 條件等資訊；

  2. 根據前面的條件資訊生成查詢語句，並記錄修改前的資料映象；

  3. 執行業務的 SQL；

  4. 記錄修改後的資料映象；

  5. 插入回滾日誌：把前後映象資料及業務 SQL 相關的資訊組成一條回滾日誌記錄，插入 UNDO_LOG 表中；

  6. 提交前，向 TC 註冊分支，並申請相關修改資料行的全域性鎖 ；

  7. 本地事務提交：業務資料的更新與前面步驟生成的 UNDO LOG 一併提交；

  8. 將本地事務提交的結果上報給事務控制器。



收到事務控制器的分支回滾請求後，我們會開啟一個本地事務，並執行如下操作：



    1. 查詢相應的 UNDO LOG 記錄；

    2. 資料校驗：拿 UNDO LOG 中的後映象資料與當前資料進行對比，如果存在不同，說明資料被當前全域性事務之外的動作做了修改，此時我們需要根據配置策略進行處理；

    3. 根據 UNDO LOG 中的前映象和業務 SQL 的相關資訊生成回滾語句並執行；

    4. 提交本地事務，並把本地事務的執行結果（即分支事務回滾的結果）上報事務控制器。

    5. 收到事務控制器的分支提交請求後，我們會將請求放入一個非同步任務佇列中，並馬上返回提交成功的結果給事務控制器。

    6. 非同步任務階段的分支提交請求將非同步地、批次地刪除相應 UNDO LOG 記錄。



    推薦閱讀：


    來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69949806/viewspace-2902748/，如需轉載，請註明出處，否則將追究法律責任。

    相關文章