< from Paxos to zookeeper distributed consistency principles and practices > Reading notes-two phase commit and three-phase commit

I. BACKGROUNDThe first chapter of this book, distributed architecture, writes from a stand-alone acid to a distributed cap. See the previous article. This is the second chapter of the consistency agreement part, divided into two pieces of finishing. In a distributed system, in order to ensure high data availability, we typically keep multiple copies of the data (replica), which are placed on different physical machines. In order to provide users with the correct semantics such as add \ Delete \ r \ r, we need to ensure that the copies placed on different physical machines are consistent.
in order to solve this distributed consistency problem, there are many classical algorithms: such as two-phase commit, three-phase commit, Paxos algorithm.
Two or two phase commit (2PC)
Two-phase commit (Two-phasecommit) is an algorithm designed to maintain atomicity and consistency across all nodes in a distributed system architecture, in the domain of computer networks and databases. Typically, a two-phase commit is also known as a protocol. in a distributed system, each node, while aware of its own operation, succeeds or fails, does not know the success or failure of the operation of the other node. When a transaction spans multiple nodes, in order to maintain the acid nature of the transaction, it is necessary to introduce a component that acts as a coordinator to unify the operation results of all nodes (called contributors) and ultimately to indicate whether the nodes are actually committing the results of the operation. the two-phase submission algorithm idea can be summed up as follows: Participants will notify the coordinator of the success or failure of the operation, and then the coordinator based on the feedback of all participants to determine whether the participants to commit or abort the operation.
2.1 Protocol Description:Phase One: Commit a transaction request

1) The coordinator node asks all participant nodes if they can perform the commit operation (vote) and begins to wait for the response from each participant node.

2) The Contributor node performs all transaction operations up to the start of the query and writes the undo and redo information to the log.

3) Each participant node responds to a query initiated by the coordinator node. If the transaction operation of the contributor node is actually successful, it returns a "YES" message, or it returns a "NO" message if the actor node's transaction operation fails to execute.

Stage one is called also the polling stage.

Stage Two: Executing a transaction request The facilitator will decide whether or not the event can be submitted according to the feedback of each participant, so it is divided into the following two situations: performing a thing submissionWhen the coordinator node obtains the corresponding message from all participant nodes as "YES":

The Coordinator node issues a "formal commit" request to all participant nodes.

2) The Participant node formally completes the operation after accepting the commit request and frees the resources that were consumed during the entire transaction period.

3) The Contributor node sends an "ACK" message to the Coordinator node.

4) The coordinator node completes the transaction after the "ACK" message that is fed back by all participant nodes.

Break Things
If either participant node returns a response message of "NO" in the first stage, or if the coordinator node cannot get the response message for all contributor nodes before the first phase of the query times out, then the thing is interrupted.

1) The Coordinator node issues a "rollback operation (rollback)" Request to all participant nodes.

2) The Contributor node takes advantage of the undo information previously written to perform the rollback and frees the resources that were consumed during the entire transaction period.

3) The Contributor node sends an "ACK" message to the Coordinator node.

4) The Coordinator node is interrupted by an "ACK" message that is fed back by all participant nodes.

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

The flowchart is as follows:
In a nutshell: Two-phase submission divides the processing of a thing into a polling and execution phase, a process of first-attempt re-submission, and a strong consistency algorithm.2.2 Advantages and disadvantages:Advantages: Simple principle, easy to achieve. Disadvantages:

1, synchronous blocking problem . During execution, all participating nodes are transaction-blocked. When a participant occupies a public resource, other third-party nodes must be blocked from accessing the public resources.

2. single point of failure . Because of the importance of the Facilitator, once the coordinator fails. The participants will continue to block. Especially in the second phase, when the coordinator fails, all the participants are in the state of the locked transaction resource and cannot continue to complete the transaction operation. (if the coordinator hangs up, you can re-elect a coordinator, but it is not possible to resolve the problem that the participant is blocked due to a coordinator outage)

3, inconsistent data . In phase two of phase two submission, when a coordinator sends a commit request to a participant, a local network exception occurs, or the coordinator fails during the sending of a commit request, which results in only a subset of the participants accepting the commit request. The commit is executed after the participant receives a commit request. However, other parts of the machine that are not receiving a commit request cannot perform transactional commits. Therefore, the whole distributed system has the consistency of the data division phenomenon.

4, too conservative: Two stage submission lacks a more perfect fault-tolerant mechanism, the failure of any one node leads to the failure of the whole thing.

three or three phase commit (3PC)A three-phase commit (Three-phase commit), also known as a three-phase commit protocol (three-phase commit protocol), is an improved version of two-phase commit (2PC).
3.1 Protocol Descriptioncancommit , precommit , docommit A three stages. as follows:
3.1.1CanCommit Stage

The cancommit phase of 3PC is actually much like the 2PC prep phase. The coordinator sends a commit request to the participant, and the participant returns a Yes response if it can commit, otherwise returns no response.

1. Transaction Enquiry

The coordinator sends a CANCOMMIT request to the participant. asks if the transaction commit operation can be performed. It then begins to wait for the participant's response.

2. Response Feedback

After a participant receives a CANCOMMIT request, normally, if it thinks it can perform the transaction successfully, it returns a Yes response and enters the standby state. Otherwise feedback no

3.1.2PreCommit Stage

The facilitator decides whether the precommit operation of the memory can be done according to the reaction of the participants. According to the response, there are two possible.

Perform a transaction pre-commit

The pre-execution of a transaction is performed if the feedback received by the facilitator from all participants is a Yes response.

1. Send the pre-submission request Coordinator to send the PRECOMMIT request to the participant and enter the prepared phase.

2. After the transaction pre-submission participant receives the PRECOMMIT request, the transaction operation is performed and the undo and redo information is logged to the transaction log.

3. Response Feedback If a participant succeeds in performing a transactional operation, an ACK response is returned, and the final instruction is started waiting.

Break Things

If any participant sends no response to the Coordinator, or waits for a timeout, the coordinator does not receive a response from the participant, then the transaction is interrupted.

1. The Send interrupt Request Coordinator sends an abort request to all participants.

2. The interrupt transaction participant receives an abort request from the Coordinator (or after a timeout has not received a request from the coordinator) to perform a transaction interruption.

3.1.3docommit Stage

This phase of real transaction submission can also be divided into the following two scenarios.

Execute commit

1. The Send submission request coordinates the receipt of the ACK response sent by the participant, then he enters the submission status from the pre-commit state. and send Docommit requests to all participants.

2. After the transaction submission participant receives the DOCOMMIT request, it performs a formal transaction submission. and frees all transactional resources after the transaction commits are completed.

3. After the response feedback transaction is submitted, an ACK response is sent to the coordinator.

4. complete the transaction after the transaction Coordinator receives an ACK response from all participants.

Interrupt Transaction

The coordinator does not receive an ACK response sent by the participant (either the recipient sends an ACK response or the response time-out), and the interrupt transaction is executed.

1. Send Interrupt Request Coordinator sends abort request to all participants

2. The transaction rollback participant receives the abort request, takes advantage of the undo information it records in phase two to perform the rollback operation of the transaction, and releases all transaction resources after the rollback is complete.

3. Feedback results After the transaction is rolled back by the participant, an ACK message is sent to the Coordinator

4. After the interrupt transaction coordinator receives an ACK message from the contributor's feedback, it performs a transaction interruption.

Attention:

Phase three, which may occur: The coordinator has a problem and the coordinator and participant network fails. Regardless of which exception will cause the participant to not receive a docommit or Rebort request from the coordinator in time, the participant will continue to commit the transaction after waiting for the timeout.

3.2 Advantages and Disadvantages:

Pros: 3PC primarily addresses a single point of failure and reduces the blocking range, because once a participant is unable to receive timely information from the Coordinator, he will execute the commit by default. It does not always hold transactional resources and is in a blocking state.

Cons: Introduce a new problem, if a network partition occurs, the coordinator sends an abort response that is not received by the participant in a timely manner, then the participant performs a commit operation after waiting for the timeout. This is a case of inconsistent data between the other participants who received the abort command and performed the rollback.

For 2PC, 3PC can not completely solve the distributed consistency problem, is Paxos. The next piece of finishing.

< from Paxos to zookeeper distributed consistency principles and practices > Reading notes-two phase commit and three-phase commit