分散式事務~從seata例項來學習分散式事務

张占岭發表於2024-11-13
分散式

部署

docker run --name=seata1.4.2 \
        --hostname=d67502e1d2ea \
        --mac-address=02:42:0a:ff:fe:02 \
        --env=SEATA_IP=192.168.60.136 \
        --env=SEATA_PORT=8091 \
        --volume=/root/seata/seata-server-1.4.2/conf/registry.conf:/seata-server/resources/registry.conf \
        --volume=/root/seata/seata-server-1.4.2/conf/file.conf:/seata-server/resources/file.conf \
        --volume=/root/dev/docker/seata/logs:/root/logs \
        --workdir=/seata-server \
        -p 8091:8091 \
        --restart=no \
        --runtime=runc \
        --detach=true \
        -t \
        seataio/seata-server:1.4.2

說明

  • 兩個微服務
  • micro-order為訂單服務
  • micro-product為商品服務
  • 下單成功後，會扣商品服務的庫存
  • 庫存成功後，會一起提交，失敗後，會回滾

分散式事務術語

  • TC (Transaction Coordinator) - 事務協調者，維護全域性和分支事務的狀態，驅動全域性事務提交或回滾。
  • TM (Transaction Manager) - 事務管理器，定義全域性事務的範圍：開始全域性事務、提交或回滾全域性事務。
  • RM (Resource Manager) - 資源管理器，管理分支事務處理的資源，與TC交談以註冊分支事務和報告分支事務的狀態，並驅動分支事務提交或回滾。

四種分散式事務模式

  • AT 模式是無侵入的分散式事務解決方案，適用於不希望對業務進行改造的場景，幾乎0學習成本。
  • TCC 模式是高效能分散式事務解決方案，適用於核心系統等對效能有很高要求的場景。
  • Saga 模式是長事務解決方案，適用於業務流程長且需要保證事務最終一致性的業務系統，Saga 模式一階段就會提交本地事務，無鎖，長流程情況下可以保證效能，多用於渠道層、整合層業務系統。事務參與者可能是其它公司的服務或者是遺留系統的服務，無法進行改造和提供 TCC 要求的介面，也可以使用 Saga 模式。
  • XA模式是分散式強一致性的解決方案，但效能低而使用較少。
  • Seata預設是AT模式
    seata涉及到三個角色之間的互動，本文透過流程圖將AT模式下的基本互動流程梳理一下，為我們以後的解析打下基礎。
    假設有三個微服務，分別是服務A、B、C，其中服務A中呼叫了服務B和服務C，TM、TC、RM三者之間的互動流程如下圖：

  1. 服務A啟動時，GlobalTransactionScanner會對有@GlobalTransaction註解的方法進行AOP增強，並生成代理，增強的程式碼位於GlobalTransactionalInterceptor類中，當呼叫@GlobalTransaction註解的方法時，增強程式碼首先向TC註冊全域性事務，表示全域性事務的開始，同時TC生成XID，並返回給TM；
  2. 服務A中呼叫服務B時，將XID傳遞給服務B；
  3. 服務B得到XID後，訪問TC，註冊分支事務，並從TC獲得分支事務ID，TC根據XID將分支事務與全域性事務關聯；
  4. 接下來服務B開始執行SQL語句，在執行前將表中對應的資料儲存一份，執行後在儲存一份，將這兩份記錄作為回滾記錄寫入到資料庫中，如果執行過程中沒有異常，服務B最後將事務提交，並通知TC分支事務成功，服務B也會清除本地事務資料；
  5. 服務A訪問完服務B後，訪問服務C；
  6. 服務C與TC之間的互動與服務B完全一致；
  7. 服務B和服務C都成功後，服務A透過TM通知TC全域性事務成功，如果失敗了，服務A也會通知TC全域性事務失敗；
  8. TC記錄了全域性事務下的每個分支事務，TC收到全域性事務的結果後，如果結果成功，則通知RM成功，RM收到通知後清理之前在資料庫中儲存的回滾記錄，如果失敗了，則RM要查詢出之前在資料庫儲存的回滾記錄，對之前的SQL操作進行回滾。

因為TM、RM、TC之間的互動都是透過網路完成的，很容易出現網路斷開的情況，因此TC提供了四個定時執行緒池，定時檢測系統中是否有超時事務、非同步提交事務、回滾重試事務、重試提交事務，如果發現了有這四類事務，則從全域性事務中獲取所有的分支事務，分別呼叫各個分支事務完成對應的操作，依次來確保事務的一致性。

需要考慮的問題：

透過上面流程的分析可以發現，每次SQL操作（查詢除外）時，都會增加額外了三次資料庫操作；每次全域性事務和分支事務開啟時，都涉及到TM、RM與TC的互動；全域性事務期間還要承擔資料短時不一致的情況，這些都是我們在使用AT模式需要考慮的情況。

相關文章