五分鐘帶你體驗(yàn)一把分布式事務(wù)！so easy！
網(wǎng)上關(guān)于分布式事務(wù)講理論的多，講實(shí)戰(zhàn)的少，今天我想通過一個(gè)案例，來讓小伙伴們感受一把分布式事務(wù)，咱們今天盡量少談點(diǎn)理論。咱們今天的主角是 Seata！
分布式事務(wù)涉及到很多理論，如 CAP，BASE 等，很多小伙伴剛看到這些理論就被勸退了，所以我們今天不講理論，咱們就看個(gè) Demo，通過代碼快速體驗(yàn)一把什么是分布式事務(wù)。
1. 什么是 Seata？
Seata 是一款開源的分布式事務(wù)解決方案，致力于提供高性能和簡(jiǎn)單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶打造一站式的分布式解決方案。
Seata 支持的事務(wù)模式有四種分別是:
-
Seata AT 模式
-
Seata TCC 模式
-
Seata Saga 模式
-
Seata XA 模式
Seata 中有三個(gè)核心概念：
-
TC (Transaction Coordinator) - 事務(wù)協(xié)調(diào)者：維護(hù)全局和分支事務(wù)的狀態(tài)，驅(qū)動(dòng)全局事務(wù)提交或回滾。
-
TM (Transaction Manager) - 事務(wù)管理器：定義全局事務(wù)的范圍，開始全局事務(wù)、提交或回滾全局事務(wù)。
-
RM ( Resource Manager ) - 資源管理器：管理分支事務(wù)處理的資源( Resource )，與 TC 交談以注冊(cè)分支事務(wù)和報(bào)告分支事務(wù)的狀態(tài)，并驅(qū)動(dòng)分支事務(wù)提交或回滾。
其中，TC 為單獨(dú)部署的 Server 服務(wù)端，TM 和 RM 為嵌入到應(yīng)用中的 Client 客戶端。
這些概念小伙伴們作為一個(gè)了解即可，不了解也能用 Seata，了解了更能理解 Seata 的工作原理。
2. 搭建 Seata 服務(wù)端
我們先來把 Seata 服務(wù)端搭建起來。
Seata 下載地址：
-
https://github.com/seata/seata/releases
目前最新版本是 1.4.2，我們就使用最新版本來做。
這個(gè)工具在 Windows 或者 Linux 上部署差別不大，所以我這里就直接部署在 Windows 上了，方便一些。
我們首先下載 1.4.2 版本的 zip 壓縮包，下載之后解壓，然后在 conf 目錄中配置兩個(gè)地方：
1. 首先配置 file.conf 文件
file.conf 中配置 TC 的存儲(chǔ)模式，TC 的存儲(chǔ)模式有三種：
-
file：適合單機(jī)模式，全局事務(wù)會(huì)話信息在內(nèi)存中讀寫，并持久化本地文件 root.data，性能較高。
-
db：適合集群模式，全局事務(wù)會(huì)話信息通過 db 共享，相對(duì)性能差點(diǎn)。
-
redis：適合集群模式，全局事務(wù)會(huì)話信息通過 redis 共享，相對(duì)性能好點(diǎn)，但是要注意，redis 模式在 Seata-Server 1.3 及以上版本支持，性能較高，不過存在事務(wù)信息丟失的風(fēng)險(xiǎn)，所以需要開發(fā)者提前配置適合當(dāng)前場(chǎng)景的 redis 持久化配置。
這里我們?yōu)榱耸∈?，配置?file 模式，這樣事務(wù)會(huì)話信息讀寫在內(nèi)存中完成，持久化則寫到本地 file，如下圖：
如果配置 db 或者 redis 模式，大家記得填一下下面的相關(guān)信息。具體如下圖：
另外還需要注意的是自己的數(shù)據(jù)庫(kù)版本信息，改數(shù)據(jù)庫(kù)連接的時(shí)候按照實(shí)際情況修改，Seata 針對(duì) MySQL5.x 和 MySQL8.x 都提供了對(duì)應(yīng)的數(shù)據(jù)庫(kù)驅(qū)動(dòng)（在 lib 目錄下），我們只需要把驅(qū)動(dòng)改好就行了。
2. 再配置 registry.conf 文件
registry.conf 主要配置 Seata 的注冊(cè)中心，我們這里采用大家比較熟悉的 Eureka，配置如下：
可以看到，支持的配置中心比較多，我們選擇 Eureka，選好配置中心之后，記得修改配置中心相關(guān)的信息。
OK，現(xiàn)在就配置完成了，但是先別啟動(dòng)，還差一個(gè) Eureka 注冊(cè)中心。
3. 項(xiàng)目配置
接下來我們配置項(xiàng)目。
Seata 官方提供了一個(gè)非常經(jīng)典的 Demo，我們直接來看這個(gè) Demo。
官方案例下載地址：https://github.com/seata/seata-samples
不過這里是很多案例混在一起的，可能看起來會(huì)比較亂，而且由于要下載的依賴比較多，所以極有可能依賴下載失敗，因此大家也可以在公眾號(hào)后臺(tái)回復(fù) seata-demo 獲取松哥整理好的案例，直接導(dǎo)入即可，如下圖：
這是一個(gè)商品下單的案例，我來和大家稍微解釋下：
-
eureka：這是服務(wù)注冊(cè)中心。
-
account：這是賬戶服務(wù)，可以查詢/修改用戶的賬戶信息（主要是賬戶余額）。
-
order：這是訂單服務(wù)，可以下訂單。
-
storage：這是一個(gè)倉(cāng)儲(chǔ)服務(wù)，可以查詢/修改商品的庫(kù)存數(shù)量。
-
bussiness：這是業(yè)務(wù)，用戶下單操作將在這里完成。
這個(gè)案例講了一個(gè)什么事呢？
當(dāng)用戶想要下單的時(shí)候，調(diào)用了 bussiness 中的接口，bussiness 中的接口又調(diào)用了它自己的 service，在 service 中，首先開啟了全局分布式事務(wù)，然后通過 feign 調(diào)用 storage 中的接口去扣庫(kù)存，然后再通過 feign 調(diào)用 order 中的接口去創(chuàng)建訂單（order 在創(chuàng)建訂單的時(shí)候，不僅會(huì)創(chuàng)建訂單，還會(huì)扣除用戶賬戶的余額），在扣除庫(kù)存并完成訂單創(chuàng)建之后，接下來會(huì)去檢查用戶的余額和庫(kù)存數(shù)量是否正確，如果用戶余額為負(fù)數(shù)或者庫(kù)存數(shù)量為負(fù)數(shù)，則會(huì)進(jìn)行事務(wù)回滾，否則提交事務(wù)。
本案例具體架構(gòu)如下圖：
這個(gè)案例就是一個(gè)典型的分布式事務(wù)問題，storage 和 order 中的事務(wù)分屬于不同的微服務(wù)，但是我們希望他們同時(shí)成功或者同時(shí)失敗。
現(xiàn)在大家明白了這個(gè)案例是干嘛的，我們就來把它跑起來。
首先創(chuàng)建一個(gè)名為 seata 的數(shù)據(jù)庫(kù)，然后執(zhí)行上面代碼中的 all.sql 數(shù)據(jù)腳本。
接下來用 idea 打開上面這個(gè)項(xiàng)目，在每一個(gè)項(xiàng)目的 application.properties 文件中（Eureka 不用改），修改數(shù)據(jù)的連接信息，如下圖：
除了 Eureka 之外，另外四個(gè)都要改哦。
OK，配置結(jié)束。
4. 啟動(dòng)測(cè)試
首先啟動(dòng) Eureka。
接下來先別記著啟動(dòng)其他服務(wù)，先啟動(dòng) Seata Server，也就是我們第二小節(jié)配置的那個(gè)服務(wù)，在它的 bin 目錄下，Windows 下雙擊/Linux 下執(zhí)行啟動(dòng)腳本。
最后再分別啟動(dòng)剩下的四個(gè)服務(wù)，啟動(dòng)完成后，我們可以在 Eureka 中查看相關(guān)信息：
可以看到，各個(gè)服務(wù)都注冊(cè)上來了。
接下來我們?cè)L問 bussiness 中提供的兩個(gè)測(cè)試接口。
第一個(gè)測(cè)試接口是：
http://127.0.0.1:8084/purchase/commit
這個(gè)接口對(duì)應(yīng)的代碼是： io.seata.sample.controller.BusinessController#purchaseCommit ，這個(gè)地方是模擬 U100000 用戶購(gòu)買了 30 個(gè) C100000 商品，每個(gè)商品的價(jià)格是 100 ，商品庫(kù)存是 200 ，用戶賬戶余額是 10000 ，所以購(gòu)買之后，商品庫(kù)存變?yōu)?nbsp;170 ，用戶賬戶余額變?yōu)?nbsp;7000 。這是正常購(gòu)買的情況。
- @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)完這個(gè)接口之后，就可以去數(shù)據(jù)庫(kù)查看相應(yīng)的數(shù)據(jù)。
第二個(gè)測(cè)試的接口是：
http://127.0.0.1:8084/purchase/rollback
這個(gè)接口對(duì)應(yīng)的代碼是： io.seata.sample.controller.BusinessController#purchaseRollback ，這次是模擬用戶購(gòu)買 99999 個(gè)商品，無論是用戶賬戶余額還是商品庫(kù)存數(shù)量，都無法支撐這次購(gòu)買行為，因此這個(gè)接口的調(diào)用最終會(huì)回滾，數(shù)據(jù)庫(kù)中的數(shù)據(jù)會(huì)保持原樣。
- @RequestMapping("/purchase/rollback")
- public String purchaseRollback() {
- try {
- businessService.purchase("U100000", "C100000", 99999);
- } catch (Exception exx) {
- return exx.getMessage();
- }
- return "全局事務(wù)提交";
- }
這就是一個(gè)分布式事務(wù)案例。
小伙伴們感興趣也可以研究一下官方這個(gè)案例，我們會(huì)發(fā)現(xiàn)這里的東西非常簡(jiǎn)單，單純是如下方法上多了一個(gè)注解而已( 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("賬戶或庫(kù)存不足,執(zhí)行回滾");
- }
- }
purchase 方法用 @GlobalTransactional 注解標(biāo)記了下，就開啟了全局事務(wù)了，里邊的兩個(gè)調(diào)用都是 feign 的調(diào)用，對(duì)應(yīng)了不同的服務(wù)，最后再做一個(gè)數(shù)據(jù)校驗(yàn)，校驗(yàn)失敗就拋出異常，一旦該方法拋出異常，上面已經(jīng)執(zhí)行的代碼就會(huì)回滾。
這個(gè)項(xiàng)目其余的代碼都是微服務(wù)中的常規(guī)代碼，就不贅述了。
5. 實(shí)現(xiàn)原理
我們稍微來說下 Seata 中這個(gè)分布式事務(wù)的原理，先來看一張圖：
這張圖非常清晰的描述了上面的案例，大致流程如下：
-
有三個(gè)概念：TM、RM、TC，這些我們?cè)诘谝恍」?jié)已經(jīng)介紹過了，這里就不再贅述。
-
首先由 Business 開啟全局事務(wù)。
-
接下來 Business 在調(diào)用 Storage 和 Order 的時(shí)候，這兩個(gè)在數(shù)據(jù)庫(kù)操作之前都會(huì)向 TC 注冊(cè)一個(gè)分支事務(wù)并提交。
-
分支事務(wù)在操作時(shí)，都會(huì)向 undo_log 表中提交一條記錄，當(dāng)全局事務(wù)提交的時(shí)候會(huì)清空 undo_log 表中的記錄，否則將以該表中的記錄為依據(jù)進(jìn)行反向補(bǔ)償（將數(shù)據(jù)恢復(fù)原樣）。
具體到上面的案例，事務(wù)提交分兩個(gè)階段，過程如下：
一階段：
-
首先 Business 開啟全局事務(wù)，這個(gè)過程中會(huì)向 TC 注冊(cè)，然后會(huì)拿到一個(gè) xid，這是一個(gè)全局事務(wù) id。
-
接下來在 Business 中調(diào)用 Storage 微服務(wù)。
-
來解析 SQL：得到 SQL 的類型（UPDATE），表（storage_tbl），條件（where commodity_code = 'C100000'）等相關(guān)的信息。
-
查詢前鏡像：根據(jù)解析得到的條件信息，生成查詢語(yǔ)句，定位數(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)容， 這個(gè)將作為反向補(bǔ)償（回滾）的依據(jù) ，這個(gè)字段的值是一個(gè) JSON，松哥挑出來這個(gè) JSON 中比較重要的一部分來和大家分享：
-
beforeImage：這個(gè)是修改前數(shù)據(jù)庫(kù)中的數(shù)據(jù)，可以看到每個(gè)字段的值，id 為 4，count 的值為 200。
-
afterImage：這個(gè)是修改后數(shù)據(jù)庫(kù)中的數(shù)據(jù)，可以看到，此時(shí) id 為 4，count 的值為 170。
-
Storage 在提交前，會(huì)向 TC 注冊(cè)分支：申請(qǐng) 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("賬戶或庫(kù)存不足,執(zhí)行回滾");
- }
- }
下單時(shí)候，扣除了庫(kù)存，并且創(chuàng)建了訂單，最后一檢查，發(fā)現(xiàn)庫(kù)存為負(fù)數(shù)或者用戶賬戶余額為負(fù)數(shù)，說明這個(gè)訂單有問題，此時(shí)就該拋異?；貪L，否則就提交數(shù)據(jù)。
具體操作如下：
回滾：
-
收到 TC 的分支回滾請(qǐng)求，開啟一個(gè)本地事務(wù)，執(zhí)行如下操作。
-
通過 xid 和 branch_id 去 undo_log 表中查找對(duì)應(yīng)的記錄。
-
數(shù)據(jù)校驗(yàn)：拿第二步查找到的后鏡與當(dāng)前數(shù)據(jù)進(jìn)行比較，如果有不同，說明數(shù)據(jù)被當(dāng)前全局事務(wù)之外的動(dòng)作做了修改。這種情況，需要根據(jù)配置策略來做處理。
-
第三步的比較如果相同，則根據(jù) undo_log 中的前鏡像和業(yè)務(wù) SQL 的相關(guān)信息生成并執(zhí)行回滾的語(yǔ)句。
-
提交本地事務(wù)。并把本地事務(wù)的執(zhí)行結(jié)果（即分支事務(wù)回滾的結(jié)果）上報(bào)給 TC。
提交：
-
收到 TC 的分支提交請(qǐng)求，把請(qǐng)求放入一個(gè)異步任務(wù)的隊(duì)列中，馬上返回提交成功的結(jié)果給 TC。
-
異步任務(wù)階段的分支提交請(qǐng)求將異步和批量地刪除相應(yīng) UNDO LOG 記錄。
換句話說，事務(wù)如果正常提交了，undo_log 表中是沒有記錄的，如果大家想看該表中的記錄，可以在事務(wù)提交之前通過 DEBUG 的方式查看。
6. 小結(jié)
講了這么多，是不是就把 Seata 講完了呢？NONONO！這只是 AT 模式而已！還有三種模式，松哥下篇文章再和小伙伴們分享。
好啦，這就是一個(gè)簡(jiǎn)單的分布式事務(wù)，小伙伴們先來感受一把！標(biāo)題是五分鐘感受一把分布式事務(wù)，因?yàn)槲恼吕镞呂疫€和大家分享了原理，如果大家只是跑一下案例感受，五分鐘應(yīng)該夠了，不信試試！
