如何用C#實現(xiàn)SAGA分布式事務
背景
銀行跨行轉賬業(yè)務是一個典型分布式事務場景，假設 A 需要跨行轉賬給 B，那么就涉及兩個銀行的數(shù)據(jù)，無法通過一個數(shù)據(jù)庫的本地事務保證轉賬的 ACID ，只能夠通過分布式事務來解決。
市面上使用比較多的分布式事務框架，支持 SAGA 的，大部分都是 JAVA 為主的，沒有提供 C# 的對接方式，或者是對接難度大，一定程度上讓人望而卻步。
下面就基于這個框架來實踐一下銀行轉賬的例子。
前置工作
dotnet add package Dtmcli --version 0.3.0
成功的 SAGA
先來看一下一個成功完成的 SAGA 時序圖。
上圖的微服務1，對應我們示例的 OutApi，也就是轉錢出去的那個服務。
微服務2，對應我們示例的 InApi，也就是轉錢進來的那個服務。
下面是兩個服務的正向操作和補償操作的處理。
OutApi
app.MapPost("/api/TransOut", (string branch_id, string gid, string op, TransRequest req) =>
{
// 進行 數(shù)據(jù)庫操作
Console.WriteLine($"用戶【{req.UserId}】轉出【{req.Amount}】正向操作，gid={gid}, branch_id={branch_id}, op={op}");
return Results.Ok(TransResponse.BuildSucceedResponse());
});
app.MapPost("/api/TransOutCompensate", (string branch_id, string gid, string op, TransRequest req) =>
{
// 進行 數(shù)據(jù)庫操作
Console.WriteLine($"用戶【{req.UserId}】轉出【{req.Amount}】補償操作，gid={gid}, branch_id={branch_id}, op={op}");
return Results.Ok(TransResponse.BuildSucceedResponse());
});
InApi
app.MapPost("/api/TransIn", (string branch_id, string gid, string op, TransRequest req) =>
{
Console.WriteLine($"用戶【{req.UserId}】轉入【{req.Amount}】正向操作，gid={gid}, branch_id={branch_id}, op={op}");
return Results.Ok(TransResponse.BuildSucceedResponse());
});
app.MapPost("/api/TransInCompensate", (string branch_id, string gid, string op, TransRequest req) =>
{
Console.WriteLine($"用戶【{req.UserId}】轉入【{req.Amount}】補償操作，gid={gid}, branch_id={branch_id}, op={op}");
return Results.Ok(TransResponse.BuildSucceedResponse());
});
注：示例為了簡單，沒有進行實際的數(shù)據(jù)庫操作。
到此各個子事務的處理已經 OK 了，然后是開啟 SAGA 事務，進行分支調用
var userOutReq = new TransRequest() { UserId = "1", Amount = -30 };
var userInReq = new TransRequest() { UserId = "2", Amount = 30 };
var ct = new CancellationToken();
var gid = await dtmClient.GenGid(ct);
var saga = new Saga(dtmClient, gid)
.Add(outApi + "/TransOut", outApi + "/TransOutCompensate", userOutReq)
.Add(inApi + "/TransIn", inApi + "/TransInCompensate", userInReq)
;
var flag = await saga.Submit(ct);
Console.WriteLine($"case1, {gid} saga 提交結果 = {flag}");
到這里，一個完整的 SAGA 分布式事務就編寫完成了。
搭建好 dtm 的環(huán)境后，運行上面的例子，會看到下面的輸出。
當然，上面的情況太理想了，轉出轉入都是一次性就成功了。
但是實際上我們會遇到許許多多的問題，最常見的應該就是網絡故障了。
下面來看一個異常的 SAGA 示例
異常的 SAGA
做一個假設，用戶1的轉出是正常的，但是用戶2在轉入的時候出現(xiàn)了問題。
由于事務已經提交給 dtm 了，按照 SAGA 事務的協(xié)議，dtm 會重試未完成的操作。
這個時候用戶2 這邊會出現(xiàn)什么樣的情況呢？
轉入其實成功了，但是 dtm 收到錯誤 (網絡故障等)轉入沒有成功，直接告訴 dtm 失敗了 (應用異常等)
無論是那一種，dtm 都會進行重試操作。這個時候會發(fā)生什么呢？我們繼續(xù)往下看。
先看一下事務失敗交互的時序圖
再通過調整上面成功的例子，來比較直觀的看看出現(xiàn)的情況。
在 InApi 加多一個轉入失敗的處理接口
app.MapPost("/api/TransInError", (string branch_id, string gid, string op, TransRequest req) =>
{
Console.WriteLine($"用戶【{req.UserId}】轉入【{req.Amount}】正向操作--失敗，gid={gid}, branch_id={branch_id}, op={op}");
//return Results.BadRequest();
return Results.Ok(TransResponse.BuildFailureResponse());
});
失敗的返回有兩種，一種是狀態(tài)碼大于 400，一種是狀態(tài)碼是 200 并且響應體包含 FAILURE，上面的例子是第二種
調整一下調用方，把轉入正向操作替換成上面這個返回錯誤的接口。
var saga = new Saga(dtmClient, gid)
.Add(outApi + "/TransOut", outApi + "/TransOutCompensate", userOutReq)
.Add(inApi + "/TransInError", inApi + "/TransInCompensate", userInReq);
運行結果如下：
在這個例子中，只考慮補償/重試成功的情況下。
用戶1 轉出的 30 塊錢最終是回到了他的帳號上，他沒有出現(xiàn)損失。
用戶2 就有點苦逼了，轉入沒有成功，返回了失敗，還觸發(fā)了轉入的補償機制，結果就是把用戶2 還沒進帳的 30 塊錢給多扣了，這個就是上面的情況2，常見的空補償問題。
這個時候就要在進行轉入補償?shù)臅r候做一系列的判斷，轉入有沒有成功，轉出有沒有失敗等等，把業(yè)務變的十分復雜。
如果出現(xiàn)了上述的情況1，會發(fā)生什么呢？
用戶2 第一次已經成功轉入 30 塊錢，返回的也是成功，但是網絡出了點問題，導致 dtm 認為失敗了，它就會進行重試，相當于用戶2 還會收到第二個轉入 30 塊錢的請求！也就是說這次轉帳，用戶2 會進賬 60 塊錢，翻倍了，也就是說這個請求不是冪等。
同樣的，要處理這個問題，在進行轉入的正向操作中也要進行一系列的判斷，同樣會把復雜度上升一個級別。
前面有提到 dtm 提供了子事務屏障的功能，保證了冪等、空補償?shù)瘸Ｒ妴栴}。
再來看看這個子事務屏障的功能有沒有幫我們簡化上面異常處理。
子事務屏障
子事務屏障，需要根據(jù) trans_type，gid，branch_id 和 op 四個內容進行創(chuàng)建。
這4個內容 dtm 在回調時會放在 querysting 上面。
客戶端里面提供了 IBranchBarrierFactory 來供我們使用。
空補償
針對上面的異常情況(用戶2 憑空消失 30 塊錢)，對轉入的補償進行子事務屏障的改造。
app.MapPost("/api/BarrierTransInCompensate", async (string branch_id, string gid, string op, string trans_type, TransRequest req, IBranchBarrierFactory factory) =>
{
var barrier = factory.CreateBranchBarrier(trans_type, gid, branch_id, op);
using var db = Db.GeConn();
await barrier.Call(db, async (tx) =>
{
// 轉入失敗的情況下，不應該輸出下面這個
Console.WriteLine($"用戶【{req.UserId}】轉入【{req.Amount}】補償操作，gid={gid}, branch_id={branch_id}, op={op}");
// tx 參數(shù)是事務，可和本地事務一起提交回滾
await Task.CompletedTask;
});
Console.WriteLine($"子事務屏障-補償操作，gid={gid}, branch_id={branch_id}, op={op}");
return Results.Ok(TransResponse.BuildSucceedResponse());
});
Call 方法就是關鍵所在了，需要傳入一個 DbConnection 和真正的業(yè)務操作，這里的業(yè)務操作就是在控制臺輸出補償操作的信息。
同樣的，我們再調整一下調用方，把轉入補償操作替換成上面帶子事務屏障的接口。
var saga = new Saga(dtmClient, gid)
.Add(outApi + "/TransOut", outApi + "/TransOutCompensate", userOutReq)
.Add(inApi + "/TransInError", inApi + "/BarrierTransInCompensate", userInReq)
;
再來運行這個例子。
會發(fā)現(xiàn)轉入的補償操作并沒執(zhí)行，控制臺沒有輸出補償信息，而是輸出了
Will not exec busiCall, isNullCompensation=True, isDuplicateOrPend=False
這個就表明了，這個請求是個空補償，是不應該執(zhí)行業(yè)務方法的，既空操作。
再來看一下，轉入成功的，但是 dtm 收到了失敗的信號，不斷重試造成重復請求的情況。
冪等
針對用戶2 轉入兩次 30 塊錢的異常情況，對轉入的正向操作進行子事務屏障的改造。
app.MapPost("/api/BarrierTransIn", async (string branch_id, string gid, string op, string trans_type, TransRequest req, IBranchBarrierFactory factory) =>
{
Console.WriteLine($"用戶【{req.UserId}】轉入【{req.Amount}】請求來了！??！ gid={gid}, branch_id={branch_id}, op={op}");
var barrier = factory.CreateBranchBarrier(trans_type, gid, branch_id, op);
using var db = Db.GeConn();
await barrier.Call(db, async (tx) =>
{
var c = Interlocked.Increment(ref _errCount);
// 模擬一個超時執(zhí)行
if (c > 0 && c < 2) await Task.Delay(10000);
Console.WriteLine($"用戶【{req.UserId}】轉入【{req.Amount}】正向操作，gid={gid}, branch_id={branch_id}, op={op}");
await Task.CompletedTask;
});
return Results.Ok(TransResponse.BuildSucceedResponse());
});
這里通過一個超時執(zhí)行來讓 dtm 進行轉入正向操作的重試。
同樣的，我們再調整一下調用方，把轉入的正向操作也替換成上面帶子事務屏障的接口。
var saga = new Saga(dtmClient, gid)
.Add(outApi + "/TransOut", outApi + "/TransOutCompensate", userOutReq)
.Add(inApi + "/BarrierTransIn", inApi + "/BarrierTransInCompensate", userInReq)
;
再來運行這個例子。
可以看到轉入的正向操作確實是觸發(fā)了多次，第一次實際上是成功，只是響應比較慢，導致 dtm 認為是失敗了，觸發(fā)了第二次請求，但是第二次請求并沒有執(zhí)行業(yè)務操作，而是輸出了
Will not exec busiCall, isNullCompensation=False, isDuplicateOrPend=True
這個就表明了，這個請求是個重復請求，是不應該執(zhí)行業(yè)務方法的，保證了冪等。
到這里，可以看出，子事務屏障確實解決了冪等和空補償?shù)膯栴}，大大降低了業(yè)務判斷的復雜度和出錯的可能性。
寫在最后
在這篇文章里，也通過幾個例子，完整給出了編寫一個 SAGA 事務的過程，涵蓋了正常成功完成，異常情況，以及成功回滾的情況。希望對研究分布式事務的您有所幫助。
本文示例代碼： DtmSagaSample
到此這篇關于如何用C#實現(xiàn)SAGA分布式事務的文章就介紹到這了,更多相關C#實現(xiàn)SAGA內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
相關文章
C#中Abstract方法和Virtual方法的區(qū)別
這篇文章介紹了C#中Abstract方法和Virtual方法的區(qū)別，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2022-04-04
LRU（Least Recently Used）緩存替換策略是一種常用的緩存管理策略，它根據(jù)數(shù)據(jù)最近被訪問的時間來決定哪些數(shù)據(jù)應該被保留在緩存中。本文將介紹LRU緩存替換策略的原理和C#實現(xiàn)方法。2023-04-04
這篇文章主要介紹了C#簡單寫入xml文件的方法,可實現(xiàn)C#針對XML文件簡單寫入的功能,具有一定參考借鑒價值,需要的朋友可以參考下2015-07-07
本文主要介紹了C#?漢字與拼音互轉的實現(xiàn)示例，文中根據(jù)實例編碼詳細介紹的十分詳盡，具有一定的參考價值，感興趣的小伙伴們可以參考一下2022-03-03
C# 中 Array和 ArrayList詳解及區(qū)別
這篇文章主要介紹了C# 中 Array和 ArrayList詳解及區(qū)別的相關資料,需要的朋友可以參考下2017-01-01
設計模式通常分為三個主要類別：創(chuàng)建型模式、結構型模式和行為型模式，這些模式是用于解決常見的對象導向設計問題的最佳實踐，本文為大家整理了23種常見的設計模式的實現(xiàn)代碼，需要的可以參考一下2023-06-06
對于XML讀寫操作，項目中經常要用到，之前木有好好總結過，例如LINQ TO XML也用過，這次無意發(fā)現(xiàn)XPATH對于XML的查詢極為方便，索性把XML的操作總結以便后續(xù)方便使用2014-03-03
給大家分享用C#寫出一個計算機功能的全部代碼分享，有興趣的朋友可以跟著做一下。2018-03-03
這篇文章主要介紹了C#生成exe可執(zhí)行文件的兩種常用方法,通過圖文結合的方式講解的非常詳細,對大家的學習或工作有一定的幫助,需要的朋友可以參考下2024-07-07
這篇文章主要介紹了C#畫筆使用復合數(shù)組繪制單個矩形的方法,涉及C#使用畫筆繪制圖形的相關技巧,需要的朋友可以參考下2015-06-06