Distributed transaction

Distributed transactions - Theory Chapter

What is a distributed transaction

Distributed transaction means that the operation of transaction is located on different nodes , Therefore, remote cooperation between services is needed to complete transaction operations , In this kind of distributed system environment, different services cooperate with each other remotely through the network to complete the transaction, which is called distributed transaction , It mainly refers to multiple cross service transactions contained in a transaction webservice.

Distributed transaction theory -CAP&BASE

CAP

• Consistency（ Uniformity ）： Users access any node in the distributed system , The data obtained must be consistent .
• Availability（ Usability ）： The user accesses any healthy node in the cluster , Must be able to get a response , Instead of timeout or rejection , Even if there are unhealthy nodes , Other healthy nodes should also respond .
• Partition tolerance （ Partition tolerance ）： Some nodes in the distributed system lose connection with other nodes due to network failure or other reasons , Form a separate partition , When partitions appear in the cluster , The whole system should also continue to provide external services .

BASE

BASE It can be said to be a kind of neutralization and softening of usability and strong consistency .

• Basically Available （ Basic available ）： When a distributed system fails , Partial loss of availability is allowed , That is to ensure that the core is available .
• Soft State（ Soft state ）： In a certain amount of time , An intermediate state... Is allowed , Such as temporary inconsistency .
• Eventually Consistent（ Final consistency ）： Although strong consistency cannot be guaranteed , But at the end of the soft state , Finally, the data is consistent .

Distributed transaction processing scheme

XA The protocol consists of a two-phase commit （2PC）

The first stage

stay XA The first phase of distributed transactions , The node that acts as the transaction coordinator will first send Prepare request .

After receiving Prepare After the request , Each participant node will update the data related to the transaction , write in Undo Log and Redo Log. If the participant performs successfully , Do not commit the transaction for the time being , Instead, it returns... To the transaction coordination node “ complete ” news .

When the transaction coordinator receives a return message from all participants , The whole distributed transaction will enter the second phase .

The second stage

stay XA The second phase of distributed transactions , If the transaction coordination node has received all the data before, it will return in a positive direction , Then it will issue... To all transaction participants Commit request .

Receive Commit After the request , The transaction participant nodes will commit their own local transactions , And release the lock resource . When the local transaction is committed , Will return to the transaction coordinator “ complete ” news .

When the transaction coordinator receives the “ complete ” feedback , The whole distributed transaction is completed .

Add   Three stage commit （3PC） Two implementations ： In the first step, one more CanCommit Stage , First, ask whether there are conditions for submission , The two-step submission step above will be performed only after the confirmation is returned , Added a timeout , If some participants are commit I haven't received any from the coordinator for a certain period of time commit, Automatic local submission .

Inferiority

1. A single point of failure ： The transaction coordinator is the whole XA The core of the model , Once the transaction coordinator node fails , Participants cannot receive commit or rollback notification , Participants will never be able to complete the transaction .
2. Inconsistencies caused by missing messages ： Second stage , If there is a local network problem , Some transaction participants received a commit message , Another part of the transaction participants did not receive the commit message , This leads to data inconsistency between nodes . 3pc That solved the problem
3. Performance issues ： If multiple participants , Partially completed , Partially incomplete , Do not submit until the unfinished work is completed , So the performance has a certain impact .

Seata A two-step solution to

TCC Solution

1. Try： Try Phases are generally used to lock a resource , Set a ready state or freeze some data .

2. Confirm： according to Try Implementation of phase ,Confirm There are two cases ： Ideally , all Try All executed successfully , Execute the... Of each service Confirm Logic ; If confirm Execution failure , retry , Artificial intervention , By default, the execution must be successful . Some services Try Execution failure , Then execute the third stage ——Cancel.

3. Cancel If Try Stage execution exception , Will execute Cancel Stage , The execution of this stage is to put try The locked resources of the phase are released . The default is successful execution , Unsuccessful manual intervention .

MQ Message queuing ensures final consistency

Recommended articles

Interview questions ：Redis Why single thread ？ After watching this video, I got a thorough understanding

interviewer ： Let's talk about congestion control

interviewer ： Have you known about seckill system solutions

interviewer :JMM Let's talk about ？

interviewer ： Young man , Distributed database ID Solutions understand ？