部署

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操作進行回滾。

因(yin)為TM、RM、TC之間的交(jiao)互都是(shi)通過網絡完成的，很容易出(chu)現網絡斷開的情況(kuang)，因(yin)此TC提(ti)供了四個定(ding)時線程池，定(ding)時檢測系統中是(shi)否(fou)有(you)超時事務(wu)(wu)、異步提(ti)交(jiao)事務(wu)(wu)、回滾重(zhong)試事務(wu)(wu)、重(zhong)試提(ti)交(jiao)事務(wu)(wu)，如果發現了有(you)這四類事務(wu)(wu)，則從全局事務(wu)(wu)中獲(huo)取所有(you)的分支事務(wu)(wu)，分別調(diao)用各個分支事務(wu)(wu)完成對應的操作，依(yi)次來確(que)保事務(wu)(wu)的一致性。

需要考慮的問題：

通過上面流程(cheng)的(de)分析可以(yi)發現(xian)，每次(ci)SQL操作(zuo)（查詢除外(wai)）時(shi)，都(dou)會增加額外(wai)了三次(ci)數(shu)(shu)據庫(ku)操作(zuo)；每次(ci)全(quan)局事務(wu)和分支(zhi)事務(wu)開(kai)啟(qi)時(shi)，都(dou)涉及到TM、RM與(yu)TC的(de)交(jiao)互；全(quan)局事務(wu)期間還要(yao)承(cheng)擔數(shu)(shu)據短時(shi)不一(yi)致的(de)情況，這些都(dou)是我們在使用(yong)AT模(mo)式(shi)需(xu)要(yao)考慮的(de)情況。