Shulou(Shulou.com)06/02 Report--

We have methods to implement transaction ACID attributes in general relational databases of practical point databases, such as UNDO,REDO and so on. But how to ensure the consistency of data when using distributed database? A typical impact scenario is the bank transfer that you have heard many times. If user An is transferring money to user B across banks. Therefore, how to ensure the ACID of distributed transactions, there are more mature solutions, generally 2-segment commit 2PC protocol or improved version, that is, 3-segment commit 3PC protocol, the following is a brief introduction.

2PC protocol has also become 2-segment commit, 1prepare phase, and 2commit phase.

The so-called two stages are: the first stage: the preparatory stage (voting stage) and the second stage: the submission stage (implementation phase).

Preparation stage

The transaction coordinator (transaction manager) sends Prepare messages to each participant (resource manager), and each participant either returns a failure directly (such as permission verification failure), or executes the transaction locally, writing local redo and undo logs, but not committing, reaching a state of "everything is ready, only Dongfeng".

The preparation phase can be further divided into the following three steps:

1) the coordinator node asks all participant nodes if they can perform a submit operation (vote) and starts waiting for a response from each participant node.

2) the participant node performs all transaction operations until the query is initiated, and writes Undo information and Redo information to the log. (note: if successful, each participant has actually performed a transaction operation.)

3) each participant node responds to the query initiated by the coordinator node. If the participant node's transaction operation actually succeeds, it returns a "consent" message; if the participant node's transaction operation actually fails, it returns an "abort" message.

Submission stage

If the coordinator receives a failed message from the participant or times out, a Rollback message is sent directly to each participant; otherwise, a Commit message is sent; the participant performs a commit or rollback operation according to the coordinator's instructions, releasing all lock resources used in the transaction. (note: lock resources must be released in the final phase)

Next, the process of the submission phase is discussed in two cases.

When the corresponding message received by the coordinator node from all participant nodes is "agree":

1) the coordinator node issues an "commit" request to all participant nodes.

2) the participant node officially completes the operation and releases the resources occupied during the entire transaction.

3) the participant node sends a "finish" message to the coordinator node.

4) after receiving the "done" message from all participant nodes, the coordinator node completes the transaction.

If the response message returned by any participant node in the first phase is aborted, or if the coordinator node is unable to get the response messages from all participant nodes before the challenge timeout in the first phase:

1) the coordinator node issues a "rollback operation (rollback)" request to all participant nodes.

2) the participant node performs a rollback using the previously written Undo information and releases the resources occupied during the entire transaction.

3) the participant node sends a "rollback complete" message to the coordinator node.

4) after receiving the "rollback complete" message from all participant nodes, the coordinator node cancels the transaction.

Regardless of the final outcome, the second phase ends the current transaction.

Two-phase commit does seem to provide atomic operations, but unfortunately, two-phase commit has several disadvantages:

1. Synchronous blocking problem. During execution, all participating nodes are transaction blocking. When participants occupy public resources, other third-party nodes have to be blocked to access public resources.

2. Single point of failure. Because of the importance of the coordinator, once the coordinator fails. The participants will block all the time. Especially in the second phase, when the coordinator fails, all the participants are still in the state of locking transaction resources and cannot continue to complete the transaction operation. (if the coordinator dies, a coordinator can be re-elected, but the problem that participants are blocked due to coordinator downtime cannot be resolved.)

3. The data are inconsistent. In the second phase of the two-stage submission, when the coordinator sends the commit request to the participants, a local network exception occurs or the coordinator fails in the process of sending the commit request, which results in only a part of the participants receiving the commit request. After this part of the participant receives the commit request, the commit operation is performed. However, other machines that do not receive a commit request cannot perform a transaction commit. As a result, the whole distributed system has the phenomenon of data department consistency.

4. The problem that cannot be solved in the second phase: the coordinator goes down after sending the commit message, and the only participant who receives the message is also down. So even if the coordinator produces a new coordinator through the election protocol, the status of the transaction is uncertain, and no one knows whether the transaction has been committed.

Because of the defects of two-stage submission, such as synchronous blocking, single-point problem, brain fissure and so on, the researchers made improvements on the basis of two-stage submission and proposed three-stage submission.

PC

Three-phase commit (Three-phase commit), also known as three-phase commit protocol (Three-phase commit protocol), is an improved version of two-phase commit (2PC).

Unlike two-phase commit, three-phase commit has two change points.

1. Introduce the timeout mechanism. At the same time, the timeout mechanism is introduced in both the coordinator and the participants.

2. Insert a preparatory phase in the first and second stages. It ensures that the status of the participating nodes is consistent before the final submission phase.

In other words, in addition to introducing the timeout mechanism, 3PC again divides the preparation phase of 2PC into two, so that the three-phase commit has three phases: CanCommit, PreCommit, and DoCommit.

CanCommit stage

The CanCommit phase of 3PC is actually very similar to the preparatory phase of 2PC. The coordinator sends a commit request to the participant, and the participant returns the Yes response if it can be submitted, otherwise the No response is returned.

1. The transaction asks the coordinator to send a CanCommit request to the participant. Ask if a transaction commit operation can be performed. Then start waiting for a response from the participant.

two。 Response feedback after the participant receives the CanCommit request, normally, if he or she thinks the transaction can be executed smoothly, he or she returns the Yes response and enters the standby state. Otherwise, feedback No

PreCommit stage

The coordinator decides whether the PreCommit operation of the transaction can be memorized according to the reaction of the participants. Depending on the response, there are two possibilities.

If the coordinator gets a Yes response from all the participants, then the transaction is pre-executed.

1. The coordinator sends a PreCommit request to the participant and enters the Prepared phase.

two。 After the transaction pre-commit participant receives the PreCommit request, the transaction operation is performed and the undo and redo information is recorded in the transaction log.

3. Response feedback if the participant successfully executes the transaction operation, the ACK response is returned and the final instruction begins to wait.

If any participant sends a No response to the coordinator, or if the coordinator does not receive a response from the participant after the wait timeout, the transaction is interrupted.

1. Send interrupt request coordinator sends an abort request to all participants.

two。 Interrupt the transaction participant executes the interruption of the transaction after receiving the abort request from the coordinator (or after the timeout, still not receiving the request from the coordinator).

DoCommit stage

The real transaction commit at this stage can also be divided into the following two situations.

Execute submission

1. Send submit request Coordination receives the ACK response sent by the participant, then he will go from the pre-submitted state to the submitted state. And send a doCommit request to all participants.

two。 After the transaction commit participant receives the doCommit request, the formal transaction commit is performed. And release all transaction resources after the transaction commit is completed.

3. Response feedback after the transaction is committed, an Ack response is sent to the coordinator.

4. After the transaction coordinator receives the ack response from all participants, the transaction is completed.

If the interrupt transaction coordinator does not receive an ACK response from the participant (either the recipient sends an ACK response or the response times out), the interrupt transaction is executed.

In the doCommit phase, if the participant is unable to receive the doCommit or rebort request from the coordinator in time, the transaction commit will continue after the wait timeout. In fact, this should be decided on the basis of probability. When entering the third stage, it indicates that the participant has received the PreCommit request in the second stage, then the prerequisite for the coordinator to generate the PreCommit request is that he receives Yes from all participants before the start of the second phase. (once the participant receives the PreCommit, it means he knows that everyone actually agrees to modify it.) so, to sum up, when entering the third phase, due to reasons such as network timeout, although the participant did not receive a response from commit or abort, he has reason to believe that there is a good chance of successful submission. )

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.