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

This article introduces you how to solve the distributed transaction problem, the content is very detailed, interested friends can refer to, I hope it can be helpful to you.

There are mainly five schemes for the implementation of distributed transactions:

XA scheme

TCC scheme

Local message table

Reliable message final consistency scheme

Best effort notification programme

Two-phase submission scheme / XA scheme

The so-called XA scheme, that is, two-phase commit, has the concept of a transaction manager, which is responsible for coordinating the transactions of multiple databases (resource managers). The transaction manager first asks each database if you are ready. If each database replies to ok, the transaction is formally committed and the operation is performed on each database; if any of the databases says no to ok, the transaction is rolled back.

This kind of distributed transaction scheme is more suitable for distributed transactions across multiple libraries in a single application, and because it relies heavily on the database level to handle complex transactions, the efficiency is very low, so it is absolutely not suitable for high concurrency scenarios. If you want to play, then you can do it based on Spring + JTA. Just search demo and have a look at it.

We seldom use this solution. Generally speaking, it is illegal for such an operation across multiple libraries to occur within a system. I can introduce to you, now micro-services, a large system is divided into dozens or even hundreds of services. Generally speaking, our rules and specifications require that each service can only operate on its own corresponding database.

If you want to operate the corresponding libraries of other services, you are not allowed to connect directly to the libraries of other services, in violation of the specifications of the micro-service architecture, and you randomly access hundreds of services. if you have hundreds of services, it is impossible to manage and govern such a set of services. it may occur that the data is corrected by others, and your own library is written and linked by others.

If you want to operate other people's service libraries, you must do so by calling the interfaces of other services, and never allow cross-access to other people's databases.

TCC scheme

The full name of TCC is: Try, Confirm, Cancel.

Try phase: this phase refers to the detection of resources for each service and the locking or reservation of resources.

Confirm phase: this phase refers to the execution of actual operations in each service.

Cancel phase: if there is an error in the business method execution of any of the services, compensation is required here, that is, to perform a rollback of the business logic that has been successfully executed. (roll back those that have been successfully executed)

To be honest, this scheme is rarely used by people, and we use it less, but there are also scenarios in which it is used. Because this transaction rollback actually relies heavily on you to write your own code to roll back and compensate, it will cause the compensation code to be huge and disgusting.

For example, for scenarios related to money, dealing with money, payment and transaction, we will use TCC to strictly ensure that distributed transactions are either successful or rolled back automatically, strictly ensure the correctness of funds, and ensure that there will be no financial problems.

And it is best that your business execution time is relatively short.

But to be honest, generally try not to do so, their own handwritten rollback logic, or compensation logic, is really disgusting, that business code is very difficult to maintain.

Local message table

The local news list is actually such a set of ideas developed by foreign ebay.

This probably means something like this:

A system operates in a local transaction while inserting a piece of data into the message table

Then system A sends this message to MQ

After receiving the message, system B inserts a piece of data into its local message table in a transaction and performs other business operations at the same time. If the message has already been processed, then the transaction will be rolled back. This ensures that the message will not be processed repeatedly.

After system B executes successfully, it will update the status of its local message table and the status of system A message table.

If system B fails to process, then the message table status will not be updated, then system A will scan its message table regularly, and if there are any unprocessed messages, it will send it to MQ again and let B process it again.

This scheme ensures ultimate consistency, even if the B transaction fails, but A will continue to resend the message until B succeeds.

To be honest, the biggest problem with this solution is that it relies heavily on the message tables of the database to manage transactions, which will lead to what if it is a high concurrency scenario. How to expand? So it is rarely used in general.

Reliable message final consistency scheme

This means that instead of using the local message table at all, the transaction is implemented directly based on MQ. For example, Ali's RocketMQ supports message transactions.

It probably means:

A system first sends a prepared message to mq. If the prepared message fails, then cancel the operation directly and don't execute it.

If the message is successfully sent, then the local transaction is executed. If it is successful, tell mq to send a confirmation message, and if it fails, tell mq to roll back the message.

If a confirmation message is sent, then system B will receive the confirmation message and execute the local transaction

Mq will automatically regularly poll all prepared messages to call back your interface, asking you, is this message a local transaction failure, all messages that did not send confirmation, should we continue to retry or roll back? Generally speaking, you can check the database to see if the local transaction was executed before, and if it is rolled back, then roll back here as well. This is to avoid the possibility that the local transaction executes successfully and the confirmation message fails to be sent.

In this scheme, what if the transaction of system B fails? Try again and again automatically until it succeeds. If it really doesn't work, it either rolls back the important capital business. For example, after system B rolls back locally, find a way to inform system A to roll back, or send an alarm to manually roll back and compensate.

This is more appropriate, at present, most domestic Internet companies play like this, either you use RocketMQ support, or you are based on similar ActiveMQ? RabbitMQ? Encapsulate a set of similar logic by yourself, in short, this is the way of thinking.

Best effort notification programme

The general meaning of this plan is:

After the local transaction of system An is executed, send a message to MQ

There will be a best effort notification service dedicated to consuming MQ. This service will consume MQ and write it down in the database, or put it in a memory queue, and then call the interface of system B.

If system B executes successfully, it will be ok; if system B fails, then the best effort to inform the service will regularly try to re-invoke system B, repeat N times, and finally give up if it fails.

How does your company handle distributed transactions?

If you are really asked, it can be said that our so-and-so particularly strict scenario uses TCC to ensure strong consistency; then some other scenarios are based on Ali's RocketMQ to implement distributed transactions.

If you find a scenario where strict financial requirements can never be wrong, you can say that you are using the TCC solution; if it is a general distributed transaction scenario, after the order is inserted, you need to call the inventory service to update the inventory. The inventory data is not as sensitive as funds, and you can use reliable messages to achieve the final consistency solution.

As a reminder, the previous version of RocketMQ 3.2.6 can follow the above ideas, but then the interface has made some changes, so I won't repeat them here.

So much for sharing about how you solve the problem of distributed transactions. I hope the above content can be helpful to you and learn more. 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.