“This is the 9th day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021.”
2PC
introduce
Two-phase Commit (2PC for short) scheme, also known as a protocol, literally means that a transaction is committed in Two phases. The whole scheme is divided into Two important phases during the execution of a distributed transaction:
The preparation Phase: Affairs sponsors by the transaction manager to launch a distributed transaction, the transaction coordinator (transaction manager) notify each transaction parties (explorer), send them a prepare instruction, each participant or return failure, or to perform local affairs (branch), write local undo and redo logs, However, without committing a transaction, a critical state is reached where each participant holds the lock resources involved in the current local transaction.
Commit Phase: The transaction coordinator collects the information returned by all transaction participants in the first Phase. If all participants are successful, it notifies all participants to Commit. If any return fails or times out, it notifies all participants to Rollback. Participants perform commit or rollback operations on the coordinator’s instructions to release lock resources used during all transactions.
advantages
- The database level (resource manager) level controls distributed transactions, while the business level is non-aware or less intrusive
- Strong consistency
disadvantages
- Synchronization blocking problem. During execution, all participating nodes are transaction blocking. When a participant occupies a common resource, other third party nodes have to block access to the common resource.
- Single point of failure. Because of the importance of the coordinator, if the coordinator fails. The participants will keep blocking. Especially in phase 2, when the coordinator fails, all participants are still locked in the transaction resources and cannot continue to complete the transaction. (If the coordinator is down, you can re-elect a coordinator, but you can’t solve the problem of participants being blocked because the coordinator is down)
- The data are inconsistent. In phase 2 of the two-phase commit, after the coordinator sends a COMMIT request to the participant, a local network exception occurs or the coordinator fails during the commit request, which results in only a subset of the participant receiving the commit request. These participants perform the COMMIT operation after receiving the COMMIT request. However, other parts of the machine that do not receive the COMMIT request cannot perform the transaction commit. So the whole distributed system will appear data inconsistency phenomenon.
- The problem that phase 2 failed to resolve: The coordinator went down after issuing a COMMIT message, and the only participant who received the message went down at the same time. So even if the coordinator creates a new coordinator by election agreement, the status of the transaction is uncertain, and no one knows whether the transaction has been committed.
Due to the defects of two-stage submission, such as synchronous blocking, single point of problem and brain split, researchers improved the two-stage submission and proposed three-stage submission.
3PC
Compared to phase 2 commit, phase 3 commit has several upgrades:
- The three-phase commit protocol introduces a timeout mechanism.
- In the first and second phases, a preparatory phase is introduced. The state of each participating node is consistent before the final submission stage.
In addition to introducing the timeout mechanism, 3PC splits the preparation phase of 2PC into two phases again, so that there are three phases of CanCommit, PreCommit, and DoCommit.
Detailed introduction of the three stages
Similar to 2PC preparation (phase 1). The coordinator sends a COMMIT request to the participant, who returns a Yes response if he can commit, or a No response otherwise.
- Transaction query: The coordinator sends a CanCommit request to the participant. Asks if a transaction commit operation can be performed. It then waits for the participant’s response.
- After receiving a CanCommit request, the participant normally returns a Yes response and goes into the preparatory state if it thinks it can execute the transaction successfully. Otherwise, feedback No.
Phase two (PreCommit phase) The coordinator decides whether to proceed with the PreCommit operation of the transaction based on the response of the participant.
There are two cases in this stage:
Transaction pre-commit: When all participants report YES
1. Send a PreCommit request: The coordinator sends a PreCommit request to the participant and enters the Prepared phase.
2. Transaction PreCommit: After receiving a PreCommit request, a participant performs a transaction and records undo and redo information to the transaction log.
3. Response feedback: If the participant successfully executes the transaction, it will return an ACK response and wait for the final instruction.
Interrupt transaction: If either participant sends a No response to the coordinator, or if the coordinator does not receive a response from the participant after a timeout, the interrupt transaction is performed. Details are as follows:
1. Send interrupt requests: The coordinator sends abort requests to all participants.
2. Interrupt a transaction participant performs an interrupt of a transaction after receiving an ABORT request from the coordinator (or after a timeout, but still no request from the coordinator).
Stage 3 (DoCommit stage) In this stage, there are also two situations: 1, all participants feedback Ack response, 2, any participant feedback NO, or the coordinator cannot receive feedback from all participants after timeout, that is, the transaction is interrupted. Commit transaction: (A true transaction commit is performed when all participants report back an Ack response.) 1. If the coordinator is working, issue a DO Commit request to all participants. 2. After receiving the DO Commit request, the participant formally executes the transaction Commit and releases the resources occupied during the entire transaction. 3. Each participant feedback the Ack completion message to the coordinator. 4. When the coordinator receives the Ack message from all participants, the transaction is committed. Abort transaction: (when any participant reports NO, or the coordinator does not receive feedback from all participants after a timeout.) 1. If the coordinator is in a working state, abort requests are made to all participants. 2. The participant uses the Undo information in phase 1 to roll back and release the resources occupied during the entire transaction. 3. Each participant feedback the Ack completion message to the coordinator. 4. After receiving Ack messages from all participants, the coordinator completes the transaction interruption.
Note: After phase 3, participants are unable to receive do Commit or ABORT requests from the coordinator, regardless of whether the coordinator has a problem or the coordinator/participant network has a problem. At this point, participants continue to commit after waiting for a timeout.
advantages
As opposed to the two-phase commit protocol
- Reduces the blocking range of participants
- Continue to reach agreement after a single point of failure
disadvantages
After receiving the PreCommit message, if the network is partitioned, the coordinator and some participants cannot communicate with each other normally, and these participants will still commit transactions, resulting in data inconsistency.
This article has participated in the activity of “New person creation Ceremony”, and started the road of digging gold creation together.