1. What is a distributed transaction?
A: refers to a major operation by the different small operation consisting of these small operations distributed across different servers, distributed transactions need to ensure that these small operations either all succeed, or all fail. In essence, a distributed transaction is to ensure the consistency of data from different databases.
2, because distributed transactions generated?
2.1 sub-library sub-table database
When a single database table data reaches millions of levels, it is necessary to consider sub-library sub-table, then it will become a multiple databases from the original database. For example, if an operator that the operator of the 01 libraries and 02 libraries operated, but also to ensure data consistency, it is necessary to use a distributed transaction.
2.2 Application of SOA
Of the so-called SOA is service oriented business. For example, the operation will produce a single service call stock inventory and order deduction update service orders, then the database will be designed to order and inventory database under the electronic business platform, in order to ensure data consistency, you need to use a distributed transaction.
Summary: In fact, the above two scenarios, in the final analysis is to operate multiple databases, and to ensure consistency of the data, and distributed transaction generated.
3, Distributed Transaction Solutions
3.1 two-phase commit (2PC)
XA is a distributed transaction protocol, proposed by Tuxedo. XA are roughly divided into two parts: the local transaction manager and resource manager. Where the local resource managers are often implemented by the database, such as Oracle, Mysql and other databases to achieve the XA interface, the transaction manager as a global schedule, responsible for the various local resources submit rollback.
XA distributed transaction principle to achieve the following:
to sum up
Two-phase commit protocol does seem to provide atomicity operation, but it has several disadvantages:
1, synchronized blocking issues : the implementation process, all participating nodes are transaction blocking type. When a participant possession of public resources, and other third-party access nodes public resources have blocked state.
2, single point of failure : because of the importance (Transaction Manager) coordinator, once the coordinator has failed. (Local Resource Manager) participants would have been blocking it. Especially in the second phase, the coordinator fails, then all the players are still in the locked state of affairs resources, and can not continue to complete the transaction operation. (If it is hung coordinator, a coordinator may be re-elected, but can not be solved because the participants coordinator downtime caused by problems in the blocked state)
3, data inconsistency : In stage two two-phase commit protocol, when the commit coordinator sends a request to the participant, or abnormality occurs in a local network transmission request commit coordinator process fails, this results in only the part of the participant receiving a request to commit. In this partial participant after the commit request will commit to the operation. But other parts of the machine has not received a request can not be executed commit transaction commits. So the whole distributed system giving rise to the phenomenon of inconsistent data.
4, the second phase can not solve the problem : the participants after issuing the commit message down, and the only coordinator receives this message also is down. Then created a new coordinator coordinator even by election protocol, this state of affairs is uncertain, no one knows whether the transaction was already submitted.
3.2 three-phase commit (3PC)
In fact, on the basis of 2PC 3PC increased CanCommit on stage, is a variant of 2PC, and the introduction of a time-out mechanism. Once the transaction has yet to receive the participants Commit coordinator's request, it will automatically be local commit, so a relatively effective solution to the problem coordinator single point of failure. However, the performance and data consistency problem has not been fundamentally resolved.
3PC divided into three stages: CanCommit, precommit, DoCommit
3.2.1 CanCommit stage
It is much like, coordinator with the preparation stage 2PC send to participants commit request, participants can submit returns if the response Yes, otherwise No response.
- Affairs asked : CanCommit coordinator sends a request to the participants. Asking whether the transaction commit operation can be performed. Then start waiting for the response of participants
- In response to feedback : After participants received CanCommit request, under normal circumstances, if you can think of its own affairs successfully executed, the Yes response is returned, and enter the ready state. No otherwise
3.2.2 PreCommit stage
According to the coordinator of the response of participants to determine whether a transaction can be PreCommit operation. The response to the situation, there are two possibilities:
- If the coordinator feedback obtained from all participants are Yes, then it will execute the transaction and execution.
- Send pre-commit request : send coordinator PreCommit request and enter Prepared stage to the participants.
- Pre-commit transaction : PreCommit participant after receiving the request, the transaction operation is executed, and the undo and redo information logged in the transaction log.
- Feedback response : If the participant successfully executed the transaction operation, ACK response is returned, and began to wait for the final instruction.
- If there is any participant sends a coordinator of the No response, or wait for a timeout, or who have not received the coordination of the response of participants, then execute the interrupt transaction.
- Send an interrupt request : abort coordinator sends a request to all participants.
- Interrupt transaction : abort after participants received a request from the coordinator (or after a timeout, have not received a request coordinator), interrupt the execution of the transaction.
3.2.3 doCommit stage
The stage for genuine transaction commits, can be divided into the following two cases:
- Commit
- A commit request is : Coordination participant sending ACK response is received, then the pre-commit state from a state into submission. DoCommit request and sends all participants.
- Transaction commit : Participants received doCommit request after the formal implementation of the transaction commits, and release all transaction resources after the completion of the transaction commits.
- In response to feedback : After completion of the transaction submitted, it sends an ACK response to the coordinator.
- Transaction completion : After receiving the ACK response coordinator all participants to complete the transaction.
- Interrupt Transaction
- Coordinator ACK is not received in response to the participants sent (probably not the recipient to send an ACK response, it may respond to a timeout), it will execute the interrupt transaction.
- Send an interrupt request : abort coordinator sends a request to all participants
- Rollback transaction : After receiving the participant abort request, using undo information recorded in its two phases of a transaction rollback operation, and releases all the resources after the completion of a transaction rollback.
- Feedback results : After the participants completed the transaction is rolled back, as the coordinator of the ACK message.
- Interrupt Transaction : coordinator after receiving the ACK message participant feedback, the enforcement branch of the interruption.
- Coordinator ACK is not received in response to the participants sent (probably not the recipient to send an ACK response, it may respond to a timeout), it will execute the interrupt transaction.
Diagram is as follows:
to sum up
With respect to the terms of 2PC, 3PC for coordinators and participants have set up a timeout, but only 2PC coordinator only has the timeout mechanism. This optimization is resolved, the participants in the case of prolonged node can not communicate with the coordinator, we can not release the issue of resources, because the participants have their own timeout mechanism will automatically commit locally after a timeout to perform the release of resources. And this mechanism also reduces the side blocking time and scope of the entire transaction. But still does not solve the problem of data consistency, that the participant after receiving the request PreCommit awaiting final instructions, if at this time coordinator can not communicate properly with the participants, will lead participants to continue to commit the transaction, resulting in inconsistent data.
3.3 Compensation Services (TCC)
TCC (Try-Confirm-Cancel), also known as compensating transactions. It's actually the 2PC, 3PC, are a distributed transaction implementation only. It is divided into three operations:
- Try stages : detection and mainly do business resource reservation system.
- Confirm stages : Verify that the business operations.
- Cancel stages : cancel the execution of business operations.
TCC submitted to the transaction processing flow is similar to 2PC two stages, but 2PC usually at DB level, while the TCC is essentially 2PC application level, need to be implemented by the business logic. Its advantage is that you can make your own custom database application granularity operation, so as to reduce lock conflict, submitted throughput.
However, the application of invasive very strong, each branch of the business logic required to implement try, confirm, cancel three operations.
TCC diagram is as follows:
3.4 + final message transaction consistency
The so-called news of the transaction is based on a two-stage submission messaging middleware, middleware is a special use in nature, he is a local transaction and a message in a distributed transaction, the guarantee or local operation is successful and outgoing messages succeed or both fail, the open source RocketMQ to support this feature, specific principles are as follows:
Proceed as follows:
1 ,: A sends a provisioning message service message to the middleware.
2, messaging middleware ready to save the message and return to success.
3. A service performs local affairs.
4, the service A transmits a commit message to the messaging middleware, service B executing local transactions after receiving the message.
Submit are often used in highly concurrent scenario, the demolition of a distributed transaction into a transaction message (+ local operation messaging service A) + B based on local operation service message middleware two phases, wherein the operation by the message service B drive, as long as the message transaction is successful, the service a certain success, the message must be sent, and this time the service B will receive a message to local operation, if the local operation fails, the message will re-enter until the service B operation is successful, so to disguise a distributed transaction a and B, respectively.
More than a few steps there may be exceptions, now analyze them:
Step one mistake: the entire transaction fails, will not perform the service A local operation.
Step two mistakes: the entire transaction fails, will not perform the service A local operation.
Step three errors: a message needs to be done to roll back ready to implement a messaging middleware A callback interface by the service, messaging middleware will continue to perform the callback interface, check whether the service A transaction execution is successful, and if that fails then the message is ready to roll back.
Step four mistakes: this time the local transaction A service is successful, but the message does not require middleware to roll back, in fact, can be checked through the callback interface, messaging middleware to service A is executed successfully, and this time did not really need the service made a commit message , and messaging middleware can submit their own messages, thus completing the entire message transaction.
Reference article:
1 https://www.cnblogs.com/xifenglou/p/8440836.html
2、https://blog.csdn.net/skyie53101517/article/details/80741868