五分鐘帶你體驗一把分布式事務！so easy！
網上關于分布式事務講理論的多，講實戰的少，今天我想通過一個案例，來讓小伙伴們感受一把分布式事務，咱們今天盡量少談點理論。咱們今天的主角是 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 目錄中配置兩個地方：
1. 首先配置 file.conf 文件
file.conf 中配置 TC 的存儲模式，TC 的存儲模式有三種：
-
file：適合單機模式，全局事務會話信息在內存中讀寫，并持久化本地文件 root.data，性能較高。
-
db：適合集群模式，全局事務會話信息通過 db 共享，相對性能差點。
-
redis：適合集群模式，全局事務會話信息通過 redis 共享，相對性能好點，但是要注意，redis 模式在 Seata-Server 1.3 及以上版本支持，性能較高，不過存在事務信息丟失的風險，所以需要開發者提前配置適合當前場景的 redis 持久化配置。
這里我們為了省事，配置為 file 模式，這樣事務會話信息讀寫在內存中完成，持久化則寫到本地 file，如下圖：
如果配置 db 或者 redis 模式，大家記得填一下下面的相關信息。具體如下圖：
另外還需要注意的是自己的數據庫版本信息，改數據庫連接的時候按照實際情況修改，Seata 針對 MySQL5.x 和 MySQL8.x 都提供了對應的數據庫驅動（在 lib 目錄下），我們只需要把驅動改好就行了。
2. 再配置 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 模式而已！還有三種模式，松哥下篇文章再和小伙伴們分享。
好啦，這就是一個簡單的分布式事務，小伙伴們先來感受一把！標題是五分鐘感受一把分布式事務，因為文章里邊我還和大家分享了原理，如果大家只是跑一下案例感受，五分鐘應該夠了，不信試試！
