Distributed Transaction Project (3) : 2PC for Distributed Transaction Solutions (Two-Phase Commit)

Directory:

• Basic concept

• Distributed transaction theory

• Distributed Transaction Solution 2PC (This chapter)

• TCC for distributed transaction solutions

• Reliable message final consistency for distributed transaction solutions

• Best efforts notification for distributed transaction solutions

• Distributed transaction synthesis case study

1. Basic concepts

2. Basic theory of distributed transactions

3. 2PC for Distributed Transaction Solution (Two-phase Commit)

We have already studied the basic theory of distributed transaction, based on the theory, for C, TCC, reliable message final consistency, best effort notification.

3.1. What is 2PC

2PC is the two-phase commit protocol, which divides the whole transaction process into two phases: Prepare phase and commitphase. 2 refers to two phases, P refers to the preparation phase, and C refers to the commitphase.

For example:

Zhang SAN and Li Si haven’t seen each other for a long time. An old friend is about to have a dinner party. The restaurant owner asks to pay first before he can issue a ticket. At this time, Zhang SAN and Li Si respectively complain about the current situation is not satisfactory, poor money, are not willing to treat, then only AA. The boss can arrange the meal only if John and Lisa pay. However, as Both Zhang SAN and Li Si are iron cocks, an awkward scene is formed: ** Preparation stage: ** The boss asks Zhang SAN to pay, and Zhang SAN pays. The boss demands payment from Li4. Li4 pays. ** Submission stage: the boss of ** issues the ticket, and two people take the ticket and sit down for dinner.

In the computer, some relational databases such as Oracle and MySQL support the two-phase commit protocol, as shown in the following figure:

** The transaction manager sends a Prepare message to each participant. Each participant performs the transaction locally and writes a local Undo/Redo log. (Undo log records data before modification and is used for database rollback. Redo log records data after modification and is used for writing data files after transaction commit.)

Commit phase: ** If the transaction manager receives an execution failure or timeout message from each participant, it sends a Rollback message to each participant. Otherwise, send a Commit message; According to the instructions of the transaction manager, participants perform commit or rollback operations and release lock resources used during transaction processing. Note: Lock resources must be released at the last stage.

The following figure shows the two phases of 2PC, with success and failure:

Success:

Failure conditions:

3.2. Solutions

3.2.1 XA scheme

The traditional 2PC scheme is implemented at the database level. For example, Oracle and MySQL all support 2PC protocol. In order to unify standards and reduce unnecessary docking costs in the industry, standardized processing model and interface standards need to be developed. The International Open Group defines the Distributed Transaction Processing Reference Model (DTP).

In order to make the content of XA program more clear, the following new user registration points as an example to illustrate:

The execution process is as follows:

1. The application (AP) holds two data sources, the user library and the credits library.
2. The application program (AP) notified the user database RM of adding a user through TM and the integration database RM of adding points for the user. At this time, RM did not submit a transaction, and the user and the integration resources were locked.
3. After receiving the execution reply, TM will initiate rollback transactions to other RMS as long as either party fails. After rollback, resource lock will be released.
4. After receiving the execution reply, TM successfully initiates the submission transaction to all RMS. After the submission, the resource lock is released.

The DTP model defines the following roles:

• Application Program (AP) : an Application Program that uses DTP distributed transactions.
• Resource Manager (RM) : refers to the participant of a transaction. Generally, it refers to a database instance. The Resource Manager controls the database, and the Resource Manager controls branch transactions.
• Transaction Manager (TM) : A Transaction Manager that coordinates and manages transactions. The Transaction Manager controls global transactions, manages Transaction lifecycles, and coordinates RMS. Global transaction refers to the distributed transaction processing environment, need to operate multiple databases to complete a work, this work is a global transaction.
• DTP model defines the interface specification for communication between TM and RM called XA, which is simply understood as 2PC interface protocol provided by database. The realization of 2PC based on DATABASE XA protocol is also called XA scheme.

The interaction between the three roles is as follows:

1. TM provides an application programming interface to the AP through which the AP commits and rolls back transactions.
2. TM transaction middleware notifies RM of database transaction start, end, commit, rollback, etc., through XA interface.

Conclusion:

The whole 2PC transaction process involves three roles AP, RM and TM. AP refers to applications that use 2PC distributed transactions; RM stands for resource manager, which controls branch transactions; TM refers to the transaction manager, which controls the entire global transaction.

1. In the preparation phase, THE RM performs actual service operations, but does not commit transactions, and resources are locked.
2. In the commit phase, TM will accept the reply from RM in the preparation phase. If any RM fails to execute the transaction, TM will notify all RMS to perform the rollback operation; otherwise, TM will notify all RMS to commit the transaction. The commit phase ends and the resource lock is released.

Problems with XA schemes:

Local databases are required to support XA.

Resource locks are not released until the end of two phases, resulting in poor performance.

3.2.2 Seata scheme

Seata is an open source project Fescar initiated by Ali middleware team, later renamed Seata, which is an open source distributed transaction framework.

Seata solves the problem of traditional 2PC by coordinating branch transactions of local relational databases to drive the completion of global transactions. Seata is middleware that works at the application layer. The main advantage is that it has good performance and does not occupy connection resources for a long time. It solves the problem of distributed transaction in microservice scenarios with high efficiency and zero intrusion on business. AT present, it provides distributed transaction solutions in AT mode (2PC) and TCC mode.

The design philosophy of Seata is as follows:

One of Seata’s design goals is to be non-intrusive, so it starts with a non-intrusive 2PC solution, evolves on the basis of the traditional 2PC solution, and solves the problems faced by the 2PC solution.

Seata understands a distributed transaction as a global transaction that contains several branch transactions. The responsibility of a global transaction is to coordinate the branch transactions under its jurisdiction to agree on either a successful commit together or a failed rollback together. In addition, the branch transaction itself is usually a local transaction of a relational database. The following diagram shows the relationship between global transactions and branch transactions:

Similar to the traditional 2PC model, Seata defines three components to protocol the processing of distributed transactions:

• A Transaction Coordinator (TC) is an independent middleware that needs to be deployed and run independently. It maintains the running status of global transactions, receives TM instructions to initiate the submission and rollback of global transactions, and communicates with RM to coordinate the submission or rollback of branch transactions.
• Transaction Manager (TM) : A Transaction Manager that needs to be embedded in the application to work, which is responsible for starting a global Transaction and ultimately issuing a global commit or global rollback instruction to the TC.
• Resource Manager (RM) : Controls branch transactions, is responsible for branch registration and status reporting, receives instructions from transaction coordinator TC, and drives the submission and rollback of branch (local) transactions.

Here’s an example of Seata’s distributed transaction process:

The specific execution process is as follows:

1. The TM of the user service applies to the TC for starting a global transaction. The global transaction is successfully created and a globally unique XID is generated.
2. The RM of the user service registers the branch transaction with the TC, which performs the new user logic in the user service and brings it under the jurisdiction of the global transaction corresponding to the XID.
3. The user service performs a branch transaction, inserting a record into the user table.
4. The logic is executed until the integral service is called remotely (the XID is propagated in the context of the microservice invocation link). The RM of the integral service registers a branch transaction with TC, which performs the logic of adding points and brings it into the jurisdiction of the XID corresponding global transaction.
5. The integral service performs a branch transaction, inserts a record into the integral record table, and returns to the user service after execution.
6. The user service branch transaction is complete.
7. TM initiates a global commit or rollback resolution against the XID to TC.
8. TC schedules all branch transactions under XID to complete commit or rollback requests.

Seata implementation of 2PC and traditional 2PC differences:

In terms of architecture level, the RM of the traditional 2PC scheme is actually in the database layer, and RM is essentially the database itself, implemented through XA protocol, while THE RM of Seata is deployed in the application program side in the form of JAR package as the middleware layer.

In terms of two-phase commit, traditional 2PC holds locks on transactional resources until Phase E2 is complete, regardless of whether the second phase resolution is COMMIT or ROLLBACK. Instead, Seata commits the local transaction at Phase1, which saves Phase2 from being locked and improves overall efficiency.