About distributed transactions, two-phase commit protocol, Sankai commit protocol

With the large number of high-concurrency access, massive data processing and other scenarios more and more, how to achieve the high availability of web sites, scalability, scalability, security and other goals are becoming more and more important. In order to solve such a series of problems, the architecture of large-scale web site is also evolving. To improve the high-availability architecture of a large web site, you have to mention distributed. In the article of distributed consistency, we mainly introduce the consistency problem in distributed system. This article will briefly describe how to effectively resolve distributed consistency issues, including what is distributed transaction, two-phase commit, and three-phase commit. Distributed consistency Review

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 the correct semantics for the user to add \ delete \ change, we need to ensure that the copies placed on different physical machines are consistent.

In order to solve this distributed consistency problem, predecessors summed up many typical protocols and algorithms during the repeated trade-offs between performance and data consistency. Among the more notable are the second-order commit protocol (two Phase commitment Protocol), the Sankai commit protocol (three Phase commitment Protocol), and the Paxos algorithm. Distributed Transactions

A distributed transaction refers to a transaction that involves manipulating multiple databases. In fact, the concept of the same library transaction is extended to the transaction of multiple libraries. The aim is to ensure the consistency of data in distributed systems. The key to distributed transaction processing is that there must be a way to know all the actions that a transaction makes anywhere, and the decision to commit or roll back a transaction must produce a uniform result (commit all or roll back all)

In a distributed system, each node is physically independent from each other, communicating and coordinating through the network. Due to the existence of transaction mechanisms, data operations on each individual node can be guaranteed to satisfy acid. However, it is not possible to accurately know the execution of transactions in other nodes between nodes that are independent of each other. So theoretically, two machines cannot achieve a consistent state in theory. If you want to keep the data consistency across multiple machines in a distributed deployment, then you have to ensure that all data writes are performed on all nodes, either all of them are executed, or none of them are executed. However, a machine cannot know the execution results of local transactions in other machines while performing local transactions. So he did not know whether the transaction should be a commit or roolback. Therefore, the general solution is to introduce a "coordinator" component to uniformly schedule the execution of all distributed nodes. XA specification

The X/open organization (now the Open group) defines a distributed transaction processing model. The X/open DTP Model (1994) includes the application (AP), transaction manager (TM), Resource Manager (RM), Communications Explorer (CRM) four section.    Generally, the common transaction manager (TM) is the transaction middleware, the common Resource Manager (RM) is the database, the common Communication Resource Manager (CRM) is the message middleware. Typically, a transaction within a database, such as operations on multiple tables, is treated as a local transaction.   The transaction object for the database is a local transaction, while the distributed transaction object is a global transaction. The so-called global transactions, refers to the Distributed transaction processing environment, multiple databases may need to work together to complete a task, which is a global transaction, for example, a transaction may update several different databases. Operations on the database occur throughout the system but must be committed or rolled back.     At this point, the submission of a database to its internal operations depends not only on the success of the operation itself, but also on the success of the operation of other databases related to the global transaction, and if any one of the databases fails, all the operations of the database participating in the transaction must be rolled back. In general, a database cannot know what other databases are doing, so in a DTP environment, transactional middleware is required to notify and coordinate the submission or rollback of related databases. A database only alludes its own operations (recoverable) to global transactions.

XA is the interface specification (i.e. interface function) between the transaction middleware defined by the X/open DTP and the database, which is used by the transaction middleware to inform the start, end, and commit, rollback, etc. of the database transaction. XA interface functions are provided by the database vendor.

The second order submission agreement and the Sankai submission agreement are derived from this idea. It can be said that two-phase commit is the key to implementing XA distributed transactions (specifically: the two-phase commit essentially guarantees the atomicity of the distributed transaction: that all nodes are either full or not) 2PC

Two-phase commit (Two-phasecommit) is an algorithm (algorithm) that is designed to maintain consistency across all nodes in a distributed system architecture, in the domain of the computer network and the database, in order to make transactional submissions. Typically, a two-phase commit is also known as a Protocol (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 (such as writing updated data to disk, etc.). Therefore, the two-phase submission algorithm can be summarized as follows: Participants will notify the coordinator of the success or failure of the operation, and then by the coordinator based on the feedback of all participants to determine whether the participants to commit or abort the operation.

The so-called two phases are: The first phase: the preparation phase (polling phase) and the second stage: the Commit phase (the implementation phase). Preparation Phase

The transaction Coordinator (the transaction manager) sends a prepare message to each participant (Resource Manager), each of which either returns a failure directly (such as a permission validation failure), performs a transaction locally, writes the local redo and undo logs, but does not commit to a state of "everything is ready, only owed to the east Wind".

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

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. (Note: If this is successful, each participant has already performed a transactional operation)

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 "consent" message and returns an "abort" message if the transaction operation of the contributor node fails to actually execute. Submission Phase

If the coordinator receives a failure message from the participant or times out, sends a rollback (ROLLBACK) message directly to each participant, otherwise commits the commit message, and the contributor performs a commit or rollback operation based on the coordinator's instructions, releasing the lock resources used during all transaction processing. (Note: The lock resource must be released at the last stage)

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

When the coordinator node obtains the corresponding message from all participant nodes as "consent":

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

2) The Participant node formally completes the operation and releases resources that are occupied during the entire transaction period.

3) The Contributor node sends a "complete" message to the Coordinator node.

4) The coordinator node completes the transaction after the "complete" message is received by all participant nodes.

When the response message returned by either contributor node in the first stage is abort, or the coordinator node fails to get response messages for all contributor nodes before the first phase of the query times out:

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 a ROLLBACK complete message to the coordinator node.

4) The coordinator node cancels the transaction after a "rollback complete" message that is fed back by all participant nodes.

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

Two-phase commits do seem to provide atomic operations, but unfortunately there are several drawbacks to the two-phase commit:

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.

Problems that cannot be resolved in Phase 4, two: The coordinator then goes down after sending a commit message, and the only participant who receives the message is down. So even if the facilitator creates a new coordinator through an electoral agreement, the state of the transaction is uncertain, and no one knows whether the transaction has been committed.

Since the two-phase commit has defects such as synchronous blocking, single point problem, and brain fissure, the researchers have made improvements on the basis of phase two submission and presented three stages. 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).

Unlike two-phase commits, there are two change points for three-phase submissions.

1, introduce the timeout mechanism. The time-out mechanism is introduced in both the coordinator and the participant.
2. Insert a preparatory phase in the first and second phases. Ensures that the state of each participating node is consistent before the final commit phase.

In other words, in addition to the introduction of the timeout mechanism, 3PC 2PC of the preparation phase is again divided into two, so that three-phase commit has Cancommit, Precommit, docommit three stages. Cancommit 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. The transaction asks the facilitator to send the 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. After the response feedback participant receives the 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 precommit 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.

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.

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. Docommit 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.

The interrupt Transaction Coordinator does not receive an ACK response sent by the participant (either the recipient sends an ACK response or the response time-out), then 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.

In the docommit phase, if a participant fails to receive a docommit or Rebort request from the coordinator in time, the commit of the transaction continues after the wait time-out. (In fact, this should be based on probability, when entering the third stage, the participants in the second stage has received the PRECOMMIT request, then the facilitator to produce Precommit request is the precondition that he before the start of the second phase, The Cancommit response received from all participants is yes. (Once the participant receives the precommit, it means he knows that everyone actually agrees to the change) so, in a nutshell, when the third stage, due to network timeouts and other reasons, although the participants did not receive a commit or abort response, but he has reason to believe: the probability of successful submission is very large. ）

the difference between 2PC and 3PC

The single point of failure that is primarily addressed with respect to 2pc,3pc and reduces blocking, 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. However, this mechanism also leads to data consistency because, because of network reasons, the abort response sent by the coordinator is not received by the participant in time, so the participant executes a commit 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.

With 2PC and 3PC in view, we can see that the distributed consistency problem cannot be completely solved by either two-phase commit or three-phase commit. Mike Burrows, author of Google Chubby, said there is a consensus protocol, and that's Paxos "–all other approaches was just BR Oken versions of Paxos. Meaning that there is only one consistency algorithm in the world, that is Paxos, all other consistency algorithms are the incomplete version of the Paxos algorithm. The following article will describe this Paxos algorithm, which is generally considered to be difficult to understand but effective. References:

Two-phase commit protocol (2PC) and improved three-phase commit protocol (3PC) research on distributed transaction, two-phase commit, one-phase commit, best efforts 1PC mode and transaction compensation mechanism two-phase commit protocol and three-phase commit protocol

"Notice" copyright notice

(End of full text)

from:http://www.hollischuang.com/archives/681