五分鐘帶你體驗一把分布式事務(wù)！so easy！
網(wǎng)上關(guān)于分布式事務(wù)講理論的多，講實戰(zhàn)的少，今天我想通過一個案例，來讓小伙伴們感受一把分布式事務(wù)，咱們今天盡量少談點理論。咱們今天的主角是 Seata！
分布式事務(wù)涉及到很多理論，如 CAP，BASE 等，很多小伙伴剛看到這些理論就被勸退了，所以我們今天不講理論，咱們就看個 Demo，通過代碼快速體驗一把什么是分布式事務(wù)。
1. 什么是 Seata？
Seata 是一款開源的分布式事務(wù)解決方案，致力于提供高性能和簡單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶打造一站式的分布式解決方案。
Seata 支持的事務(wù)模式有四種分別是:
-
Seata AT 模式
-
Seata TCC 模式
-
Seata Saga 模式
-
Seata 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，了解了更能理解 Seata 的工作原理。
2. 搭建 Seata 服務(wù)端
我們先來把 Seata 服務(wù)端搭建起來。
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：適合單機模式，全局事務(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，如下圖：
如果配置 db 或者 redis 模式，大家記得填一下下面的相關(guān)信息。具體如下圖：
另外還需要注意的是自己的數(shù)據(jù)庫版本信息，改數(shù)據(jù)庫連接的時候按照實際情況修改，Seata 針對 MySQL5.x 和 MySQL8.x 都提供了對應(yīng)的數(shù)據(jù)庫驅(qū)動（在 lib 目錄下），我們只需要把驅(qū)動改好就行了。
2. 再配置 registry.conf 文件
registry.conf 主要配置 Seata 的注冊中心，我們這里采用大家比較熟悉的 Eureka，配置如下：
可以看到，支持的配置中心比較多，我們選擇 Eureka，選好配置中心之后，記得修改配置中心相關(guān)的信息。
OK，現(xiàn)在就配置完成了，但是先別啟動，還差一個 Eureka 注冊中心。
3. 項目配置
接下來我們配置項目。
Seata 官方提供了一個非常經(jīng)典的 Demo，我們直接來看這個 Demo。
官方案例下載地址：https://github.com/seata/seata-samples
不過這里是很多案例混在一起的，可能看起來會比較亂，而且由于要下載的依賴比較多，所以極有可能依賴下載失敗，因此大家也可以在公眾號后臺回復(fù) seata-demo 獲取松哥整理好的案例，直接導(dǎo)入即可，如下圖：
這是一個商品下單的案例，我來和大家稍微解釋下：
-
eureka：這是服務(wù)注冊中心。
-
account：這是賬戶服務(wù)，可以查詢/修改用戶的賬戶信息（主要是賬戶余額）。
-
order：這是訂單服務(wù)，可以下訂單。
-
storage：這是一個倉儲服務(wù)，可以查詢/修改商品的庫存數(shù)量。
-
bussiness：這是業(yè)務(wù)，用戶下單操作將在這里完成。
這個案例講了一個什么事呢？
當(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)如下圖：
這個案例就是一個典型的分布式事務(wù)問題，storage 和 order 中的事務(wù)分屬于不同的微服務(wù)，但是我們希望他們同時成功或者同時失敗。
現(xiàn)在大家明白了這個案例是干嘛的，我們就來把它跑起來。
首先創(chuàng)建一個名為 seata 的數(shù)據(jù)庫，然后執(zhí)行上面代碼中的 all.sql 數(shù)據(jù)腳本。
接下來用 idea 打開上面這個項目，在每一個項目的 application.properties 文件中（Eureka 不用改），修改數(shù)據(jù)的連接信息，如下圖：
除了 Eureka 之外，另外四個都要改哦。
OK，配置結(jié)束。
4. 啟動測試
首先啟動 Eureka。
接下來先別記著啟動其他服務(wù)，先啟動 Seata Server，也就是我們第二小節(jié)配置的那個服務(wù)，在它的 bin 目錄下，Windows 下雙擊/Linux 下執(zhí)行啟動腳本。
最后再分別啟動剩下的四個服務(wù)，啟動完成后，我們可以在 Eureka 中查看相關(guān)信息：
可以看到，各個服務(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)?nbsp;170 ，用戶賬戶余額變?yōu)?nbsp;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ù)提交";
- }
這就是一個分布式事務(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í)行的代碼就會回滾。
這個項目其余的代碼都是微服務(wù)中的常規(guī)代碼，就不贅述了。
5. 實現(xiàn)原理
我們稍微來說下 Seata 中這個分布式事務(wù)的原理，先來看一張圖：
這張圖非常清晰的描述了上面的案例，大致流程如下：
-
有三個概念：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ù)提交分兩個階段，過程如下：
一階段：
-
首先 Business 開啟全局事務(wù)，這個過程中會向 TC 注冊，然后會拿到一個 xid，這是一個全局事務(wù) id。
-
接下來在 Business 中調(diào)用 Storage 微服務(wù)。
-
來解析 SQL：得到 SQL 的類型（UPDATE），表（storage_tbl），條件（where commodity_code = 'C100000'）等相關(guān)的信息。
-
查詢前鏡像：根據(jù)解析得到的條件信息，生成查詢語句，定位數(shù)據(jù)。
-
執(zhí)行業(yè)務(wù) SQL，也就是做真正的數(shù)據(jù)更新操作。
-
查詢后鏡像：根據(jù)前鏡像的結(jié)果，通過 主鍵 定位數(shù)據(jù)。
-
插入回滾日志：把前后鏡像數(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。
-
Storage 在提交前，會向 TC 注冊分支：申請 storage_tbl 表中，主鍵值等于 4 的記錄的全局鎖。
-
本地事務(wù)提交：業(yè)務(wù)數(shù)據(jù)的更新和前面步驟中生成的 UNDO LOG 一并提交。
-
同理，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ù)。
具體操作如下：
回滾：
-
收到 TC 的分支回滾請求，開啟一個本地事務(wù)，執(zhí)行如下操作。
-
通過 xid 和 branch_id 去 undo_log 表中查找對應(yīng)的記錄。
-
數(shù)據(jù)校驗：拿第二步查找到的后鏡與當(dāng)前數(shù)據(jù)進行比較，如果有不同，說明數(shù)據(jù)被當(dāng)前全局事務(wù)之外的動作做了修改。這種情況，需要根據(jù)配置策略來做處理。
-
第三步的比較如果相同，則根據(jù) undo_log 中的前鏡像和業(yè)務(wù) SQL 的相關(guān)信息生成并執(zhí)行回滾的語句。
-
提交本地事務(wù)。并把本地事務(wù)的執(zhí)行結(jié)果（即分支事務(wù)回滾的結(jié)果）上報給 TC。
提交：
-
收到 TC 的分支提交請求，把請求放入一個異步任務(wù)的隊列中，馬上返回提交成功的結(jié)果給 TC。
-
異步任務(wù)階段的分支提交請求將異步和批量地刪除相應(yīng) UNDO LOG 記錄。
換句話說，事務(wù)如果正常提交了，undo_log 表中是沒有記錄的，如果大家想看該表中的記錄，可以在事務(wù)提交之前通過 DEBUG 的方式查看。
6. 小結(jié)
講了這么多，是不是就把 Seata 講完了呢？NONONO！這只是 AT 模式而已！還有三種模式，松哥下篇文章再和小伙伴們分享。
好啦，這就是一個簡單的分布式事務(wù)，小伙伴們先來感受一把！標(biāo)題是五分鐘感受一把分布式事務(wù)，因為文章里邊我還和大家分享了原理，如果大家只是跑一下案例感受，五分鐘應(yīng)該夠了，不信試試！
