一站式分布式事務(wù) Seata 方案
引言
上一篇《如何選擇分布式事務(wù)解決方案？》 綜合比較了各種分布式事務(wù)方案的優(yōu)缺點，并在技術(shù)選型上給出合理化的建議?？紤]到企業(yè)應(yīng)用的普遍性和適用性，今天重點聊聊分布式Seata方案實踐和原理。
Seata 是什么?
Seata 是一款開源的分布式事務(wù)解決方案，致力于提供高性能和簡單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶打造一站式的分布式解決方案。默認(rèn)AT模式。
英文官網(wǎng)：https://seata.io/zh-cn/
中文官網(wǎng)：https://seata.io/zh-cn/
看官網(wǎng)這輕松而有趣的解釋，心中默念：
為探究這個問題，我們嘗試從問題中來，到問題中去。試想：
- 不使用分布式事務(wù)會產(chǎn)生怎樣的結(jié)果？
- 為何選擇Seata方案？
- 這種方案如何實現(xiàn)提交和回滾保證數(shù)據(jù)一致性的？
帶著這些問題，根據(jù)實際應(yīng)用場景逐步探究。。。
業(yè)務(wù)場景
在電商交易系統(tǒng)中，最核心的業(yè)務(wù)場景：下訂單 --> 減庫存 --> 調(diào)支付，要求具備數(shù)據(jù)強一致性。
基本模型如下：
我們要求該場景應(yīng)滿足以下幾個條件：
- 訂單狀態(tài)正常（0-異常，1-正常）
- 庫存不能出現(xiàn)負(fù)數(shù)或者下單了沒有扣庫存
- 保證金額正常支付，不能出現(xiàn)扣款多或者扣款少的情況
業(yè)務(wù)實現(xiàn)
下面我們給出核心代碼描述業(yè)務(wù)過程。
訂單服務(wù)：
public interface OrderService {
/**
* 創(chuàng)建訂單
*/
void create(Order order);
}倉儲服務(wù)：
public interface StorageService {
/**
* 扣減庫存
*/
void deduct(Long productId, Integer count);
}帳戶服務(wù)：
public interface AccountService {
/**
* 扣減賬戶余額
*
* @param userId 用戶id
* @param money 金額
*/
void debit(@RequestParam("userId") Long userId, @RequestParam("money") BigDecimal money);
}這里只給出核心業(yè)務(wù)邏輯說明問題。在訂單業(yè)務(wù)作為核心邏輯，遠(yuǎn)程調(diào)用扣庫存和支付。
public class OrderServiceImpl implements OrderService
{
@Resource
private OrderDao orderDao;
@Resource
private StorageService storageService;
@Resource
private AccountService accountService;
/**
* 創(chuàng)建訂單->調(diào)用庫存服務(wù)扣減庫存->調(diào)用賬戶服務(wù)扣減賬戶余額->修改訂單狀態(tài)
* 簡單說：下訂單->扣庫存->減余額->改狀態(tài)
*/
@Override
//這里先注釋掉，用于比較實用分布式事務(wù)前后的效果
//@GlobalTransactional(name = "fsp-create-order",rollbackFor = Exception.class)
public void create(Order order)
{
//創(chuàng)建訂單
orderDao.create(order);
//2 扣減庫存
storageService.deduct(order.getProductId(),order.getCount());
//3 扣減賬戶金額
accountService.debit(order.getUserId(),order.getMoney());
//4 修改訂單狀態(tài)，從零到1,1代表已經(jīng)完成
orderDao.update(order.getUserId(),0);
}
}未使用分布式事務(wù)前的場景
初始狀態(tài)：
-- 庫存商品：100
mysql> select * from t_storage;
+----+------------+-------+------+---------+
| id | product_id | total | used | residue |
+----+------------+-------+------+---------+
| 1 | 1 | 100 | 0 | 100 |
+----+------------+-------+------+---------+
1 row in set (0.00 sec)
--賬戶余額：1000
mysql> select * from t_account;
+----+---------+-------+------+---------+
| id | user_id | total | used | residue |
+----+---------+-------+------+---------+
| 1 | 1 | 1000 | 0 | 1000 |
+----+---------+-------+------+---------+
1 row in set (0.00 sec)
-- 訂單為空
mysql> select * from t_order;
Empty set (0.00 sec)下面模擬一個賬戶扣減異常（因為OpenFeign的默認(rèn)分別是連接超時時間10秒.這處設(shè)置20秒就是為了挑事兒），然后分別啟動訂單、庫存、賬戶服務(wù)。
/**
* 扣減賬戶余額
*/
@Override
public void debit(Long userId, BigDecimal money) {
LOGGER.info("------->account-service中扣減賬戶余額開始");
//模擬超時異常，全局事務(wù)回滾
//暫停幾秒鐘線程
try { TimeUnit.SECONDS.sleep(20); } catch (InterruptedException e) { e.printStackTrace(); }
accountDao.debit(userId,money);
LOGGER.info("------->account-service中扣減賬戶余額結(jié)束");
}模擬下訂單過程：
http://localhost:2001/order/create?userId=1&productId=1&count=10&mnotallow=100
頁面異常因為賬戶服務(wù)中扣減過程發(fā)生異常。我們再來觀察數(shù)據(jù)庫中的變化情況：
-- 庫存商品：100
mysql> select * from t_storage;
+----+------------+-------+------+---------+
| id | product_id | total | used | residue |
+----+------------+-------+------+---------+
| 1 | 1 | 100 | 10 | 90 |
+----+------------+-------+------+---------+
1 row in set (0.00 sec)
--賬戶余額：1000
mysql> select * from t_account;
+----+---------+-------+------+---------+
| id | user_id | total | used | residue |
+----+---------+-------+------+---------+
| 1 | 1 | 1000 | 0 | 1000 |
+----+---------+-------+------+---------+
1 row in set (0.00 sec)
-- 訂單為空
mysql> select * from t_order;
+----+---------+------------+-------+-------+--------+
| id | user_id | product_id | count | money | status |
+----+---------+------------+-------+-------+--------+
| 3 | 1 | 1 | 10 | 100 | 0 |
+----+---------+------------+-------+-------+--------+
1 row in set (0.00 sec)觀察分析，訂單狀態(tài)：0-異常。庫存較少，但是余額沒有扣減。商家容易哭死。這就使我們不得不做事務(wù)的控制。以達(dá)到數(shù)據(jù)一致性。
Seata方案引入
對此，我們使用分布式事務(wù)Seata的解決方案解決此問題。
圖片來源于官網(wǎng)
為方便測試使用，這里準(zhǔn)備了Seata的一套環(huán)境。并給出相應(yīng)業(yè)務(wù)測試用例SQL。
使用非常簡單。只需要在核心業(yè)務(wù)方法上加一個注解@GlobalTransactional即可。
@Override
@GlobalTransactional(name = "fsp-create-order",rollbackFor = Exception.class)
public void create(Order order)
{
//創(chuàng)建訂單
orderDao.create(order);
//2 扣減庫存
storageService.deduct(order.getProductId(),order.getCount());
//3 扣減賬戶金額
accountService.debit(order.getUserId(),order.getMoney());
//4 修改訂單狀態(tài)，從零到1,1代表已經(jīng)完成
orderDao.update(order.getUserId(),0);
}恢復(fù)數(shù)據(jù)初始狀態(tài)，再次啟動和重復(fù)上述測試步驟。觀察在發(fā)生異常的情況下，數(shù)據(jù)庫還是初始的狀態(tài)（為出現(xiàn)訂單異常和賬戶余額變動的問題）。顯然：這個注解幫助我們：在分布式環(huán)境下，當(dāng)有異常發(fā)生時進(jìn)行全局回滾，以維持?jǐn)?shù)據(jù)的一致狀態(tài)。我們把這種全局意義上控制的事務(wù)成為全局事務(wù)。
Seata執(zhí)行流程及原理
@GlobalTransactional用事實告訴我們：極簡是一種美！
是不是很好奇？
下面究其背后的原理做深層次的探究。
(1) 全局事務(wù)中的角色
- TM 事務(wù)發(fā)起方，是業(yè)務(wù)方法上帶有@GlobalTransactional注解的服務(wù)，如：本案例中訂單服務(wù)。
- TC 事務(wù)協(xié)調(diào)者，可以理解為一個隱形的中間人，負(fù)責(zé)管理事務(wù)。
- TR 事務(wù)參與者：本案例當(dāng)中：訂單、庫存、賬戶都是還是事務(wù)參與者
(2) 全局成功提交流程
(3) 全局失敗回滾流程
下面我們用代碼驗證此過程：
- 啟動nacos；
- 啟動seata；
- debug啟動訂單、庫存、賬戶服務(wù)，斷點跟蹤
查看數(shù)據(jù)庫變化情況（取關(guān)鍵字段信息）：
-- 全局事務(wù)
mysql> select xid,transaction_id,application_id,transaction_service_group,transaction_name from global_table ;
+-------------------------------+----------------+---------------------+---------------------------+------------------+
| xid | transaction_id | application_id | transaction_service_group | transaction_name |
+-------------------------------+----------------+---------------------+---------------------------+------------------+
| 192.168.0.101:8091:2155601919 | 2155601919 | seata-order-service | fsp_tx_group | fsp-create-order |
+-------------------------------+----------------+---------------------+---------------------------+------------------+
1 row in set (0.01 sec)
-- 分支事務(wù)
mysql> select xid,transaction_id,branch_id,client_id,branch_type from branch_table;
+-------------------------------+----------------+------------+-------------------------------------------+-------------+
| xid | transaction_id | branch_id | client_id | branch_type |
+-------------------------------+----------------+------------+-------------------------------------------+-------------+
| 192.168.0.101:8091:2155601919 | 2155601919 | 2155601922 | seata-order-service:192.168.0.101:51952 | AT |
| 192.168.0.101:8091:2155601919 | 2155601919 | 2155601927 | seata-storage-service:192.168.0.101:52459 | AT |
| 192.168.0.101:8091:2155601919 | 2155601919 | 2155601930 | seata-account-service:192.168.0.101:52498 | AT |
+-------------------------------+----------------+------------+-------------------------------------------+-------------+
3 rows in set (0.00 sec)
-- 鎖
mysql> select xid,transaction_id,branch_id,table_name,resource_id from lock_table;
+-------------------------------+----------------+------------+------------+-----------------------------------------------+
| xid | transaction_id | branch_id | table_name | resource_id |
+-------------------------------+----------------+------------+------------+-----------------------------------------------+
| 192.168.0.101:8091:2155601919 | 2155601919 | 2155601930 | t_account | jdbc:mysql://114.116.10.56:3306/seata_account |
| 192.168.0.101:8091:2155601919 | 2155601919 | 2155601922 | t_order | jdbc:mysql://114.116.10.56:3306/seata_order |
| 192.168.0.101:8091:2155601919 | 2155601919 | 2155601927 | t_storage | jdbc:mysql://114.116.10.56:3306/seata_storage |
+-------------------------------+----------------+------------+------------+-----------------------------------------------+
3 rows in set (0.00 sec)注意：全局事務(wù)xid 和分支事務(wù)branch_id 之間的對應(yīng)關(guān)系，比對上圖中成功提交流程.
我們觀察業(yè)務(wù)庫中的undo_log日志情況：（重點關(guān)注rollback_info字段信息）
格式化一下rollback_info信息:
當(dāng)然，讀者感興趣可以查看下seata_account庫和 seata_storage庫中undo_log的情況，與此類似。
所以我們可以將Seata的執(zhí)行原理歸納為：
(1) 在一階段，Seata 會攔截“業(yè)務(wù) SQL”，
- 解析 SQL 語義，找到“業(yè)務(wù) SQL”要更新的業(yè)務(wù)數(shù)據(jù)，在業(yè)務(wù)數(shù)據(jù)被更新前，將其保存成“before image”;
- 執(zhí)行“業(yè)務(wù) SQL”更新業(yè)務(wù)數(shù)據(jù);
- 在業(yè)務(wù)數(shù)據(jù)更新之后，其保存成“after image”，最后生成行鎖。
以上操作全部在一個數(shù)據(jù)庫事務(wù)內(nèi)完成，這樣保證了一階段操作的原子性。
圖片來源于學(xué)習(xí)筆記
(2) 二階段提交：
天空不留下鳥兒的痕跡，但它已經(jīng)飛過），完成數(shù)據(jù)清理即可。
圖片來源于學(xué)習(xí)筆記
(3) 二階段回滾：
二階段如果是回滾的話，Seata 就需要回滾一階段已經(jīng)執(zhí)行的“業(yè)務(wù) SQL”，還原業(yè)務(wù)數(shù)據(jù)?；貪L方式便是用“before image”還原業(yè)務(wù)數(shù)據(jù)。
- 還原前要首先要校驗臟寫；
- 對比“數(shù)據(jù)庫當(dāng)前業(yè)務(wù)數(shù)據(jù)”和 “after image”
- 如果兩份數(shù)據(jù)完全一致就說明沒有臟寫，可以還原業(yè)務(wù)數(shù)據(jù)，如果不一致就說明有臟寫，出現(xiàn)臟寫就需要轉(zhuǎn)人工處理。
圖片來源于學(xué)習(xí)筆記
總結(jié)
本文主要對分布式事務(wù)Seata的使用、原理做了介紹，同時在選擇方案選擇上給出如下建議：
- 非必要不引入分布式事務(wù)的處理；
- 分布式事務(wù)在分布式環(huán)境下使用，單體應(yīng)用不必考慮；
- 一般多用在遠(yuǎn)程調(diào)用三方外部平臺之間，內(nèi)部系統(tǒng)服務(wù)之間建議使用Spring事務(wù)
- Seata分布式事務(wù)方案默認(rèn)AT模式，代碼無入侵，使用簡單，在數(shù)據(jù)一致性要求比較高的系統(tǒng)中，是很好的分布式事務(wù)解決方案。常用于電商支付、金融轉(zhuǎn)賬類業(yè)務(wù)。
- Seata配置繁瑣，引入子系統(tǒng)會產(chǎn)生很多其它問題。應(yīng)根據(jù)實際場景合理選擇。
