Distributed transaction-two-phase commit (2PC-Prepare/Commit)

Original: 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 one is the XA distributed transaction protocol proposed by the Oracle Tuxedo system.

The XA protocol includes two implementations of two-phase commit (2PC) and three-phase commit (3PC). Here we focus on the specific process of two-phase commit.

There are two roles in the XA protocol: transaction coordinator and transaction participant .

The forward process of XA two-phase submission

The first stage

XA protocol role

  1. In the first stage of the XA distributed transaction, the node as the transaction coordinator will first send a Prepare request to all participant nodes.
  2. After receiving the Prepare request, each participant node will perform transaction-related data updates and write them to Undo Log and Redo Log. If the participant executes successfully, the transaction will not be submitted for the time being, but a "done" message will be returned to the transaction coordination node.
  3. When the transaction coordinator receives the return message from all participants, the entire distributed transaction will enter the second phase.

second stage

second stage

  1. In the second stage of the XA distributed transaction, if the transaction coordinator node has received all positive returns before, then it will issue a Commit request to all transaction participants.
  2. After receiving the Commit request, the transaction participant nodes will each commit the local transaction and release the lock resources. When the local transaction is committed, it will return a "complete" message to the transaction coordinator.
  3. When the transaction coordinator receives "done" feedback from all transaction participants, the entire distributed transaction is completed.

The processing flow of the failure of the XA two-phase submission

The first stage

The first stage
In the first stage of XA, if a transaction participant feeds back a failure message, it means that the node's local transaction execution is unsuccessful and must be rolled back.

second stage

second stage

So in the second stage, the transaction coordination node sends Abort requests to all transaction participants. After receiving the Abort request, each transaction participant node needs to roll back the transaction locally, and the rollback operation is performed in accordance with Undo Log.

Insufficiency of XA two-phase submission

1. Performance issues
XA协议遵循强一致性 . 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 will release the resources after submission. Such a process has very obvious performance problems.

2. The single point of failure of the
coordinator The transaction coordinator is the core of the entire XA model. Once the transaction coordinator node hangs up, and the participant cannot receive the commit or rollback notification, the participant will always be in an intermediate state and cannot complete the transaction.

3. Inconsistency caused by missing messages.
In the second stage of the XA protocol, if a local network problem occurs, some transaction participants receive the commit message, and the other part of the transaction participant does not receive the commit message, then data inconsistency between nodes will result.

Other distributed transaction solutions

How to avoid the problems of XA two-phase submission? There are many other distributed transaction schemes to choose from:

1. XA three-phase submission

XA three-phase commit adds the CanCommit phase to the two-phase commit , and introduces a timeout mechanism . Once the transaction participant has not received the commit request from the coordinator for a long time, the local commit will be performed automatically. This effectively solves the problem of a single point of failure of the coordinator. However, performance issues and inconsistencies are still not fundamentally resolved.

2. MQ transaction

Use message middleware to asynchronously complete the second half of the transaction to achieve the final consistency of the system . This approach avoids performance issues like the XA protocol.

3.TCC affairs

TCC transaction is the abbreviation of Try, Commit, and Cancel instructions. Its logic mode is similar to XA two-phase commit, but the implementation method is artificially implemented at the code level .

Guess you like

Origin blog.csdn.net/eluanshi12/article/details/84660913