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

Today, I would like to talk to you about what distributed transactions are, many people may not know much about it. In order to make you understand better, the editor summarized the following content for you. I hope you can get something from this article.

1. What is a distributed transaction?

A: a large operation consists of different small operations, which are distributed on different servers. Distributed transactions need to ensure that these small operations either succeed or fail. In essence, distributed transaction is to ensure the data consistency of different databases.

2. What are the causes of distributed transactions? 2.1 Database subdatabase and table

    when the database single table data reaches the level of ten million, we should consider sub-database and sub-table, then it will change from the original one database to multiple databases. For example, if an operation operates on both the 01 library and the 02 library, and to ensure data consistency, then distributed transactions are used.

2.2 Application SOA

    's so-called SOA is the service of the business. For example, when the e-commerce platform issues an order, it will call inventory service to deduct inventory and order service to update order data, then it will be designed to order database and inventory database. In order to ensure data consistency, distributed transactions are needed.

Summary: in fact, the above two scenarios, in the final analysis, are to operate multiple databases, and to ensure the consistency of the data, resulting in distributed transactions.

3. Distributed transaction solution 3.1 two-phase commit (2PC)

    XA is a distributed transaction protocol proposed by Tuxedo. XA is roughly divided into two parts: transaction manager and local resource manager. Among them, the local resource manager is often implemented by the database, such as Oracle, Mysql and other databases all implement the XA interface, while the transaction manager, as the global scheduler, is responsible for the submission and rollback of each local resource.

The principles of XA to implement distributed transactions are as follows:

Summary

   two-phase commit does seem to provide atomic operations, but it has several disadvantages:

1. Synchronous blocking problem: during execution, all participating nodes are transaction blocking. When participants occupy public resources, other third-party nodes have to be blocked to access public resources.

2. Single point of failure: because of the importance of the coordinator, once the coordinator fails. (local Resource Manager) participants will block all the time. Especially in the second phase, when the coordinator fails, all the participants are still in the state of locking transaction resources and cannot continue to complete the transaction operation. (if the coordinator dies, a coordinator can be re-elected, but the problem that participants are blocked due to coordinator downtime cannot be resolved.)

3. Data inconsistency: in stage 2 of the two-stage submission, when the coordinator sends the commit request to the participants, a local network exception occurs or the coordinator fails in the process of sending the commit request, which will cause only some participants to receive the commit request. After this part of the participant receives the commit request, the commit operation is performed. However, other machines that do not receive a commit request cannot perform a transaction commit. As a result, the whole distributed system has the phenomenon of data inconsistency.

4. The problem that cannot be solved in the second phase: the participant goes down after sending the commit message, and the only coordinator who receives the message is also down. So even if the coordinator produces a new coordinator through the election protocol, the status of the transaction is uncertain, and no one knows whether the transaction has been committed.

3.2 three-phase commit (3PC)

   3PC actually adds the CanCommit phase on the basis of 2PC, which is a variant of 2PC, and introduces a timeout mechanism. Once the transaction participant has not received the coordinator's Commit request, the local commit will be carried out automatically, which solves the problem of coordinator's single point of failure relatively effectively. However, the problems of performance and data consistency are not fundamentally solved.

3PC is divided into three stages: CanCommit, PreCommit, DoCommit

3.2.1 CanCommit Pha

   is similar to the preparation phase of 2PC, in which the coordinator sends a commit request to the participant, and the participant returns a Yes response if it can be submitted, otherwise it returns a No response.

Transaction query: the coordinator sends a CanCommit request to the participant. Ask if a transaction commit operation can be performed. And then start waiting for the participants to respond.

Response feedback: after the participant receives the CanCommit request, normally, if he or she thinks the transaction can be executed smoothly, he or she will return the Yes response and enter the ready state. Otherwise, return No

3.2.2 PreCommit Pha

The    coordinator decides whether a transactional PreCommit operation can be performed based on the response of the participants. Depending on the response, there are two possibilities:

If the coordinator gets Yes feedback from all participants, then the transaction and execution will be performed.

Send a pre-submission request: the coordinator sends a PreCommit request to the participant and enters the Prepared phase.

Transaction pre-commit: after the participant receives the PreCommit request, the transaction operation is performed and the undo and redo information is recorded in the transaction log.

Response feedback: if the participant successfully executes the transaction operation, the ACK response is returned while waiting for the final instruction.

If any participant sends a No response to the coordinator, or the wait times out, or the coordinator does not receive a response from the participant, the transaction is interrupted.

Send interrupt request: the coordinator sends an abort request to all participants.

Interrupt transaction: the participant executes the interruption of the transaction after receiving the abort request from the coordinator (or after the timeout, still does not receive the request from the coordinator).

3.2.3 doCommit Pha

The real transaction commit at this stage of    can also be divided into the following two situations:

Execute submission

Send a submission request: if you coordinate to receive the ACK response from the participant, you will go from the pre-submitted state to the submitted state. And send a doCommit request to all participants.

Transaction commit: after the participant receives the doCommit request, the formal transaction commit is performed and all transaction resources are released after the transaction commit is completed.

Response feedback: after the transaction is committed, send an ACK response to the coordinator.

Complete the transaction: after the coordinator receives the ACK response from all participants, the transaction is completed.

Interrupt a transaction

Send interrupt request: the coordinator sends an abort request to all participants

Transaction rollback: after receiving the abort request, the participant uses the undo information recorded in phase 2 to perform the transaction rollback operation, and releases all transaction resources after the rollback is completed.

Feedback result: after the participant completes the transaction rollback, sends an ACK message to the coordinator.

Interrupt transaction: the coordinator executes the interruption of the transaction after receiving the ACK message from the participant.

If the coordinator does not receive an ACK response from the participant (either the recipient sends a non-ACK response or the response times out), the interrupt transaction is executed.

The schematic diagram is as follows:

Summary

Compared with 2PC,    sets timeout for both coordinators and participants in 3PC, while only coordinators in 2PC have timeout mechanism. This optimization solves the problem that participants are unable to release resources when they are unable to communicate with the coordinator node for a long time, because participants have a timeout mechanism that will automatically perform local commit to release resources after timeout. This mechanism also reduces the blocking time and scope of the whole transaction. However, the problem of data consistency has not been solved, that is, the participant waits for the final instruction after receiving the PreCommit request. If the coordinator cannot communicate with the participant normally, it will cause the participant to continue to submit the transaction, resulting in data inconsistency.

3.3compensation transaction (TCC)

   TCC (Try-Confirm-Cancel) is also called compensation transaction. It is actually an implementation of distributed transactions just like 2PC and 3PC. It is divided into three operations:

Try phase: mainly testing the business system and reserving resources.

Confirm phase: confirm the execution of the business operation.

Cancel phase: cancels the execution of the business operation.

The processing flow of    TCC transactions is similar to that of 2PC two-phase commit, but 2PC is usually at the DB level, while TCC is essentially an application-level 2PC, which needs to be implemented through business logic. Its advantage is that it allows applications to define the granularity of database operations, reducing lock conflicts and commit throughput.

However,    is very intrusive to applications, and each branch of business logic needs to implement three operations: try, confirm and cancel.

The schematic diagram of TCC is as follows:

3.4 message transaction + final consistency

   's so-called message transaction is a two-phase commit based on message middleware, which is essentially a special use of middleware. He puts local transactions and sending messages in a distributed transaction to ensure that either local operations are successful and outgoing messages are successful, or both fail. Open source RocketMQ supports this feature, as follows:

The steps are as follows:

1. Service A sends a preparatory message to the message middleware.

2. Message middleware saves the prepared message and returns success.

3. Service A performs local transactions.

4. Service A sends a submission message to the message middleware, and Service B executes a local transaction after receiving the message.

   two-phase commit based on message middleware is often used in high concurrency scenarios to split a distributed transaction into a message transaction (local operation of service A + sending message) + local operation of service B, where the operation of service B is message driven. As long as the message transaction is successful, service A must be successful and the message must be sent. At this time, service B will receive a message to perform the local operation. If the local operation fails, the message is reinvested until the service B operation succeeds, thus realizing the distributed transaction between An and B in disguise.

There may be anomalies in the above steps, which are analyzed now:

Step 1 error: the entire transaction fails and the local operation of Service An is not performed.

Step 2 error: the entire transaction fails and the local operation of service An is not performed.

Step 3 error: you need to roll back the preparatory message. Service An implements a callback interface of message middleware. The message middleware will continue to execute the callback interface to check whether the transaction execution of service An is successful. If it fails, roll back the preparatory message.

Step 4 error: at this time, the local transaction of service An is successful, but the message middleware does not need to be rolled back. In fact, through the callback interface, message middleware can check that service A has executed successfully. At this time, there is no need for the service to send and submit messages. Message middleware can commit the message itself, thus completing the entire message transaction.

After reading the above, do you have any further understanding of what a distributed transaction is? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.