How to choose the best distributed transaction solution for you

I had an article before that introduced the seven most classic solutions . Here we provide the most suitable solutions from the perspective of business needs and according to different business scenarios.

When we adopted the service/microservice architecture and decoupled the business, we used a local database to ensure the data modification of ACID in a single unit. Because it spans multiple services, it is no longer applicable, and we need to introduce distribution. Type transactions to ensure the new atomicity.

Due to the distributed transaction solution, ACID cannot be guaranteed, and there is no perfect solution that can solve all business problems. Therefore, in actual applications, the most suitable distributed transaction solution will be selected according to the different characteristics of the business.

Business Categories

The following are several common business classifications, as well as the introduction of suitable solutions

Multiple microservices are combined into atomic operations

There is a type of business scenario where you need to combine multiple microservices into atomic operations: Suppose you have an active business. After the user clicks the claim button, they will receive a coupon and one-month membership. Coupons and members belong to different services, and both need to be called. It is not expected that one service is successfully called and the other is unsuccessful due to network or other failures.

This scenario is suitable for reliable messaging solutions. You can use rocketmq, rabbitmq, etc., for messages sent to the message queue, you must wait for the queue to receive confirmation before returning to the application.

Local transaction + multiple microservices are combined as atomic operations

One type of business is similar to the previous one, but there are some differences: suppose you have a new user after successfully registering, receive a coupon and one-month membership. If the registration is unsuccessful, do not want to call to claim; only the registration is successful to claim.

In this case, it is suitable for the local message scheme or the transaction message scheme. Both of these schemes can guarantee the atomicity of local transactions and messages.

Order type business that requires high consistency

Order transaction business involves multiple services such as funds, inventory, coupons, etc. To complete an order, various related services need to be combined into an overall rollbackable transaction. If the amount is first deducted while the order is in progress, then the amount can only be refunded due to insufficient inventory, and the amount of compensation will be added back. During this process, the user saw that the amount decreased, and then the amount changed back, and the experience was very poor. Generally, this type of business will freeze the funds first, and if the order is successful, then the funds will be deducted; if it fails, the funds will be unfrozen, which can make the funds information more user-friendly.

This scenario is suitable for the TCC scheme. You can freeze funds in TCC Try, deduct funds in Confirm, and unfreeze funds in Cancel.

Rollback business with low consistency requirements

If the business does not require high consistency in the transaction, allow the user to see the intermediate state, such as the user's point data.

This mode is suitable for SAGA mode. Compared with TCC, SAGA only has forward operation and reverse compensation operation, which will be simpler.

Longer global transaction

The time-consuming and older global transaction is suitable for reliable messages and SAGA, but not suitable for TCC and XA, because most XA and TCC implementations, in order to facilitate users to define transactions flexibly, usually save the progress of the transaction in the application, once the transaction is in progress The application crashed, unable to move forward to the next step, only to roll back.

SAGA and reliable news, save the progress of the transaction in the database or message system, any component temporarily fails, if the retry succeeds, the transaction can continue.

Among them, if the entire transaction needs to be rolled back, then it is suitable for SAGA, and does not need to be rolled back, suitable for reliable messages

Business with low concurrency

If the business concurrency is not high and the transaction needs to support rollback, then the XA solution is suitable. In addition to the low concurrency, the XA solution also requires the local database to support the XA interface. The advantage of this scheme is that it is simpler to use and closer to local affairs

practice

After introducing the various business types and suitable business solutions above, under normal circumstances, you need to choose a suitable open source project to implement the technical solution. In the field of distributed transactions, DTM , SEATA , RocketMq

Among them, seata is developed in Java, supports Java language access, supports TCC, SAGA, XA, AT (similar to XA, higher performance, but dirty rollback)

RocketMq is developed in Java, supports access in various languages, and only supports reliable message and transaction message mode

This article focuses on DTM, which is developed with GO, based on HTTP protocol, supports multiple language access, supports TCC, SAGA, XA, reliable message, transaction message mode.

Examples of reliable news

Let's take the first and simplest business scenario "multiple microservices combined into atomic operations" to see how DTM solves the problem

Assuming that the processing functions for receiving coupons and members are ObtainCoupon and ObtainVip respectively, then the processing function for processing the receiving logic (using Go as an example) can only be written like this:

    msg := dtmcli.NewMsg(DtmServer,gid).
        Add(Busi+"/ObtainCoupon", req).
        Add(Busi+"/ObtainVip", req)
    err := msg.Submit()

After dtm receives the message submitted by the client, it will ensure that ObtainCoupon and ObtainVip are called. If any of them fails, it will continue to retry until it succeeds.

If you are using the rocketmq solution, then you need to do the following steps:

1. Send a "received" message to the queue
2. Consume the "received" message, then call ObtainCoupon and ObtainVip, and then confirm that the message has been successfully consumed

Comparing the solutions of dtm and rocketmq, dtm only needs a few simple lines of code (dtm also provides an http interface, you can directly send http requests in any language), clear and simple. The rocketmq solution involves more queue knowledge and more work to be done

SAGA example

Suppose we have a business of redeeming points for courses. On the one hand, points are not a very core asset, and the intermediate state allows users to see it. On the other hand, redeeming courses may show that the course already has permission and needs to be rolled back. Therefore, this business belongs to "consistent" Rollback business with low sexual requirements".

We use the SAGA solution to solve this problem, take a look at the DTM solution, the code is roughly as follows:

    saga := dtmcli.NewSaga(DtmServer, gid).
        Add(Busi+"/AdjustIntegral", Busi+"/AdjustIntegralRevert", req).
        Add(Busi+"/AuthCourse", Busi+"/AuthCourseRevert", req)
    saga.WaitResult = true
    err := saga.Submit()

After dtm receives the saga transaction submitted by the client, it will call AdjustIntegral and AuthCourse in order. If the function returns an error and requires rollback, dtm will call AuthCourseRevert and AdjustIntegralRevert to rollback.

If you have not adopted the dtm solution, you can use SEATA's SAGA, which involves more background knowledge and more complicated access.

More examples

You can visit https://github.com/yedf/dtm , there are many distributed transaction examples

Multiple modes coexist

If your actual project involves many scenarios involving distributed transactions, one transaction mode may not meet the needs, and you may need to use SEATA+Rocketmq, which has high access and maintenance costs. DTM provides a one-stop solution and provides convenient support for various common business scenarios.

summary

As an emerging distributed transaction framework, dtm provides powerful functions and easy-to-use interfaces, which greatly simplifies the use of distributed transactions under the microservice architecture.

The following is a comparison of the main features of dtm and seata:

characteristic	DTM	SEATA	Remark
Support language	Golang, python, php, c# and others	Java	dtm can easily access a new language
Exception handling	Sub-transaction barrier automatic processing	Manual processing	dtm solves idempotence, suspension, and null compensation
TCC affairs	✓	✓
XA affairs	✓	✓
AT affairs	✗	✓	AT is similar to XA, with better performance, but with dirty rollback
SAGA affairs	Simple mode	State machine complex pattern	The state machine mode of dtm is under planning
Transaction message	✓	✗	dtm provides transaction messages similar to rocketmq
letter of agreement	HTTP	Protocols such as dubbo, no HTTP	dtm will support grpc protocol in the future

The project address of dtm is https://github.com/yedf/dtm , welcome everyone to visit, try and light up star