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

This article introduces how to solve distributed transactions in Java, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Brief introduction

Distributed transaction means that the operation of the transaction is located on different nodes, so it is necessary to guarantee the AICD characteristics of the transaction.

For example, in the case of placing an order, if the inventory and order are not on the same node, a distributed transaction is involved.

Solution

In a distributed system, there are only several solutions to realize distributed transactions.

One, two-phase commit (2PC)

Two-phase commit (Two-phase Commit,2PC), through the introduction of a coordinator (Coordinator) to coordinate the behavior of participants, and finally decide whether these participants actually execute the transaction.

1. Run process 1.1 preparation phase

The coordinator asks the participant whether the transaction was executed successfully, and the participant sends back the transaction execution result.

1.2 submission phase

If the transaction executes successfully on each participant, the transaction coordinator sends a notification to the participant to commit the transaction; otherwise, the coordinator sends a notification to the participant to roll back the transaction.

It is important to note that during the preparation phase, the participant executed the transaction, but has not yet committed. Commit or roll back only after receiving a notification from the coordinator during the submission phase.

two。 Existing problems

2.1 synchronous blocking all transaction participants are in a synchronous blocking state while waiting for a response from other participants and are unable to perform other operations.

2.2 the single point coordinator plays a very important role in 2PC, and failure will have a great impact. Especially when a failure occurs in Phase 2, all participants will be waiting for the status and unable to complete other operations.

2.3 data inconsistency in stage 2, if the coordinator sends only part of the Commit message and the network is abnormal, then only some participants receive the Commit message, that is to say, only some participants submit the transaction, which makes the system data inconsistent.

2.4 too conservative the failure of any node will lead to the failure of the whole transaction, and there is no perfect fault-tolerant mechanism.

II. Compensation transaction (TCC)

TCC is actually the compensation mechanism adopted, and its core idea is to register a corresponding confirmation and compensation (revocation) operation for each operation. It is divided into three stages:

The Try phase is mainly about testing the business system and reserving resources.

The main purpose of the Confirm phase is to confirm the submission of the business system. When the Try phase is executed successfully and the Confirm phase is started, the default Confirm phase will not go wrong. That is, as long as Try succeeds, Confirm will succeed.

The Cancel phase mainly cancels the business executed in the case of business execution error and needs to be rolled back, and reserves resources to be released.

For example, if you want to transfer money to Smith if you assume Bob, the idea is: we have a local method that calls the

First of all, in the Try phase, you need to call the remote interface to freeze the money of Smith and Bob.

In the Confirm phase, the transfer operation of the remote call is performed and the transfer is thawed successfully.

If the second step is successful, the transfer is successful, and if the second step fails, the thawing method (Cancel) corresponding to the remote freeze API is called.

Pros: compared with 2PC, the implementation and process are relatively simple, but the data consistency is also worse than 2PC.

Disadvantages: the shortcomings are still quite obvious, and it is possible to fail in the 3 steps of 2Jing. TCC is a compensation method in the application layer, so programmers need to write a lot of compensation code when implementing it. In some scenarios, some business processes may not be easy to define and handle with TCC.

III. Local message table (asynchronously guaranteed)

The local message table and the business data table are located in the same database, so that the local transaction can be used to ensure that the operations on the two tables satisfy the transaction characteristics, and the message queue is used to ensure the final consistency.

After one side of the distributed transaction operation completes the operation of writing business data, a message is sent to the local message table, and the local transaction can guarantee that the message will be written to the local message table.

The message in the local message table is then forwarded to a message queue such as Kafka, and if the forwarding is successful, the message is deleted from the local message table, otherwise it will continue to be re-forwarded.

On the other side of the distributed transaction operation, a message is read from the message queue and the operation in the message is performed.

Advantages: a very classic implementation that avoids distributed transactions and achieves ultimate consistency.

Disadvantages: message tables are coupled to the business system, and if there is no encapsulated solution, there will be a lot of chores to deal with.

IV. MQ transaction message

There are some third-party MQ that support transaction messages, such as RocketMQ, which supports transaction messages in a way similar to the two-phase commit adopted, but some mainstream MQ in the market do not support transaction messages, such as RabbitMQ and Kafka.

Take Ali's RocketMQ middleware as an example, the idea is roughly as follows:

In the first stage of Prepared message, you will get the address of the message. The second phase executes the local transaction, and the third phase accesses the message and modifies the state through the address obtained in the first stage.

That is, within the business method, you have to submit two requests to the message queue, one to send a message and one to confirm. If the delivery of the confirmation message fails, RocketMQ will periodically scan the transaction messages in the message cluster, and when the Prepared message is found, it will confirm to the message sender, so the producer needs to implement a check interface, and RocketMQ will decide whether to roll back or continue to send the confirmation message according to the policy set by the sender. This ensures that message delivery succeeds or fails at the same time as the local transaction.

Advantages: ultimate consistency is achieved without relying on local database transactions.

Disadvantages: difficult to implement, mainstream MQ does not support, RocketMQ transaction message part of the code is not open source.

On how to solve distributed transactions in Java to share here, I hope that 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.