Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to use C # to achieve SAGA distributed transactions, the content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Background

The inter-bank transfer business is a typical distributed transaction scenario. If A needs to transfer money across banks to B, then the data involving two banks can not be guaranteed by the local transaction of a database, and the ACID can only be solved through distributed transactions.

There are many distributed transaction frameworks in the market, and most of them support SAGA, which are mainly based on JAVA, and do not provide the connection mode of C#, or it is difficult to connect, which is prohibitive to a certain extent.

Here is an example of bank transfer based on this framework.

Front work

Dotnet add package Dtmcli-version 0.3.0 successful SAGA

Let's first take a look at a successfully completed SAGA sequence diagram.

The microservice 1 in the figure above corresponds to the OutApi of our example, that is, the service where the money is transferred.

Microservice 2, which corresponds to the InApi of our example, that is, the service in which the money is transferred.

The following is the processing of the forward operation and compensation operation of the two services.

OutApi

App.MapPost ("/ api/TransOut", (string branch_id, string gid, string op, TransRequest req) = > {/ / perform database operation Console.WriteLine ($"user [{req.UserId}] transfer out [{req.Amount}] forward operation, 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) = > {/ / perform database operation Console.WriteLine ($"user [{req.UserId}] transfer out [{req.Amount}] compensation operation, 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 ($"user [{req.UserId}] transferred to [{req.Amount}] forward operation, 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 ($"user [{req.UserId}] transfer to [{req.Amount}] compensation operation, gid= {gid}, branch_id= {branch_id}, op= {op}"); return Results.Ok (TransResponse.BuildSucceedResponse ());})

Note: the example does not perform actual database operations for simplicity.

At this point, the processing of each sub-transaction has been OK, and then the SAGA transaction is opened to make branch calls.

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 submission result = {flag}")

At this point, a complete SAGA distributed transaction is written.

After setting up the environment for dtm, run the above example and you will see the following output.

Of course, the above situation is too ideal, transfer out and transfer is an one-time success.

But in fact, we will encounter a lot of problems, the most common of which should be network failure.

Let's take a look at an example of an exception called SAGA

Abnormal SAGA

Let's assume that the transfer out of user 1 is normal, but user 2 has a problem with the transfer.

Because the transaction has been committed to dtm, according to the protocol of the SAGA transaction, dtm will retry the outstanding operation.

What will happen to user 2 at this time?

The transfer was actually successful, but the dtm received an error (network failure, etc.) and directly told dtm that the transfer was not successful (application exception, etc.)

Either way, dtm retries the operation. What will happen at this time? Let's move on.

First, take a look at the timing diagram of the transaction failure interaction.

Then by adjusting the above successful examples, to take a more intuitive look at the situation.

Add one more processing interface for failed transfer to InApi.

App.MapPost ("/ api/TransInError", (string branch_id, string gid, string op, TransRequest req) = > {Console.WriteLine ($"user [{req.UserId}] transferred to [{req.Amount}] forward operation-failed, gid= {gid}, branch_id= {branch_id}, op= {op}"); / / return Results.BadRequest (); return Results.Ok (TransResponse.BuildFailureResponse ());})

There are two types of failed returns, one is that the status code is greater than 400, the other is that the status code is 200 and the response body contains FAILURE, the above example is the second

Adjust the caller to replace the forward operation with the interface that returned an error.

Var saga = new Saga (dtmClient, gid) .add (outApi + "/ TransOut", outApi + "/ TransOutCompensate", userOutReq) .add (inApi + "/ TransInError", inApi + "/ TransInCompensate", userInReq)

The running results are as follows:

In this example, only compensation / retry success is considered.

The 30 yuan transferred by user 1 finally returned to his account, and there was no loss.

User 2 is a bit bitter, the transfer is not successful, the failure is returned, and the transfer compensation mechanism is triggered. As a result, the 30 yuan that user 2 has not yet earned is deducted. This is the above case 2, the common empty compensation problem.

At this time, we have to make a series of judgments during the transfer compensation, such as whether the transfer is successful, whether the transfer has failed, and so on, which makes the business very complicated.

What happens if the above situation 1 occurs?

User 2 has successfully transferred 30 yuan for the first time, and the return is also successful, but there is something wrong with the network, causing dtm to think that it has failed, and it will try again, which is equivalent to user 2 will receive a second request to transfer 30 yuan! That is to say, this transfer, user 2 will receive 60 yuan, double, that is to say, this request is not idempotent.

Similarly, to deal with this problem, you have to make a series of judgments in the forward operation of the transfer, which will also increase the complexity by one level.

As mentioned earlier, dtm provides the function of sub-transaction barrier, which ensures common problems such as idempotency and null compensation.

Let's see if the function of this sub-transaction barrier helps us simplify the exception handling above.

Sub-transaction barrier

The subtransaction barrier needs to be created according to the four contents of trans_type,gid,branch_id and op.

These four content dtm will be placed on the querysting during the callback.

IBranchBarrierFactory is provided in the client for us to use.

Null compensation

In view of the above abnormal situation (user 2 disappears 30 yuan out of thin air), transform the sub-transaction barrier to the transferred compensation.

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) = > {/ / when the transfer fails, the following Console.WriteLine should not be output ($"user [{req.UserId}] transfer to [{req.Amount}] compensation operation, gid= {gid}, branch_id= {branch_id}, op= {op}"); / / tx parameter is a transaction, which can be committed and rolled back with the local transaction }); Console.WriteLine ($"sub-transaction barrier-compensation operation, gid= {gid}, branch_id= {branch_id}, op= {op}"); return Results.Ok (TransResponse.BuildSucceedResponse ());})

The Call method is the key. You need to pass in a DbConnection and the real business operation, which is to output the information of the compensation operation on the console.

Similarly, let's adjust the caller to replace the forward compensation operation with the interface with the transaction barrier above.

Var saga = new Saga (dtmClient, gid) .add (outApi + "/ TransOut", outApi + "/ TransOutCompensate", userOutReq) .add (inApi + "/ TransInError", inApi + "/ BarrierTransInCompensate", userInReq)

Let's run this example again.

You will find that the transferred compensation operation is not performed, and the console does not output the compensation information, but outputs the

Will not exec busiCall, isNullCompensation=True, isDuplicateOrPend=False

This shows that the request is an empty compensation and should not execute the business method, which is a null operation.

Again, the transfer was successful, but dtm received a signal of failure and kept retrying the situation that resulted in repeated requests.

Idempotent

In view of the abnormal situation that user 2 transfers 30 yuan twice, the transformation of the sub-transaction barrier of the transferred forward operation is carried out.

App.MapPost ("/ api/BarrierTransIn", async (string branch_id, string gid, string op, string trans_type, TransRequest req, IBranchBarrierFactory factory) = > {Console.WriteLine ($"user [{req.UserId}] transfer [{req.Amount}] request is coming!! 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); / / simulate a timeout to execute 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());}); 这里通过一个超时执行来让 dtm 进行转入正向操作的重试。 同样的，我们再调整一下调用方，把转入的正向操作也替换成上面带子事务屏障的接口。 var saga = new Saga(dtmClient, gid) .Add(outApi + "/TransOut", outApi + "/TransOutCompensate", userOutReq) .Add(inApi + "/BarrierTransIn", inApi + "/BarrierTransInCompensate", userInReq) ; 再来运行这个例子。

You can see that the forward operation of the transfer is indeed triggered many times, the first time is actually successful, but the response is relatively slow, causing dtm to think that it failed and triggered the second request, but the second request did not perform the business operation, but output

Will not exec busiCall, isNullCompensation=False, isDuplicateOrPend=True

This shows that the request is a repeated request and that the business method should not be executed, ensuring idempotency.

At this point, it can be seen that the sub-transaction barrier does solve the problem of idempotent and null compensation, which greatly reduces the complexity of business judgment and the possibility of error.

On how to use C # to achieve SAGA distributed transactions to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.