五分鐘帶你體驗一把分佈式事務！so easy！

@[toc] 網上關於分佈式事務講理論的多，講實戰的少，今天我想通過一個案例，來讓小夥伴們感受一把分佈式事務，咱們今天儘量少談點理論。咱們今天的主角是 Seata！

分佈式事務涉及到很多理論，如 CAP，BASE 等，很多小夥伴剛看到這些理論就被勸退了，所以我們今天不講理論，咱們就看個 Demo，通過代碼快速體驗一把什麼是分佈式事務。

1. 什麼是 Seata？

Seata 是一款開源的分佈式事務解決方案，致力於提供高性能和簡單易用的分佈式事務服務。Seata 將爲用戶提供了 AT、TCC、SAGA 和 XA 事務模式，爲用戶打造一站式的分佈式解決方案。

Seata 支持的事務模式有四種分別是:

Seata AT 模式
Seata TCC 模式
Seata Saga 模式
Seata XA 模式

Seata 中有三個核心概念：

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

其中，TC 爲單獨部署的 Server 服務端，TM 和 RM 爲嵌入到應用中的 Client 客戶端。

這些概念小夥伴們作爲一個瞭解即可，不瞭解也能用 Seata，瞭解了更能理解 Seata 的工作原理。

2. 搭建 Seata 服務端

我們先來把 Seata 服務端搭建起來。

Seata 下載地址：

https://github.com/seata/seata/releases

目前最新版本是 1.4.2，我們就使用最新版本來做。

這個工具在 Windows 或者 Linux 上部署差別不大，所以我這裏就直接部署在 Windows 上了，方便一些。

我們首先下載 1.4.2 版本的 zip 壓縮包，下載之後解壓，然後在 conf 目錄中配置兩個地方：

首先配置 file.conf 文件

file.conf 中配置 TC 的存儲模式，TC 的存儲模式有三種：

file：適合單機模式，全局事務會話信息在內存中讀寫，並持久化本地文件 root.data，性能較高。
db：適合集羣模式，全局事務會話信息通過 db 共享，相對性能差點。
redis：適合集羣模式，全局事務會話信息通過 redis 共享，相對性能好點，但是要注意，redis 模式在 Seata-Server 1.3 及以上版本支持，性能較高，不過存在事務信息丟失的風險，所以需要開發者提前配置適合當前場景的 redis 持久化配置。

這裏我們爲了省事，配置爲 file 模式，這樣事務會話信息讀寫在內存中完成，持久化則寫到本地 file，如下圖：

如果配置 db 或者 redis 模式，大家記得填一下下面的相關信息。具體如下圖：

題外話

注意，如果使用 db 模式，需要提前準備好數據庫腳本，如下（小夥伴們可以直接在公衆號江南一點雨後臺回覆 seata-db 下載這個數據庫腳本）：

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;

另外還需要注意的是自己的數據庫版本信息，改數據庫連接的時候按照實際情況修改，Seata 針對 MySQL5.x 和 MySQL8.x 都提供了對應的數據庫驅動（在 lib 目錄下），我們只需要把驅動改好就行了。

再配置 registry.conf 文件

registry.conf 主要配置 Seata 的註冊中心，我們這裏採用大家比較熟悉的 Eureka，配置如下：

可以看到，支持的配置中心比較多，我們選擇 Eureka，選好配置中心之後，記得修改配置中心相關的信息。

OK，現在就配置完成了，但是先別啓動，還差一個 Eureka 註冊中心。

3. 項目配置

接下來我們配置項目。

Seata 官方提供了一個非常經典的 Demo，我們直接來看這個 Demo。

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

不過這裏是很多案例混在一起的，可能看起來會比較亂，而且由於要下載的依賴比較多，所以極有可能依賴下載失敗，因此大家也可以在公衆號後臺回覆 seata-demo 獲取松哥整理好的案例，直接導入即可，如下圖：

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

eureka：這是服務註冊中心。
account：這是賬戶服務，可以查詢/修改用戶的賬戶信息（主要是賬戶餘額）。
order：這是訂單服務，可以下訂單。
storage：這是一個倉儲服務，可以查詢/修改商品的庫存數量。
bussiness：這是業務，用戶下單操作將在這裏完成。

這個案例講了一個什麼事呢？

當用戶想要下單的時候，調用了 bussiness 中的接口，bussiness 中的接口又調用了它自己的 service，在 service 中，首先開啓了全局分佈式事務，然後通過 feign 調用 storage 中的接口去扣庫存，然後再通過 feign 調用 order 中的接口去創建訂單（order 在創建訂單的時候，不僅會創建訂單，還會扣除用戶賬戶的餘額），在扣除庫存並完成訂單創建之後，接下來會去檢查用戶的餘額和庫存數量是否正確，如果用戶餘額爲負數或者庫存數量爲負數，則會進行事務回滾，否則提交事務。

本案例具體架構如下圖：

這個案例就是一個典型的分佈式事務問題，storage 和 order 中的事務分屬於不同的微服務，但是我們希望他們同時成功或者同時失敗。

現在大家明白了這個案例是幹嘛的，我們就來把它跑起來。

首先創建一個名爲 seata 的數據庫，然後執行上面代碼中的 all.sql 數據腳本。

接下來用 idea 打開上面這個項目，在每一個項目的 application.properties 文件中（Eureka 不用改），修改數據的連接信息，如下圖：

除了 Eureka 之外，另外四個都要改哦。

OK，配置結束。

4. 啓動測試

首先啓動 Eureka。

接下來先別記着啓動其他服務，先啓動 Seata Server，也就是我們第二小節配置的那個服務，在它的 bin 目錄下，Windows 下雙擊/Linux 下執行啓動腳本。

最後再分別啓動剩下的四個服務，啓動完成後，我們可以在 Eureka 中查看相關信息：

可以看到，各個服務都註冊上來了。

接下來我們訪問 bussiness 中提供的兩個測試接口。

第一個測試接口是：

http://127.0.0.1:8084/purchase/commit

這個接口對應的代碼是：io.seata.sample.controller.BusinessController#purchaseCommit，這個地方是模擬 U100000 用戶購買了 30 個 C100000 商品，每個商品的價格是 100，商品庫存是 200，用戶賬戶餘額是 10000，所以購買之後，商品庫存變爲 170，用戶賬戶餘額變爲 7000。這是正常購買的情況。

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

當我們調完這個接口之後，就可以去數據庫查看相應的數據。

第二個測試的接口是：

http://127.0.0.1:8084/purchase/rollback

這個接口對應的代碼是：io.seata.sample.controller.BusinessController#purchaseRollback，這次是模擬用戶購買 99999 個商品，無論是用戶賬戶餘額還是商品庫存數量，都無法支撐這次購買行爲，因此這個接口的調用最終會回滾，數據庫中的數據會保持原樣。

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

這就是一個分佈式事務案例。

小夥伴們感興趣也可以研究一下官方這個案例，我們會發現這裏的東西非常簡單，單純是如下方法上多了一個註解而已(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("賬戶或庫存不足,執行回滾");
    }
}

purchase 方法用 @GlobalTransactional 註解標記了下，就開啓了全局事務了，裏邊的兩個調用都是 feign 的調用，對應了不同的服務，最後再做一個數據校驗，校驗失敗就拋出異常，一旦該方法拋出異常，上面已經執行的代碼就會回滾。

這個項目其餘的代碼都是微服務中的常規代碼，就不贅述了。

5. 實現原理

我們稍微來說下 Seata 中這個分佈式事務的原理，先來看一張圖：

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

有三個概念：TM、RM、TC，這些我們在第一小節已經介紹過了，這裏就不再贅述。
首先由 Business 開啓全局事務。
接下來 Business 在調用 Storage 和 Order 的時候，這兩個在數據庫操作之前都會向 TC 註冊一個分支事務並提交。
分支事務在操作時，都會向 undo_log 表中提交一條記錄，當全局事務提交的時候會清空 undo_log 表中的記錄，否則將以該表中的記錄爲依據進行反向補償（將數據恢復原樣）。

具體到上面的案例，事務提交分兩個階段，過程如下：

一階段：

首先 Business 開啓全局事務，這個過程中會向 TC 註冊，然後會拿到一個 xid，這是一個全局事務 id。
接下來在 Business 中調用 Storage 微服務。
來解析 SQL：得到 SQL 的類型（UPDATE），表（storage_tbl），條件（where commodity_code = 'C100000'）等相關的信息。
查詢前鏡像：根據解析得到的條件信息，生成查詢語句，定位數據。

執行業務 SQL，也就是做真正的數據更新操作。
查詢後鏡像：根據前鏡像的結果，通過主鍵定位數據。

插入回滾日誌：把前後鏡像數據以及業務 SQL 相關的信息組成一條回滾日誌記錄，插入到 UNDO_LOG 表中。

branch_id 和 xid 分別表示分支事務（即 Storage 自己的事務）和全局事務的 id，rollback_info 中保存着前後鏡像的內容，這個將作爲反向補償（回滾）的依據，這個字段的值是一個 JSON，松哥挑出來這個 JSON 中比較重要的一部分來和大家分享：

beforeImage：這個是修改前數據庫中的數據，可以看到每個字段的值，id 爲 4，count 的值爲 200。
afterImage：這個是修改後數據庫中的數據，可以看到，此時 id 爲 4，count 的值爲 170。

Storage 在提交前，會向 TC 註冊分支：申請 storage_tbl 表中，主鍵值等於 4 的記錄的全局鎖。
本地事務提交：業務數據的更新和前面步驟中生成的 UNDO LOG 一併提交。
同理，Order 和 Account 也按照上面的步驟提交數據。

以上 1-10 步就是一階段的數據提交。

再來看二階段：

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

還是以上面的案例爲例：

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

下單時候，扣除了庫存，並且創建了訂單，最後一檢查，發現庫存爲負數或者用戶賬戶餘額爲負數，說明這個訂單有問題，此時就該拋異常回滾，否則就提交數據。

具體操作如下：

回滾：

收到 TC 的分支回滾請求，開啓一個本地事務，執行如下操作。
通過 xid 和 branch_id 去 undo_log 表中查找對應的記錄。
數據校驗：拿第二步查找到的後鏡與當前數據進行比較，如果有不同，說明數據被當前全局事務之外的動作做了修改。這種情況，需要根據配置策略來做處理。
第三步的比較如果相同，則根據 undo_log 中的前鏡像和業務 SQL 的相關信息生成並執行回滾的語句。
提交本地事務。並把本地事務的執行結果（即分支事務回滾的結果）上報給 TC。

提交：

收到 TC 的分支提交請求，把請求放入一個異步任務的隊列中，馬上返回提交成功的結果給 TC。
異步任務階段的分支提交請求將異步和批量地刪除相應 UNDO LOG 記錄。

換句話說，事務如果正常提交了，undo_log 表中是沒有記錄的，如果大家想看該表中的記錄，可以在事務提交之前通過 DEBUG 的方式查看。

6. 小結

講了這麼多，是不是就把 Seata 講完了呢？NONONO！這只是 AT 模式而已！還有三種模式，松哥下篇文章再和小夥伴們分享。

好啦，這就是一個簡單的分佈式事務，小夥伴們先來感受一把！標題是五分鐘感受一把分佈式事務，因爲文章裏邊我還和大家分享了原理，如果大家只是跑一下案例感受，五分鐘應該夠了，不信試試！

五分鐘帶你體驗一把分佈式事務！so easy！

1. 什麼是 Seata？

2. 搭建 Seata 服務端

3. 項目配置

4. 啓動測試

5. 實現原理

6. 小結

推薦2款開源、美觀的WinForm UI控件庫

NET9 AspnetCore將整合OpenAPI的文檔生成功能而無需三方庫

在Linux下管理MySQL的大小寫敏感性

鯤鵬平臺的銀河麒麟，修復音頻

定時清理服務器上log文件，清理docker日誌文件

安裝筆記本應用商店的pycharm，再安排pandas等模塊，說是沒有打包工具?

智能測試持續加碼，大模型引領軟件測試新生態

DevExpress Office File API中文教程 - 如何用OpenAI模型增強Office文檔可訪問性？

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結