----- the next day -----
————————————
If there is no distributed transaction:
In a series of microservice systems, what would happen if there were no distributed transactions? Let's take the commonly used transaction business in the Internet as an example:
The figure above contains two independent microservices for inventory and order, and each microservice maintains its own database.
In the business logic of the trading system, a commodity needs to call the inventory service to deduct inventory before placing an order, and then call the order service to create an order record.
Under normal circumstances, the two databases are updated successfully, and the data on both sides maintains consistency.
However, under abnormal circumstances, it is possible that the deduction of inventory is completed, and the subsequent order record fails to be inserted for some reason. At this time, the data on both sides has lost its due consistency.
What is a distributed transaction?
Distributed transactions are used to ensure data consistency between different nodes in a distributed system.
There are many implementations of distributed transactions, the most representative of which is the XA distributed transaction protocol proposed by the Oracle Tuxedo system.
The XA protocol includes two implementations: two-phase submission (2PC) and three-phase submission (3PC). Here we focus on the specific process of two-phase submission.
In the game of World of Warcraft, when the copy group plays the BOSS, in order to facilitate the collaboration between the captain and the team members, the captain can initiate an "in-place confirmation" operation:
When the team member receives the prompt to confirm the position, if it is already in place, choose "Yes", if it is not already in place, choose "No".
When the captain receives the confirmation of the in-place of all people, he will publish a message to all the players, telling them to start playing BOSS.
Correspondingly, when the captain initiates the confirmation of seating, it is possible that some players have not been seated:
The above is the confirmation process of group playing BOSS in World of Warcraft. This process is very similar to the two-phase commit of the XA distributed transaction protocol.
So what does the XA protocol look like? There are two roles in the XA protocol: transaction coordinator and transaction participant.
Let's take a look at the interaction process between them:
The first stage:
In the first phase of XA distributed transactions, the node acting as the transaction coordinator will first send Prepare requests to all participant nodes.
After receiving the Prepare request, each participant node will perform data update related to the transaction and write it to Undo Log and Redo Log.
If the participant executes successfully, he does not submit the transaction temporarily, but returns a "complete" message to the transaction coordination node.
When the transaction coordinator receives the return messages from all participants, the entire distributed transaction will enter the second stage.
second stage:
In the second phase of XA distributed transactions, if the transaction coordinating node has received a positive return before, then it will issue a Commit request to all transaction participants.
After receiving the Commit request, the transaction participant nodes will each commit local transactions and release the lock resources.
When the local transaction completes the commit, it will return a "complete" message to the transaction coordinator.
When the transaction coordinator receives "completion" feedback from all transaction participants, the entire distributed transaction is completed.
The first stage:
second stage:
In the first stage of XA, if a transaction participant reports a failure message, it means that the node's local transaction was not successful and must be rolled back.
So in the second phase, the transaction coordination node sends Abort requests to all transaction participants.
After receiving the Abort request, each transaction participant node needs to perform the transaction rollback operation locally, and the rollback operation is performed in accordance with Undo Log.
The above is the detailed process of XA two-phase agreement submission.
What are the shortcomings of XA two-phase submission?
1. Performance issues
The XA protocol follows strong consistency.
In the process of transaction execution, each node occupies database resources. Only when all nodes are ready, the transaction coordinator will notify the submission, and the participants release the resources after submission.
Such a process has very obvious performance problems.
2. The coordinator's single point of failure
The transaction coordinator is the core of the entire XA model. Once the transaction coordinator node hangs up, the participant will not receive a commit or rollback notification, and the participant will always be in an intermediate state and cannot complete the transaction.
3. Inconsistencies caused by missing messages.
In the second stage of the XA protocol, if a local network problem occurs, some transaction participants receive a commit message, and another part of the transaction participants do not receive a commit message, which results in inconsistent data between nodes.
How to avoid the various issues submitted by XA in two stages? There are many other distributed transaction options to choose from:
1. XA three-phase submission
XA three-phase submission adds CanCommit phase on the basis of two-phase submission, and introduces a timeout mechanism.
Once the thing participant has not received the coordinator's commit request, it will automatically commit locally.
This effectively solves the problem of the coordinator's single point of failure. But performance issues and inconsistencies are still not fundamentally resolved.
2. MQ transaction
Use message middleware to asynchronously complete the second half of the transaction update to achieve the final consistency of the system.
This approach avoids performance problems like the XA protocol.
3. TCC affairs
TCC transaction is an abbreviation of Try, Commit and Cancel. The logic mode is similar to XA two-phase commit, but the implementation method is artificially implemented at the code level.
Interesting comic-style learning, pay attention to the programmer's small gray public number so that your learning is no longer boring.
Programmer Xiaohui's latest published book: Comic Algorithm-Xiaohui's Algorithm Journey