什么是Seata？

Seata 是一款開源的分布式事務(wù)解決方案，致力于提供高性能和簡單易用的分布式事務(wù)服務(wù)馋劈。Seata 將為用戶提供了 AT攻锰、TCC、SAGA 和 XA 事務(wù)模式妓雾，為用戶打造一站式的分布式解決方案娶吞。

Seata 支持的事務(wù)模式有四種分別是:

• AT模式
• TCC模式
• saga模式
• XA模式

先了解下Seata中的三個核心概念：
TC(Transaction Coordinator) - 事務(wù)協(xié)調(diào)者：維護全局和分支事務(wù)的狀態(tài)，驅(qū)動全局事務(wù)提交或回滾
TM (Transaction Manager) - 事務(wù)管理器：定義全局事務(wù)的范圍械姻，開始全局事務(wù)寝志、提交或回滾全局事務(wù)
RM ( Resource Manager ) - 資源管理器：管理分支事務(wù)處理的資源( Resource )，與 TC 交談以注冊分支事務(wù)和報告分支事務(wù)的狀態(tài)策添，并驅(qū)動分支事務(wù)提交或回滾
其中材部，TC 為單獨部署的 Server 服務(wù)端，TM 和 RM 為嵌入到應(yīng)用中的 Client 客戶端唯竹。

搭建 Seata 服務(wù)端

https://github.com/seata/seata

代碼下載解壓后乐导，兩個地方配置做更改：

1. 首先配置 file.conf 文件
   file.conf 中配置 TC 的存儲模式，TC 的存儲模式有三種：

• file：適合單機模式浸颓，全局事務(wù)會話信息在內(nèi)存中讀寫物臂，并持久化本地文件 root.data，性能較高产上。
• db：適合集群模式棵磷，全局事務(wù)會話信息通過 db 共享，相對性能差點晋涣。
• redis：適合集群模式仪媒，全局事務(wù)會話信息通過 redis 共享，相對性能好點谢鹊，但是要注意算吩，redis 模式在 Seata-Server 1.3 及以上版本支持，性能較高佃扼，不過存在事務(wù)信息丟失的風(fēng)險偎巢，所以需要開發(fā)者提前配置適合當(dāng)前場景的 redis 持久化配置。
  這里我們?yōu)榱耸∈录嬉渲脼?file 模式压昼，這樣事務(wù)會話信息讀寫在內(nèi)存中完成，持久化則寫到本地 file瘤运，如下圖：
  
  image.png
  
  如果配置 db 或者 redis 模式窍霞，大家記得填一下下面的相關(guān)信息。具體如下圖：
  
  image.png
  
  注意尽超，如果使用 db 模式官撼，需要提前準(zhǔn)備好數(shù)據(jù)庫腳本，如下:

CREATE DATABASE /*!32312 IF NOT EXISTS*/`seata2` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ /*!80016 DEFAULT ENCRYPTION='N' */;

USE `seata2`;

/*Table structure for table `branch_table` */

DROP TABLE IF EXISTS `branch_table`;

CREATE TABLE `branch_table` (
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(128) NOT NULL,
  `transaction_id` bigint(20) DEFAULT NULL,
  `resource_group_id` varchar(32) DEFAULT NULL,
  `resource_id` varchar(256) DEFAULT NULL,
  `branch_type` varchar(8) DEFAULT NULL,
  `status` tinyint(4) DEFAULT NULL,
  `client_id` varchar(64) DEFAULT NULL,
  `application_data` varchar(2000) DEFAULT NULL,
  `gmt_create` datetime(6) DEFAULT NULL,
  `gmt_modified` datetime(6) DEFAULT NULL,
  PRIMARY KEY (`branch_id`),
  KEY `idx_xid` (`xid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

/*Data for the table `branch_table` */
/*Table structure for table `global_table` */

DROP TABLE IF EXISTS `global_table`;

CREATE TABLE `global_table` (
  `xid` varchar(128) NOT NULL,
  `transaction_id` bigint(20) DEFAULT NULL,
  `status` tinyint(4) NOT NULL,
  `application_id` varchar(32) DEFAULT NULL,
  `transaction_service_group` varchar(32) DEFAULT NULL,
  `transaction_name` varchar(128) DEFAULT NULL,
  `timeout` int(11) DEFAULT NULL,
  `begin_time` bigint(20) DEFAULT NULL,
  `application_data` varchar(2000) DEFAULT NULL,
  `gmt_create` datetime DEFAULT NULL,
  `gmt_modified` datetime DEFAULT NULL,
  PRIMARY KEY (`xid`),
  KEY `idx_gmt_modified_status` (`gmt_modified`,`status`),
  KEY `idx_transaction_id` (`transaction_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

/*Data for the table `global_table` */

/*Table structure for table `lock_table` */

DROP TABLE IF EXISTS `lock_table`;
CREATE TABLE `lock_table` (
  `row_key` varchar(128) NOT NULL,
  `xid` varchar(128) DEFAULT NULL,
  `transaction_id` bigint(20) DEFAULT NULL,
  `branch_id` bigint(20) NOT NULL,
  `resource_id` varchar(256) DEFAULT NULL,
  `table_name` varchar(32) DEFAULT NULL,
  `pk` varchar(36) DEFAULT NULL,
  `gmt_create` datetime DEFAULT NULL,
  `gmt_modified` datetime DEFAULT NULL,
  PRIMARY KEY (`row_key`),
  KEY `idx_branch_id` (`branch_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

2. 再配置 registry.conf 文件
   registry.conf 主要配置 Seata 的注冊中心似谁，我們這里采用大家比較熟悉的 Eureka傲绣，配置如下：

   
   
   image.png
   
   

   可以看到掠哥，支持的配置中心比較多，我們選擇 Eureka秃诵，選好配置中心之后续搀，記得修改配置中心相關(guān)的信息。

項目配置

Seata 官方提供了一個非常經(jīng)典的 Demo菠净，我們直接來看如下AT模式的 Demo禁舷。

官方案例下載地址：https://github.com/seata/seata-samples

不過這里是很多案例混在一起的，可能看起來會比較亂毅往，而且由于要下載的依賴比較多牵咙，所以極有可能依賴下載失敗，因此大家也可以在公眾號后臺回復(fù) seata-demo 獲取松哥整理好的案例攀唯，直接導(dǎo)入即可洁桌，如下圖：

image.png

這是一個商品下單的案例，我來和大家稍微解釋下：

• eureka：這是服務(wù)注冊中心侯嘀。
• account：這是賬戶服務(wù)另凌，可以查詢/修改用戶的賬戶信息（主要是賬戶余額）。
• order：這是訂單服務(wù)戒幔，可以下訂單吠谢。
• storage：這是一個倉儲服務(wù)，可以查詢/修改商品的庫存數(shù)量诗茎。

• bussiness：這是業(yè)務(wù)工坊，用戶下單操作將在這里完成
  這個案例表述的內(nèi)容是：
  當(dāng)用戶想要下單的時候，調(diào)用了 bussiness 中的接口错沃，bussiness 中的接口又調(diào)用了它自己的 service栅组，在 service 中，首先開啟了全局分布式事務(wù)枢析，然后通過 feign 調(diào)用 storage 中的接口去扣庫存，然后再通過 feign 調(diào)用 order 中的接口去創(chuàng)建訂單（order 在創(chuàng)建訂單的時候，不僅會創(chuàng)建訂單，還會扣除用戶賬戶的余額）棍弄，在扣除庫存并完成訂單創(chuàng)建之后咏尝，接下來會去檢查用戶的余額和庫存數(shù)量是否正確，如果用戶余額為負數(shù)或者庫存數(shù)量為負數(shù)古戴，則會進行事務(wù)回滾，否則提交事務(wù)。
  本案例具體架構(gòu)如下圖：

  
  
  image.png
  
  

  這個案例就是一個典型的分布式事務(wù)問題饮睬，storage 和 order 中的事務(wù)分屬于不同的微服務(wù)，但是我們希望他們同時成功或者同時失敗篮奄。
  現(xiàn)在大家明白了這個案例是干嘛的捆愁，我們就來把它跑起來割去。
  首先創(chuàng)建一個名為 seata 的數(shù)據(jù)庫，然后執(zhí)行上面代碼中的 all.sql 數(shù)據(jù)腳本昼丑。
  接下來用 idea 打開上面這個項目呻逆，在每一個項目的 application.properties 文件中（Eureka 不用改），修改數(shù)據(jù)的連接信息菩帝，如下圖：

  
  
  image.png

啟動測試

首先啟動 Eureka咖城。
接下來先別記著啟動其他服務(wù)，先啟動 Seata Server呼奢，也就是我們第二小節(jié)配置的那個服務(wù)宜雀，在它的 bin 目錄下
最后再分別啟動剩下的四個服務(wù)，啟動完成后握础，我們可以在 Eureka 中查看相關(guān)信息

image.png

可以看到州袒，各個服務(wù)都注冊上來了。

接下來我們訪問 bussiness 中提供的兩個測試接口弓候。
第一個測試接口是：
http://127.0.0.1:8084/purchase/commit
這個接口對應(yīng)的代碼是：io.seata.sample.controller.BusinessController#purchaseCommit郎哭，這個地方是模擬 U100000 用戶購買了 30 個 C100000 商品，每個商品的價格是 100菇存，商品庫存是 200夸研，用戶賬戶余額是 10000，所以購買之后依鸥，商品庫存變?yōu)?170亥至，用戶賬戶余額變?yōu)?7000。這是正常購買的情況贱迟。

@RequestMapping(value = "/purchase/commit", produces = "application/json")
public String purchaseCommit() {
    try {
        businessService.purchase("U100000", "C100000", 30);
    } catch (Exception exx) {
        return exx.getMessage();
    }
    return "全局事務(wù)提交";
}

當(dāng)我們調(diào)完這個接口之后姐扮，就可以去數(shù)據(jù)庫查看相應(yīng)的數(shù)據(jù)。

第二個測試的接口是：
http://127.0.0.1:8084/purchase/rollback

這個接口對應(yīng)的代碼是：io.seata.sample.controller.BusinessController#purchaseRollback衣吠，這次是模擬用戶購買 99999 個商品茶敏，無論是用戶賬戶余額還是商品庫存數(shù)量，都無法支撐這次購買行為缚俏，因此這個接口的調(diào)用最終會回滾惊搏，數(shù)據(jù)庫中的數(shù)據(jù)會保持原樣。

@RequestMapping("/purchase/rollback")
public String purchaseRollback() {
    try {
        businessService.purchase("U100000", "C100000", 99999);
    } catch (Exception exx) {
        return exx.getMessage();
    }
    return "全局事務(wù)提交";
}

小伙伴們感興趣也可以研究一下官方這個案例忧换，我們會發(fā)現(xiàn)這里的東西非常簡單恬惯，單純是如下方法上多了一個注解而已(io.seata.sample.service.BusinessService#purchase)：

@GlobalTransactional
public void purchase(String userId, String commodityCode, int orderCount) {
    storageFeignClient.deduct(commodityCode, orderCount);
    orderFeignClient.create(userId, commodityCode, orderCount);
    if (!validData()) {
        throw new RuntimeException("賬戶或庫存不足,執(zhí)行回滾");
    }
}

purchase 方法用 @GlobalTransactional 注解標(biāo)記了下，就開啟了全局事務(wù)了亚茬，里邊的兩個調(diào)用都是 feign 的調(diào)用酪耳，對應(yīng)了不同的服務(wù)，最后再做一個數(shù)據(jù)校驗刹缝，校驗失敗就拋出異常碗暗，一旦該方法拋出異常颈将，上面已經(jīng)執(zhí)行的代碼就會回滾。

實現(xiàn)原理

image.png

這張圖非常清晰的描述了上面的案例讹堤，大致流程如下：

有三個概念：TM吆鹤、RM、TC洲守，這些我們在第一小節(jié)已經(jīng)介紹過了疑务，這里就不再贅述。

• 首先由 Business 開啟全局事務(wù)梗醇。
• 接下來 Business 在調(diào)用 Storage 和 Order 的時候知允，這兩個在數(shù)據(jù)庫操作之前都會向 TC 注冊一個分支事務(wù)并提交。
• 分支事務(wù)在操作時叙谨，都會向 undo_log 表中提交一條記錄温鸽，當(dāng)全局事務(wù)提交的時候會清空 undo_log 表中的記錄，否則將以該表中的記錄為依據(jù)進行反向補償（將數(shù)據(jù)恢復(fù)原樣）手负。
  具體到上面的案例涤垫，事務(wù)提交分兩個階段，過程如下：

一階段：

1. 首先 Business 開啟全局事務(wù)竟终，這個過程中會向 TC 注冊蝠猬，然后會拿到一個 xid，這是一個全局事務(wù) id统捶。
2. 接下來在 Business 中調(diào)用 Storage 微服務(wù)榆芦。
3. 來解析 SQL：得到 SQL 的類型（UPDATE），表（storage_tbl）喘鸟，條件（where commodity_code = 'C100000'）等相關(guān)的信息匆绣。

4. 查詢前鏡像：根據(jù)解析得到的條件信息，生成查詢語句什黑，定位數(shù)據(jù)崎淳。

   
   
   image.png
5. 執(zhí)行業(yè)務(wù) SQL，也就是做真正的數(shù)據(jù)更新操作兑凿。

6. 查詢后鏡像：根據(jù)前鏡像的結(jié)果凯力，通過主鍵定位數(shù)據(jù)。

   
   
   image.png
7. 插入回滾日志：把前后鏡像數(shù)據(jù)以及業(yè)務(wù) SQL 相關(guān)的信息組成一條回滾日志記錄礼华，插入到 UNDO_LOG 表中。
   branch_id 和 xid 分別表示分支事務(wù)（即 Storage 自己的事務(wù)）和全局事務(wù)的 id拗秘，rollback_info 中保存著前后鏡像的內(nèi)容圣絮，這個將作為反向補償（回滾）的依據(jù)，這個字段的值是一個 JSON雕旨，松哥挑出來這個 JSON 中比較重要的一部分來和大家分享：

• beforeImage：這個是修改前數(shù)據(jù)庫中的數(shù)據(jù)扮匠，可以看到每個字段的值捧请，id 為 4，count 的值為 200棒搜。

• afterImage：這個是修改后數(shù)據(jù)庫中的數(shù)據(jù)疹蛉，可以看到，此時 id 為 4力麸，count 的值為 170可款。

  
  
  image.png
  
  
  image.png

8. Storage 在提交前，會向 TC 注冊分支：申請 storage_tbl 表中克蚂，主鍵值等于 4 的記錄的全局鎖闺鲸。
9. 本地事務(wù)提交：業(yè)務(wù)數(shù)據(jù)的更新和前面步驟中生成的 UNDO LOG 一并提交。
10. 同理埃叭，Order 和 Account 也按照上面的步驟提交數(shù)據(jù)摸恍。
    以上 1-10 步就是一階段的數(shù)據(jù)提交。

再來看二階段：

二階段有兩種可能赤屋，提交或者回滾立镶。

還是以上面的案例為例：

@GlobalTransactional
public void purchase(String userId, String commodityCode, int orderCount) {
    storageFeignClient.deduct(commodityCode, orderCount);
    orderFeignClient.create(userId, commodityCode, orderCount);
    if (!validData()) {
        throw new RuntimeException("賬戶或庫存不足,執(zhí)行回滾");
    }
}

下單時候，扣除了庫存类早，并且創(chuàng)建了訂單媚媒，最后一檢查，發(fā)現(xiàn)庫存為負數(shù)或者用戶賬戶余額為負數(shù)莺奔，說明這個訂單有問題欣范，此時就該拋異常回滾令哟，否則就提交數(shù)據(jù)恼琼。

具體操作如下：
回滾：

1. 收到 TC 的分支回滾請求，開啟一個本地事務(wù)屏富，執(zhí)行如下操作晴竞。
2. 通過 xid 和 branch_id 去 undo_log 表中查找對應(yīng)的記錄。
3. 數(shù)據(jù)校驗：拿第二步查找到的后鏡與當(dāng)前數(shù)據(jù)進行比較狠半，如果有不同噩死，說明數(shù)據(jù)被當(dāng)前全局事務(wù)之外的動作做了修改。這種情況神年，需要根據(jù)配置策略來做處理已维。
4. 第三步的比較如果相同，則根據(jù) undo_log 中的前鏡像和業(yè)務(wù) SQL 的相關(guān)信息生成并執(zhí)行回滾的語句已日。
5. 提交本地事務(wù)垛耳。并把本地事務(wù)的執(zhí)行結(jié)果（即分支事務(wù)回滾的結(jié)果）上報給 TC。

提交：

1. 收到 TC 的分支提交請求，把請求放入一個異步任務(wù)的隊列中堂鲜，馬上返回提交成功的結(jié)果給 TC栈雳。
2. 異步任務(wù)階段的分支提交請求將異步和批量地刪除相應(yīng) UNDO LOG 記錄。

換句話說缔莲，事務(wù)如果正常提交了哥纫，undo_log 表中是沒有記錄的，如果大家想看該表中的記錄痴奏，可以在事務(wù)提交之前通過 DEBUG 的方式查看蛀骇。