第一章?Seata 概述

一、分布式事務

1.1?分布式事務簡介

（1）事務

事務可以看做是一次大的活動，它由不同的小活動組成，這些活動要么全部成功，要么全部失敗。

（2）本地事務

? 在計算機系統(tǒng)中，更多的是通過關系型數(shù)據(jù)庫來控制事務，這是利用數(shù)據(jù)庫本身的事務特性來實現(xiàn)的，因此叫數(shù)據(jù)庫事務，由于應用主要靠關系數(shù)據(jù)庫來控制事務，而數(shù)據(jù)庫通常和應用在同一個服務器，所以基于關系型數(shù)據(jù)庫的事務又被稱為本地事務。

數(shù)據(jù)庫事務的四大特性：ACID

• A（Atomic）：原子性，構成事務的所有操作，要么都執(zhí)行完成，要么全部不執(zhí)行，不可能出現(xiàn)部分成功部分失敗的情況。
• C（Consistency）：一致性，在事務執(zhí)行前后，數(shù)據(jù)庫的一致性約束沒有被破壞。比如：張三向李四轉(zhuǎn) 100 元，轉(zhuǎn)賬前和轉(zhuǎn)賬后的數(shù)據(jù)是正確狀態(tài)這叫一致性，如果出現(xiàn)張三轉(zhuǎn)出 100 元，李四賬戶沒有增加 100 元這就出現(xiàn)了數(shù) 據(jù)錯誤，就沒有達到一致性。
• I（Isolation）：隔離性，數(shù)據(jù)庫中的事務一般都是并發(fā)的，隔離性是指并發(fā)的兩個事務的執(zhí)行互不干擾，一個事務不能看到其他事務的運行過程的中間狀態(tài)。通過配置事務隔離級別可以比避免臟讀、重復讀問題。
• D（Durability）：持久性，事務完成之后，該事務對數(shù)據(jù)的更改會持久到數(shù)據(jù)庫，且不會被回滾。

數(shù)據(jù)庫事務在實現(xiàn)時會將一次事務的所有操作全部納入到一個不可分割的執(zhí)行單元，該執(zhí)行單元的所有操作要么都成功，要么都失敗，只要其中任一操作執(zhí)行失敗，都將導致整個事務的回滾。

（3）分布式事務

隨著互聯(lián)網(wǎng)的快速發(fā)展，軟件系統(tǒng)由原來的單體應用轉(zhuǎn)變?yōu)榉植际綉谩?/p>

分布式系統(tǒng)會把一個應用系統(tǒng)拆分為可獨立部署的多個服務，因此需要服務與服務之間遠程協(xié)作才能完成事務操作，這種分布式系統(tǒng)環(huán)境下由不同的服務之間通過網(wǎng)絡遠程協(xié)作完成事務稱之為分布式事務。例如用戶注冊送積分事務、創(chuàng)建訂單減庫存事務，銀行轉(zhuǎn)賬事務等都是分布式事務。

分布式事務產(chǎn)生的情景：

• 跨JVM進程產(chǎn)生分布式事務
• 跨數(shù)據(jù)庫實例產(chǎn)生分布式事務
• 多服務訪問同一個數(shù)據(jù)庫實例

1.2 分布式事務基礎理論

?（1）CAP定理

1998年，加州大學的計算機科學家 Eric Brewer 提出，分布式系統(tǒng)有三個指標：

• consistency：一致性。用戶訪問分布式系統(tǒng)中的任意節(jié)點，得到的數(shù)據(jù)必須一致。
• Availability：可用性。用戶訪問集群中的任意健康節(jié)點，必須能得到響應，而不是超時或拒絕。
• Partition tolerance：分區(qū)容錯性。
  • Partition：分區(qū)因為網(wǎng)絡故障或其它原因?qū)е路植际较到y(tǒng)中的部分節(jié)點與其它節(jié)點失去連接，形成獨立分區(qū)。
  • Tolerance：容錯，在集群出現(xiàn)分區(qū)時，整個系統(tǒng)也要持續(xù)對外提供服務。

當分布式系統(tǒng)節(jié)點通過網(wǎng)絡連接，就一定會出現(xiàn)分區(qū)問題（P），出現(xiàn)分區(qū)時系統(tǒng)的一致性（C）和可用性（A）就無法同時滿足，此時就需要考慮是滿足 CP 還是 AP。

（2）Base 理論

BASE 理論是對 CAP 的一種解決思路，包含三個思想：

• Basically Available：基本可用。分布式系統(tǒng)在出現(xiàn)故障時，允許損失部分可用性，即保證核心可用。
• Soft State：軟狀態(tài)。在一定時間內(nèi)，允許出現(xiàn)中間狀態(tài)，比如臨時的不一致狀態(tài)。
• Eventually Consistent：最終一致性。雖然無法保證強一致性，但是在軟狀態(tài)結(jié)束后，最終達到數(shù)據(jù)一致。

分布式事務最大的問題是各個子事務的一致性問題，因此可以借鑒 CAP 定理和 BASE 理論：

• AP 模式：各子事務分別執(zhí)行和提交，允許出現(xiàn)結(jié)果不一致，然后采用彌補措施恢復數(shù)據(jù)即可，實現(xiàn)最終一致。
• CP 模式：各個子事務執(zhí)行后互相等待，同時提交，同時回滾，達成強一致。但事務等待過程中，處于弱可用狀態(tài)。
  ?

（3）分布式事務解決

解決分布式事務的思想和模型：

• 全局事務：整個分布式事務
• 分支事務：分布式事務中包含的每個子系統(tǒng)的事務
• 最終一致思想：各分支事務分別執(zhí)行并提交，如果有不一致的情況，再想辦法恢復數(shù)據(jù)
• 強一致思想：各分支事務執(zhí)行完業(yè)務不要提交，等待彼此結(jié)果，而后統(tǒng)一提交或回滾

1.3 兩階段 2PC

2PC（Two-phase commit，三階段提交） 即兩階段提交協(xié)議，是將整個事務流程分為兩個階段，準備階段（Prepare phase）、提交階段（commit phase），2 是指兩個階段，P 是指準備階段，C 是指提交階段。

一階段：

1. 協(xié)調(diào)者向所有參與者發(fā)送事務請求，詢問是否可執(zhí)行事務操作，然后等待各個參與者的響應。
2. 各個參與者接收到協(xié)調(diào)者事務請求后，執(zhí)行事務操作(例如更新一個關系型數(shù)據(jù)庫表中的記錄)，并將 Undo 和 Redo 信息記錄事務日志中。
3. 如果參與者成功執(zhí)行了事務并寫入 Undo 和 Redo 信息，則向協(xié)調(diào)者返回 YES 響應，否則返回 NO 響應。當然參與者也可能宕機，從而不會返回響應。

二階段：

1. 協(xié)調(diào)者向所有參與者發(fā)送 Commit/Rollback 請求。
2. 事務提交參與者收到 CommitRollback 請求后，執(zhí)行事務提交/回滾，提交/回滾完成后釋放事務執(zhí)行期占用的所有資源。反饋結(jié)果參與者執(zhí)行事務提交/回滾后向協(xié)調(diào)者發(fā)送 Ack 響應。
3. 完成事務接收到所有參與者的 Ack 響應后，完成事務提交/回滾。

2PC 的問題：

• 同步阻塞：參與者在等待協(xié)調(diào)者的指令時，其實是在等待其他參與者的響應，在此過程中，參與者是無法進行其他操作的，也就是阻塞了其運行。倘若參與者與協(xié)調(diào)者之間網(wǎng)絡異常導致參與者一直收不到協(xié)調(diào)者信息，那么會導致參與者一直阻塞下去。
• 單點：
  • 在2PC中，一切請求都來自協(xié)調(diào)者，所以協(xié)調(diào)者的地位是至關重要的，如果協(xié)調(diào)者宕機，那么就會使參與者一直阻塞并一直占用事務資源。
  • 如果協(xié)調(diào)者也是分布式，使用選主方式提供服務，那么在一個協(xié)調(diào)者掛掉后，可以選取另一個協(xié)調(diào)者繼續(xù)后續(xù)的服務，可以解決單點問題。但是，新協(xié)調(diào)者無法知道上一個事務的全部狀態(tài)信息(例如已等待Prepare響應的時長等)，所以也無法順利處理上一個事務。
• 數(shù)據(jù)不一致：Commit 事務過程中 Commit/Rollack 請求可能因為協(xié)調(diào)者宕機或協(xié)調(diào)者與參與者網(wǎng)絡問題丟失，那么就導致了部分參與者沒有收到 Commt/Rollack 請求，而其他參與者則正常收到執(zhí)行了 Commit/Rollack 操作，沒有收到請求的參與者則繼續(xù)阻塞。這時，參與者之間的數(shù)據(jù)就不再一致了。
• 環(huán)境可靠性依賴：協(xié)調(diào)者 Prepare 請求發(fā)出后，等待響應，然而如果有參與者宕機或與協(xié)調(diào)者之間的網(wǎng)絡中斷，都會導致協(xié)調(diào)者無法收到所有參與者的響應，那么在 2PC 中，協(xié)調(diào)者會等待一定時間，然后超時后會觸發(fā)事務中斷，在這個過程中，協(xié)調(diào)者和所有其他參與者都是出于阻塞的

1.4 三階段 3PC

3PC（Three-phase commit，三階段提交）也叫三階段提交協(xié)議，是在計算機網(wǎng)絡及數(shù)據(jù)庫的范疇下，使得一個分布式系統(tǒng)內(nèi)的所有節(jié)點能夠執(zhí)行事務的提交的一種分布式算法。

3PC 主要是為了解決兩階段提交協(xié)議的阻塞問題，2PC 存在的問題是當協(xié)作者崩潰時，參與者不能做出最后的選擇。因此參與者可能在協(xié)作者恢復之前保持阻塞。

除了引入超時機制之外，3PC 把 2PC 的準備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit 三個階段。

CanCommit 階段：

1. 事務詢問：協(xié)調(diào)者向參與者發(fā)送 CanCommit 請求，詢問是否可以執(zhí)行事務提交操作，然后開始等待參與者的響應。
2. 響應反饋：參與者接到 CanCommit 請求之后，如果其自身認為可以順利執(zhí)行事務，則返回 Yes 響應，并進入預備狀態(tài)。否則反饋 No。

PreCommit 階段：

• 在 CanCommit 階段中，如果所有的參與者都返回 Yes 的話，那么就會進入 PreCommit 階段進行事務預提交。這里的 PreCommit 階段跟上面的第一階段是差不多的，只不過這里協(xié)調(diào)者和參與者都引入了超時機制（2PC中只有協(xié)調(diào)者可以超時，參與者沒有超時機制）。

DoCommit 階段：

1. 協(xié)調(diào)者向所有參與者發(fā)送 Commit/Rollback 請求。
2. 事務提交參與者收到 CommitRollback 請求后，執(zhí)行事務提交/回滾，提交/回滾完成后釋放事務執(zhí)行期占用的所有資源。反饋結(jié)果參與者執(zhí)行事務提交/回滾后向協(xié)調(diào)者發(fā)送 Ack 響應。
3. 完成事務接收到所有參與者的 Ack 響應后，完成事務提交/回滾。

3PC 對于協(xié)調(diào)者和參與者都設置了超時時間，避免了參與者在長時間無法與協(xié)調(diào)者節(jié)點通訊（協(xié)調(diào)者掛掉了）的情況下，無法釋放資源的問題，因為參與者自身擁有超時機制會在超時后，自動進行本地 commit 從而進行釋放資源，這種機制也側(cè)面降低了整個事務的阻塞時間和范圍。

二、Seata 概述

2.1?Seata 簡介

（1）Seata 簡介

Seata 是2019年1月份螞蟻金服和阿里巴巴共同開源的分布式事務解決方案，致力于提供高性能和簡單易用的分布式事務服務。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，為用戶打造一站式的分布式解決方案。

（2）Seata 發(fā)展歷史

1. 早在 2007 年，阿里巴巴和螞蟻集團內(nèi)部開發(fā)了分布式事務中間件，用于解決電商、支付、物流等業(yè)務場景中應用數(shù)據(jù)的一致性問題。內(nèi)部項目分別被稱為 TXC (Taobao Transaction Constructor)/XTS(eXtended Transaction Service)，該項目幾乎在每筆訂單的交易支付鏈路幾乎都有使用。

2. 自 2013 年以來，阿里巴巴和螞蟻集團已在阿里云和金融云上向企業(yè)客戶分別發(fā)布了分布式事務云服務產(chǎn)品 GTS(global transaction service)/DTX(Distributed Transaction-eXtended)，在各個行業(yè)領域積累了大量用戶。

3. 2019 年 1 月，阿里巴巴集團正式開源了該項目，項目命名為 Fescar (Fast & Easy Commit and Rollback)）。項目開源以來，它受到了眾多開發(fā)人員的熱烈歡迎和贊揚，開源一周收獲了超 3k star，曾一度蟬聯(lián) GitHub Trending 排行榜第一。

4. 2019 年 4 月，螞蟻集團數(shù)據(jù)中間件團隊加入了 Fescar 社區(qū)。為了創(chuàng)建一個更加開放和中立的社區(qū)，F(xiàn)escar 改名為 Seata（Simple Extensible Autonomous Transaction Architecture），代碼倉庫從 Alibaba organization 遷移到其獨立的 Seata organization。

5. 2019 年 12 月，Seata 開源項目正式發(fā)布 1.0.0 GA 版本，標志著項目已基本可生產(chǎn)使用。

6. 2023 年 10 月，為了更好的通過社區(qū)驅(qū)動技術的演進，阿里和螞蟻集團正式將 Seata 捐贈給 Apache 基金會，該提案已通過了 Apache 基金會的投票決議，Seata 正式進入 Apache 孵化器。

（3）Seata 角色

Seata 事務管理中有三個重要的角色：

• TC (Transaction Coordinator)：事務協(xié)調(diào)者?。維護全局和分支事務的狀態(tài)，驅(qū)動全局事務提交或回滾。
• TM (Transaction Manager)：事務管理器?。定義全局事務的范圍：開始全局事務、提交或回滾全局事務。
• RM (Resource Manager)：資源管理器?。管理分支事務處理的資源，與 TC 交談以注冊分支事務和報告分支事務的狀態(tài)，并驅(qū)動分支事務提交或回滾。

（4）Seata 方案

Seata提供了四種不同的分布式事務解決方案:

• XA 模式：強一致性分階段事務模式，犧牲了一定的可用性，無業(yè)務侵入
• TCC 模式：最終一致的分階段事務模式，有業(yè)務侵入
• AT 模式：最終一致的分階段事務模式，無業(yè)務侵入，也是 Seata 的默認模式
• SAGA 模式：長事務模式，有業(yè)務侵入

2.2 Seata 安裝

（1）Seata 下載

進入?Seata 官網(wǎng)，如下：

點擊下載，進入下載界面：

選擇對應的版本和平臺，下載即可。下載完成后，解壓到指定目錄，解壓后的目錄如下：

bin：

• seata-server.bat：Windows 平臺下啟動文件
• seata-server.sh：Linux 平臺下啟動文件

conf：

• file.conf：文件存儲的相關配置
• registry.conf：注冊中心和配置中心的相關配置
• logback.xml：日志的相關配置

Seata 高版本的 seata-server 文件目錄有所變化：

conf 目錄下的 file.conf 和 registry.conf 文件被?application.yml 文件所代替。

2.3 Seata 部署

修改數(shù)據(jù)存儲文件 file.conf，file.conf 文件如下：

## transaction log store, only used in seata-server
store {
  ## store mode: file、db、redis
  mode = "file"
  ## rsa decryption public key
  publicKey = ""
  ## file store property
  file {
    ## store location dir
    dir = "sessionStore"
    # branch session size , if exceeded first try compress lockkey, still exceeded throws exceptions
    maxBranchSessionSize = 16384
    # globe session size , if exceeded throws exceptions
    maxGlobalSessionSize = 512
    # file buffer size , if exceeded allocate new buffer
    fileWriteBufferCacheSize = 16384
    # when recover batch read size
    sessionReloadReadSize = 100
    # async, sync
    flushDiskMode = async
  }

  ## database store property
  db {
    ## the implement of javax.sql.DataSource, such as DruidDataSource(druid)/BasicDataSource(dbcp)/HikariDataSource(hikari) etc.
    datasource = "druid"
    ## mysql/oracle/postgresql/h2/oceanbase etc.
    dbType = "mysql"
    driverClassName = "com.mysql.jdbc.Driver"
    ## if using mysql to store the data, recommend add rewriteBatchedStatements=true in jdbc connection param
    url = "jdbc:mysql://127.0.0.1:3306/seata?rewriteBatchedStatements=true"
    user = "mysql"
    password = "mysql"
    minConn = 5
    maxConn = 100
    globalTable = "global_table"
    branchTable = "branch_table"
    lockTable = "lock_table"
    queryLimit = 100
    maxWait = 5000
  }

  ## redis store property
  redis {
    ## redis mode: single、sentinel
    mode = "single"
    ## single mode property
    single {
      host = "127.0.0.1"
      port = "6379"
    }
    ## sentinel mode property
    sentinel {
      masterName = ""
      ## such as "10.28.235.65:26379,10.28.235.65:26380,10.28.235.65:26381"
      sentinelHosts = ""
    }
    password = ""
    database = "0"
    minConn = 1
    maxConn = 10
    maxTotal = 100
    queryLimit = 100
  }
}

Seata 中文件存儲有三種方式：

• file：單機模式。全局事務會話信息內(nèi)存中讀寫并持久化本地文件root.data，性能較高(默認)
• db：高可用模式，全局事務會話信息通過db共享，相應性能差些
• redis：Seata-Server 1.3 及以上版本支持，性能較高，存在事務信息丟失風險

修改數(shù)據(jù)存儲方式，如修改為 db：

## transaction log store, only used in seata-server
store {
  ## store mode: file、db、redis
  mode = "db"
  ## rsa decryption public key
  publicKey = ""

  ## database store property
  db {
    ## the implement of javax.sql.DataSource, such as DruidDataSource(druid)/BasicDataSource(dbcp)/HikariDataSource(hikari) etc.
    datasource = "druid"
    ## mysql/oracle/postgresql/h2/oceanbase etc.
    dbType = "mysql"
    driverClassName = "com.mysql.jdbc.Driver"
    ## if using mysql to store the data, recommend add rewriteBatchedStatements=true in jdbc connection param
    url = "jdbc:mysql://127.0.0.1:3306/seata?rewriteBatchedStatements=true"
    user = "mysql"
    password = "mysql"
    minConn = 5
    maxConn = 100
    globalTable = "global_table"
    branchTable = "branch_table"
    lockTable = "lock_table"
    queryLimit = 100
    maxWait = 5000
  }
}

數(shù)據(jù)存儲方式如果采用 db 方式的話，則需要創(chuàng)建對應的數(shù)據(jù)庫表用于記錄，創(chuàng)建數(shù)據(jù)庫表的 SQL，在 Seata 項目源碼的?/script/server/db 目錄下可以獲?。?/p>

全局事務表：

CREATE TABLE IF NOT EXISTS `global_table`
(
    `xid`                       VARCHAR(128) NOT NULL,
    `transaction_id`            BIGINT,
    `status`                    TINYINT      NOT NULL,
    `application_id`            VARCHAR(32),
    `transaction_service_group` VARCHAR(32),
    `transaction_name`          VARCHAR(128),
    `timeout`                   INT,
    `begin_time`                BIGINT,
    `application_data`          VARCHAR(2000),
    `gmt_create`                DATETIME,
    `gmt_modified`              DATETIME,
    PRIMARY KEY (`xid`),
    KEY `idx_status_gmt_modified` (`status` , `gmt_modified`),
    KEY `idx_transaction_id` (`transaction_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

分支事務表：

CREATE TABLE IF NOT EXISTS `branch_table`
(
    `branch_id`         BIGINT       NOT NULL,
    `xid`               VARCHAR(128) NOT NULL,
    `transaction_id`    BIGINT,
    `resource_group_id` VARCHAR(32),
    `resource_id`       VARCHAR(256),
    `branch_type`       VARCHAR(8),
    `status`            TINYINT,
    `client_id`         VARCHAR(64),
    `application_data`  VARCHAR(2000),
    `gmt_create`        DATETIME(6),
    `gmt_modified`      DATETIME(6),
    PRIMARY KEY (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

鎖記錄表

CREATE TABLE IF NOT EXISTS `lock_table`
(
    `row_key`        VARCHAR(128) NOT NULL,
    `xid`            VARCHAR(128),
    `transaction_id` BIGINT,
    `branch_id`      BIGINT       NOT NULL,
    `resource_id`    VARCHAR(256),
    `table_name`     VARCHAR(32),
    `pk`             VARCHAR(36),
    `status`         TINYINT      NOT NULL DEFAULT '0' COMMENT '0:locked ,1:rollbacking',
    `gmt_create`     DATETIME,
    `gmt_modified`   DATETIME,
    PRIMARY KEY (`row_key`),
    KEY `idx_status` (`status`),
    KEY `idx_branch_id` (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

分布式鎖記錄表：

CREATE TABLE IF NOT EXISTS `distributed_lock`
(
    `lock_key`       CHAR(20) NOT NULL,
    `lock_value`     VARCHAR(20) NOT NULL,
    `expire`         BIGINT,
    primary key (`lock_key`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('AsyncCommitting', ' ', 0);
INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('RetryCommitting', ' ', 0);
INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('RetryRollbacking', ' ', 0);
INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('TxTimeoutCheck', ' ', 0);

修改 Seata 的注冊中心和配置中心，對應文件為?registry.conf，文件內(nèi)容如下：

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "file"

  nacos {
    application = "seata-server"
    serverAddr = "127.0.0.1:8848"
    group = "SEATA_GROUP"
    namespace = ""
    cluster = "default"
    username = ""
    password = ""
  }
  eureka {
    serviceUrl = "http://localhost:8761/eureka"
    application = "default"
    weight = "1"
  }
  redis {
    serverAddr = "localhost:6379"
    db = 0
    password = ""
    cluster = "default"
    timeout = 0
  }
  zk {
    cluster = "default"
    serverAddr = "127.0.0.1:2181"
    sessionTimeout = 6000
    connectTimeout = 2000
    username = ""
    password = ""
  }
  consul {
    cluster = "default"
    serverAddr = "127.0.0.1:8500"
    aclToken = ""
  }
  etcd3 {
    cluster = "default"
    serverAddr = "http://localhost:2379"
  }
  sofa {
    serverAddr = "127.0.0.1:9603"
    application = "default"
    region = "DEFAULT_ZONE"
    datacenter = "DefaultDataCenter"
    cluster = "default"
    group = "SEATA_GROUP"
    addressWaitTime = "3000"
  }
  file {
    name = "file.conf"
  }
}

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "file"

  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = ""
    password = ""
    dataId = "seataServer.properties"
  }
  consul {
    serverAddr = "127.0.0.1:8500"
    aclToken = ""
  }
  apollo {
    appId = "seata-server"
    ## apolloConfigService will cover apolloMeta
    apolloMeta = "http://192.168.1.204:8801"
    apolloConfigService = "http://192.168.1.204:8080"
    namespace = "application"
    apolloAccesskeySecret = ""
    cluster = "seata"
  }
  zk {
    serverAddr = "127.0.0.1:2181"
    sessionTimeout = 6000
    connectTimeout = 2000
    username = ""
    password = ""
    nodePath = "/seata/seata.properties"
  }
  etcd3 {
    serverAddr = "http://localhost:2379"
  }
  file {
    name = "file.conf"
  }
}

Seata 支持多種注冊中心和配置中心，例如使用 nacos，配置如下：

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "nacos"

  nacos {
    application = "seata-server"
    serverAddr = "127.0.0.1:8848"
    group = "SEATA_GROUP"
    namespace = ""
    cluster = "default"
    username = "nacos"
    password = "nacos"
  }
}

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "nacos"

  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }
}

其中 nacos 的相關配置需要修改為實際使用的配置，Seata 提供了部分配置中心的默認配置 config.txt，在 Seata 項目源碼的?script/config-center/ 路徑下可以找到：

啟動 Seata，使用如下命令啟動：

# 直接啟動方式
bin/seata-server.sh

# 添加配置方式啟動
bin/seata-server.sh -h 127.0.0.1 -p 8091 -m db -n 1 -e test

• -h：host，指定在注冊中心注冊的 IP 地址
• -p：port，指定啟動端口，默認8091
• -m：storeMode，指定事務日志存儲方式，支持 file、db、redis
• -n：serverNode，指定 seata-server 的節(jié)點 ID，如1，2，3
• -e：seataEnv，指定 seata-server 運行環(huán)境，如 dev、test、prod，啟動時會使用對應的配置文件如 registry-test.conf

Windows 平臺下啟動?seata-server.bat，Linux 平臺下啟動?seata-server.sh

2.4 Seata 集成

微服務集成 Seata，詳細步驟如下：

引入依賴：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <version>2.2.5.RELEASE</version>
    <exclusions>
        <exclusion>
            <groupId>io.seata</groupId>
            <artifactId>seata-spring-boot-starter</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>1.4.2</version>
</dependency>

在 application.yml 文件中配置 Seata 的相關配置：

seata:
  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: "SEATA_GROUP"
      application: seata-tc-server
      username: nacos
      password: nacos
  # 事務組名稱
  tx-service-group: seata-demo
  service:
    # 事務組與cluster的映射關系
    vgroup-mapping:
      seata-demo: SH

客戶端數(shù)據(jù)庫創(chuàng)建 undo_log 表：

CREATE TABLE IF NOT EXISTS `undo_log`
(
    `branch_id`     BIGINT       NOT NULL COMMENT 'branch transaction id',
    `xid`           VARCHAR(128) NOT NULL COMMENT 'global transaction id',
    `context`       VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
    `rollback_info` LONGBLOB     NOT NULL COMMENT 'rollback info',
    `log_status`    INT(11)      NOT NULL COMMENT '0:normal status,1:defense status',
    `log_created`   DATETIME(6)  NOT NULL COMMENT 'create datetime',
    `log_modified`  DATETIME(6)  NOT NULL COMMENT 'modify datetime',
    UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE = InnoDB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4 COMMENT ='AT transaction mode undo table';
ALTER TABLE `undo_log` ADD INDEX `ix_log_created` (`log_created`);

第二章 Seata 事務模式

一、Seata XA 模式

?1.1 XA 模式簡介

（1）XA 模式

XA 模式是從 1.2 版本支持的事務模式。XA 規(guī)范 是 X/Open 組織定義的分布式事務處理（DTP，Distributed Transaction Processing）標準。

Seata XA 模式是利用事務資源（數(shù)據(jù)庫、消息服務等）對 XA 協(xié)議的支持，以 XA 協(xié)議的機制來管理分支事務的一種事務模式。

（2）優(yōu)缺點

優(yōu)點：

• 與 Seata 支持的其它事務模式不同，XA 協(xié)議要求事務資源本身提供對規(guī)范和協(xié)議的支持，所以事務資源（如數(shù)據(jù)庫）可以保障從任意視角對數(shù)據(jù)的訪問有效隔離，滿足全局數(shù)據(jù)一致性。
• 業(yè)務無侵入：和 AT 一樣，XA 模式將是業(yè)務無侵入的，不給應用設計和開發(fā)帶來額外負擔。
• 數(shù)據(jù)庫的支持廣泛：XA 協(xié)議被主流關系型數(shù)據(jù)庫廣泛支持，不需要額外的適配即可使用。
• 強一致性，滿足 ACID 原則。

缺點：

• XA prepare 后，分支事務進入阻塞階段，收到 XA commit 或 XA rollback 前必須阻塞等待。事務資源長時間得不到釋放，鎖定周期長，而且在應用層上面無法干預，性能差。
• 依賴關系型數(shù)據(jù)庫實現(xiàn)事務，如果數(shù)據(jù)庫不支持事務則無法滿足 XA 模式。

1.2 XA 模式原理

—階段：

• RM 注冊分支事務到 TC，執(zhí)行分支業(yè)務 SQL 但不提交，只報告執(zhí)行狀態(tài)到 TC。

二階段：

• TC 檢測各分支事務執(zhí)行狀態(tài)，如果都成功，通知所有 RM 提交事務，如果有失敗，通知所有 RM。
• RM 接收 TC 指令，提交或回滾事務。

1.3 XA 模式實現(xiàn)

配置 Seata 事務模式為 XA 模式：

seata:
  data-source-proxy-mode: XA

使用注解 @GlobalTransantion

二、Seata AT 模式

2.1?AT 模式簡介

（1）AT 模式

AT 模式是 Seata 創(chuàng)新的一種非侵入式的分布式事務解決方案，Seata 在內(nèi)部做了對數(shù)據(jù)庫操作的代理層，使用 Seata AT 模式時，實際上用的是 Seata 自帶的數(shù)據(jù)源代理 DataSourceProxy，Seata 在這層代理中加入了很多邏輯，比如插入回滾 undo_log 日志，檢查全局鎖等。

AT 模式是 Seata 的默認模式。

在 AT 模式下，用戶只需關注自己的業(yè)務 SQL，用戶的業(yè)務 SQL 作為一階段，Seata 框架會自動生成事務的二階段提交和回滾操作。
?

（2）優(yōu)缺點

優(yōu)點：

• 一階段完成直接提交事務，釋放數(shù)據(jù)庫資源，性能比較好利用全局鎖實現(xiàn)讀寫隔離
• 沒有代碼侵入，框架自動完成回滾和提交

缺點：

• 兩階段之間屬于軟狀態(tài)，屬于最終一致
• 框架的快照功能會影響性能，但比 XA 模式要好很多

2.2?AT 模式原理

（1）AT 模式原理分析

在一階段，Seata 會攔截業(yè)務 SQL 并解析 SQL 語義，找到業(yè)務 SQL 要更新的業(yè)務數(shù)據(jù)，在業(yè)務數(shù)據(jù)被更新前，將其保存成 before image，然后執(zhí)行業(yè)務 SQL 更新業(yè)務數(shù)據(jù)，在業(yè)務數(shù)據(jù)更新之后，再將其保存成 after image，最后生成行鎖。以上操作全部在一個數(shù)據(jù)庫事務內(nèi)完成，這樣保證了一階段操作的原子性。

二階段如果是提交的話，因為業(yè)務 SQL 在一階段已經(jīng)提交至數(shù)據(jù)庫，所以 Seata 框架只需將一階段保存的快照數(shù)據(jù)和行鎖刪掉，完成數(shù)據(jù)清理即可。

二階段如果是回滾的話，Seata 就需要回滾一階段已經(jīng)執(zhí)行的業(yè)務 SQL，還原業(yè)務數(shù)據(jù)?；貪L方式便是用 before image 還原業(yè)務數(shù)據(jù)。

注意在還原前要首先要校驗臟寫，對比數(shù)據(jù)庫當前業(yè)務數(shù)據(jù)和 after image，如果兩份數(shù)據(jù)完全一致就說明沒有臟寫，可以還原業(yè)務數(shù)據(jù)，如果不一致就說明有臟寫，出現(xiàn)臟寫就需要轉(zhuǎn)人工處理。

3.3?AT 模式實現(xiàn)

?配置 Seata 事務模式為 AT 模式：

seata:
  data-source-proxy-mode: AT

使用注解 @GlobalTransantion

（2）寫隔離

AT 模式寫隔離：

• 一階段本地事務提交前，需要確保先拿到全局鎖?。
• 拿不到全局鎖?，不能提交本地事務。
• 拿全局鎖的嘗試被限制在一定范圍內(nèi)，超出范圍將放棄，并回滾本地事務，釋放本地鎖。

以一個示例來說明：

兩個全局事務 tx1 和 tx2，分別對 a 表的 m 字段進行更新操作，m 的初始值 1000。

tx1 先開始，開啟本地事務，拿到本地鎖，更新操作 m = 1000 - 100 = 900。本地事務提交前，先拿到該記錄的全局鎖 ，本地提交釋放本地鎖。 tx2 后開始，開啟本地事務，拿到本地鎖，更新操作 m = 900 - 100 = 800。本地事務提交前，嘗試拿該記錄的全局鎖 ，tx1 全局提交前，該記錄的全局鎖被 tx1 持有，tx2 需要重試等待全局鎖 。

tx1 二階段全局提交，釋放全局鎖 ，tx2 拿到全局鎖提交本地事務。

如果 tx1 的二階段全局回滾，則 tx1 需要重新獲取該數(shù)據(jù)的本地鎖，進行反向補償?shù)母虏僮鳎瑢崿F(xiàn)分支的回滾。

此時，如果 tx2 仍在等待該數(shù)據(jù)的全局鎖，同時持有本地鎖，則 tx1 的分支回滾會失敗。分支的回滾會一直重試，直到 tx2 的全局鎖等鎖超時，放棄 全局鎖 并回滾本地事務釋放本地鎖，tx1 的分支回滾最終成功。

因為整個過程全局鎖在 tx1 結(jié)束前一直是被 tx1 持有的，所以不會發(fā)生臟寫的問題。

（3）讀隔離

在數(shù)據(jù)庫本地事務隔離級別“讀已提交（Read Committed）”或以上的基礎上，Seata（AT 模式）的默認全局隔離級別是“讀未提交（Read Uncommitted）”。

如果應用在特定場景下，必需要求全局的“讀已提交”，目前 Seata 的方式是通過 SELECT FOR UPDATE 語句的代理。

SELECT FOR UPDATE 語句的執(zhí)行會申請全局鎖 ，如果全局鎖被其他事務持有，則釋放本地鎖（回滾 SELECT FOR UPDATE 語句的本地執(zhí)行）并重試。這個過程中，查詢是被 block 住的，直到全局鎖拿到，即讀取的相關數(shù)據(jù)是已提交的，才返回。

三、Seata TCC 模式

3.1?TCC 模式簡介

（1）TCC 模式

TCC 模式是 Seata 支持的一種由業(yè)務方細粒度控制的侵入式分布式事務解決方案，是繼 AT 模式后第二種支持的事務模式，最早由螞蟻金服貢獻。其分布式事務模型直接作用于服務層，不依賴底層數(shù)據(jù)庫，可以靈活選擇業(yè)務資源的鎖定粒度，減少資源鎖持有時間，可擴展性好，可以說是為獨立部署的 SOA 服務而設計的。

（2）優(yōu)缺點

優(yōu)點：

• TCC 完全不依賴底層數(shù)據(jù)庫，能夠?qū)崿F(xiàn)跨數(shù)據(jù)庫、跨應用資源管理，可以提供給業(yè)務方更細粒度的控制。
• 一階段完成直接提交事務，釋放數(shù)據(jù)庫資源，性能好
• 相比 AT 模型，無需生成快照，無需使用全局鎖，性能最強
• 不依賴數(shù)據(jù)庫事務，而是依賴補償操作，可以用于非事務型數(shù)據(jù)庫

缺點：

• TCC 是一種侵入式的分布式事務解決方案，需要業(yè)務系統(tǒng)自行實現(xiàn) Try，Confirm，Cancel 三個操作，對業(yè)務系統(tǒng)有著非常大的入侵性，設計相對復雜
• 軟狀態(tài)，事務是最終一致
• 需要考慮 Confirm 和Cancel 的失敗情況，做好冪等處理

3.2?TCC 模式原理

在兩階段提交協(xié)議中，資源管理器（RM, Resource Manager）需要提供“準備”、“提交”和“回滾” 3 個操作；而事務管理器（TM, Transaction Manager）分 2 階段協(xié)調(diào)所有資源管理器，在第一階段詢問所有資源管理器“準備”是否成功，如果所有資源均“準備”成功則在第二階段執(zhí)行所有資源的“提交”操作，否則在第二階段執(zhí)行所有資源的“回滾”操作，保證所有資源的最終狀態(tài)是一致的，要么全部提交要么全部回滾。

資源管理器有很多實現(xiàn)方式，其中 TCC（Try-Confirm-Cancel）是資源管理器的一種服務化的實現(xiàn)；TCC 是一種比較成熟的分布式事務解決方案，可用于解決跨數(shù)據(jù)庫、跨服務業(yè)務操作的數(shù)據(jù)一致性問題；TCC 其 Try、Confirm、Cancel 3 個方法均由業(yè)務編碼實現(xiàn)，故 TCC 可以被稱為是服務化的資源管理器。

TCC 的 Try 操作作為一階段，負責資源的檢查和預留；Confirm 操作作為二階段提交操作，執(zhí)行真正的業(yè)務；Cancel 是二階段回滾操作，執(zhí)行預留資源的取消，使資源回到初始狀態(tài)。

3.3?TCC 模式實現(xiàn)

聲明接口：

@LocalTCC
public interface TccService {

    /**
     * 一階段try邏輯
     */
    @TwoPhaseBusinessAction(name = "prepare", commitMethod = "commit", rollbackMethod = "rollback")
    void prepare(@BusinessActionContextParameter(paramName = "param") String param);

    /**
     * 二階段提交方法
     */
    boolean commit(BusinessActionContext context);

    /**
     * 二階段回滾方法
     */
    boolean rollback(BusinessActionContext context);
}

具體業(yè)務邏輯可以在該接口的實現(xiàn)類中完成。

TCC 模式問題：

• 空回滾：當某分支事務的 try 階段阻塞時，可能導致全局事務超時而觸發(fā)二階段的 cancel 操作。在未執(zhí)行 try 操作時先執(zhí)行了 cancel 操作，這時 cancel 不能做回滾，就是空回滾。
• 業(yè)務懸掛：對于已經(jīng)空回滾的業(yè)務，如果以后繼續(xù)執(zhí)行 try，就永遠不可能 confirm 或 cancel，這就是業(yè)務懸掛。應當阻止執(zhí)行空回滾后的 try 操作，避免懸掛。

四、Seata Saga 模式

4.1?Saga 模式簡介

（1）Saga 模式

Saga 模式是 Seata 提供的長事務解決方案，在 Saga 模式中，業(yè)務流程中每個參與者都提交本地事務，當出現(xiàn)某一個參與者失敗則補償前面已經(jīng)成功的參與者，一階段正向服務和二階段補償服務都由業(yè)務開發(fā)實現(xiàn)。

適用場景：

• 業(yè)務流程長、業(yè)務流程多
• 參與者包含其它公司或遺留系統(tǒng)服務，無法提供 TCC 模式要求的三個接口

（2）優(yōu)缺點

優(yōu)勢：

• 一階段提交本地事務，無鎖，高性能
• 事件驅(qū)動架構，參與者可異步執(zhí)行，高吞吐
• 補償服務易于實現(xiàn)

缺點：

• 不保證隔離性

4.2?Saga 模式原理

目前 Seata 提供的 Saga 模式是基于狀態(tài)機引擎來實現(xiàn)的，機制是：

• 通過狀態(tài)圖來定義服務調(diào)用的流程并生成 json 狀態(tài)語言定義文件
• 狀態(tài)圖中一個節(jié)點可以是調(diào)用一個服務，節(jié)點可以配置它的補償節(jié)點
• 狀態(tài)圖 json 由狀態(tài)機引擎驅(qū)動執(zhí)行，當出現(xiàn)異常時狀態(tài)引擎反向執(zhí)行已成功節(jié)點對應的補償節(jié)點將事務回滾
• 可以實現(xiàn)服務編排需求，支持單項選擇、并發(fā)、子流程、參數(shù)轉(zhuǎn)換、參數(shù)映射、服務執(zhí)行狀態(tài)判斷、異常捕獲等功能

五、Seata 模式對比

到了這里，關于Apache Seata -- 一款開源的分布式事務解決方案的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！