Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to understand Java distributed transactions". In daily operation, I believe many people have doubts about how to understand Java distributed transactions. The editor consulted all kinds of data and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to understand Java distributed transactions". Next, please follow the editor to study!

A transaction is a session in which the impact on the context is consistent, either all changes are made or all changes are undone. Live or die. There is no half-immortal middle unpredictable state.

Refer to Schrodinger's cat.

Transactions are designed to ensure the integrity and accuracy of business data.

Two common processing methods for distributed transactions are two-stage commit and compensation.

A typical two-stage submission is XA. There is a transaction coordinator that tells everyone that they are ready to submit, that they are ready to reply, that they are all ready, and then the coordinator tells them that they are all submitted together.

Compensation is easier to understand. First deal with the business, and then check whether the status is consistent in timing or callback. If a policy is not consistently adopted, force the state to a certain end state (usually a failed state), and then the world will be at peace. The typical operation is the correcting operation.

When you are ready, if there is no problem, you receive the submission, and everyone starts to submit.

At this time, for example, for a database, there are redo logs.

If a database goes down at this time, when it is restarted, check will be performed first, and the last operation will be submitted. So the data at all points are consistent.

Question1: for example, if a business calls a lot of services are write operations, what if one of the written services fails? Suppose four wrote it, and two failed.

Kimmking: the general practice of websites such as Taobao is that if all four are successful, then all four writes are set to an intermediate state when submitting this time, allowing inconsistencies first. Then, after the four execution is completed, check whether the four data are consistent in the callback or timing task. If they are consistent, they will all be set to success, and if they are inconsistent, they will all be set to failure.

Highly consistent distributed transactions are not recommended in complex business interactions. The best way to solve distributed transactions is not to consider distributed transactions. As with the problem just mentioned, the distributed transaction process is decomposed into multiple intermediate states, and the things in the intermediate state are not allowed to be operated directly by the user, such as the states are consistent and successful, or all fail when inconsistencies are detected. This strongly consistent process is decoupled.

In general, quasi-real-time is enough. When it comes to money, sometimes you can do the same.

Taobao within a few seconds of a complete order processing, it is not a problem.

Not all banks are highly consistent. Will also make a difference, but also will correct.

Especially when multiple systems are involved, for example, when we buy an air ticket, after the payment is completed, we only pay for the completion status, and then return it to the user. We will refresh the page in a few minutes before we see that the ticket has been issued and the order is completed.

At this time, if we require all processing to be strongly consistent, it will be over for a long time. It takes a few minutes for the page to die before the transaction is completed and returned to the user.

In this way, there must be a problem involved, the payment was made, but in the end, the ticket was not issued. Then there's no way to discuss a ticket change or a refund.

Taobao order changed to invoice failure, send a message to the payment to notify the refund.

When it is slow, it is possible to issue a ticket manually, when it is possible to issue a ticket for half an hour. If strong consistency is required, where all the processing threads are hung, the system will be dead long ago.

The best way to solve distributed transactions is not to consider distributed transactions.

Split, large business processes, into several small business processes, and then consider the final consistency.

Question2: do you develop your own distributed transactions, or do you come with your own database?

Kimmking:

1. As long as a processing logic ensures either success or nothing, it is a transaction. Database transactions, MQ also has transactions.

You can even write a program to generate two files, either generated, or deleted without leaving a trace, which is also a transaction.

2. There is a XA specification for distributed transactions. Transactions that implement XA interfaces can be added to a distributed transaction and managed by the XA container.

3. The method of compensation requires a specific analysis of the specific situation, and there is no framework that can be applied to all kinds of situations.

At this point, the study on "how to understand Java distributed transactions" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.