Distributed transaction Seata

2PC Two phase submission agreement ：

The first stage ：

• 1. inquiry The coordinator sends transaction requests to all participants , Ask if transaction operations can be performed , Then wait for the response of each participant .
• 2. perform After each participant receives the coordinator transaction request , Perform transaction operations ( For example, updating records in a relational database table ), And will Undo and Redo Information is recorded in the transaction log .
• 3. Respond to If the participant successfully executes the transaction and writes Undo and Redo Information , Then return to the coordinator YES Respond to , Otherwise return to NO Respond to . Of course , Participants may also be down , So that no response is returned

The second stage ：

commit：

• 1. commit request The coordinator sends... To all participants Commit request .
• 2. Transaction submission Participants receive Commit After the request , Execute transaction commit , After the commit is completed, release all resources occupied during the transaction execution period .
• 3. Feedback results After the transaction is committed, the participant sends a message to the coordinator Ack Respond to .
• 4. Complete the business Received from all participants Ack After response , Complete transaction commit .

Interrupt the business ：

In execution Prepare During the steps , If some participants fail to execute the transaction 、 Downtime or network disruption with the coordinator , Then the coordinator cannot Received... From all participants YES Respond to , Or a participant returns No Respond to , here , The coordinator will enter the fallback process , Roll back the transaction .

• 1. rollback request The coordinator sends... To all participants Rollback request .
• 2. Transaction rollback Participants receive Rollback after , Use Prepare Stage Undo Log execution transaction rollback , Release transaction execution after completion All resources occupied during the period .
• 3. Feedback results The participant sends a message to the coordinator after executing transaction rollback Ack Respond to .
• 4. Interrupt the business Received from all participants Ack After response , Complete transaction interrupt .

2PC Potential problems with the two-stage submission agreement ：

• 1. Synchronous blocking Participants are waiting for instructions from the coordinator , It's actually waiting for the response of other participants , In the process , Participants cannot perform other operations , That is, it blocks its operation . If the network abnormality between the participant and the coordinator causes the participant to not receive the coordinator information all the time , Then it will cause the participants to block all the time .
• 2. Single point stay 2PC in , All requests come from the coordinator , So the status of coordinator is very important , If the coordinator goes down , This will keep the participants blocking and occupying transaction resources , If the coordinator is also distributed , Provide services by selecting the master , So after a coordinator hangs up , You can select another coordinator to continue the follow-up service , Can solve a single point problem . however , The new coordinator cannot know all the status information of the previous transaction ( For example, has been waiting Prepare Response time, etc ), Therefore, the last transaction cannot be handled smoothly .
• 3. Data inconsistency Commit In the course of a transaction Commit request /Rollback Requests may be lost due to coordinator downtime or network problems between coordinator and participant , Then, some participants did not receive Commit/Rollback request , While other participants received and executed normally Commit/Rollback operation , Participants who do not receive the request continue to block . At this time , The data between participants is no longer consistent . When participants perform Commit/Rollback After that, it will send... To the coordinator Ack, However, whether or not the coordinator receives from all participants Ack, There will be no other remedy for the matter , What the coordinator can do is to wait for the timeout and return a message to the transaction initiator “ I'm not sure if the transaction will succeed ”.
• 4. Environmental reliability depends on The coordinator Prepare After the request , Waiting response , However, if a participant goes down or the network with the coordinator is interrupted , Will result in the coordinator not receiving the response from all participants , So in 2PC in , The coordinator will wait for a certain time , Then after timeout , Will trigger a transaction interrupt , In the process , The coordinator and all other participants are out of blocking . This mechanism is too harsh for the real environment where network problems are common .

Seata Four models of

seata There are four main modes

• AT
• TCC
• Saga
• XA

Here we mainly introduce ATT as well as TCC

AT Pattern ：

AT Pattern is a non intrusive distributed transaction solution in AT In mode , Users only need to pay attention to their own “ Business SQL”, User “ Business SQL” As a stage ,Seata The framework will automatically generate two-phase commit and rollback operations for transactions .

Stage 1 ：

In one stage ,Seata Will intercept “ Business SQL”, First analysis SQL semantics , find “ Business SQL” Number of transactions to be updated

According to the , Before the business data is updated , Save it as “before image”, And then execute “ Business SQL” Update business data ,

After the business data update , Then save it as “after image”, Finally, a row lock is generated . All the above operations are in one database

Transaction completion , This ensures the atomicity of a phase operation .

The second stage ：

Submit ：

If the second stage is submitted , because “ Business SQL” In one stage it has been submitted to the database , therefore Seata The framework only needs to put a

Delete the snapshot data and row locks saved in the phase , Complete the data cleaning .

Roll back ：

If the second stage is rollback ,Seata It is necessary to roll back what has been executed in one stage “ Business SQL”, Restore business data . Rollback party The formula is to use “before image” Restore business data ; But before restoring, first check the dirty write , contrast “ The current business of the database data ” and “after image”, If the two data are identical, there is no dirty writing , Business data can be restored , If not one It means there is dirty writing , In case of dirty writing, it needs to be transferred to manual processing （ Reverse generation SQL It refers to the transformation into after analysis update Statement execution ）

AT One stage of the pattern 、 Both phase commit and rollback are performed by Seata The framework automatically generates , Users just need to write “ Business SQL”, Can then

Easy access to distributed transactions ,AT Pattern is a distributed transaction solution without any intrusion to the business .

TCC Pattern

characteristic ：

• 1. It's more invasive , And you have to implement the relevant transaction control logic
• 2. There is basically no lock in the whole process , Better performance

Implementation steps ：

TCC Patterns need to be implemented by users according to their own business scenarios Try、Confirm and Cancel Three actions ; The transaction initiator executes in one phase Try The way , Submit for implementation in phase II Confirm Method , Two phase rollback execution Cancel Method

TCC Three ways to describe ：

• Try： Detection and reservation of resources ;
• Confirm： The business operations performed are submitted ; requirement Try success Confirm Be sure to succeed ;
• Cancel： Reserve resource release ;

Seata The three characters of

stay Seata In the framework of , There are three characters ：

TC (Transaction Coordinator) - A business coordinator

Maintain the state of global and branch transactions , Drive global transaction commit or rollback .

TM (Transaction Manager) - Transaction manager

Define the scope of the global transaction ： Start global transaction 、 Commit or roll back global transactions .

RM (Resource Manager) - Explorer

Manage resources for branch transactions , And TC Talk to register branch transactions and report the status of branch transactions , And drive branch transaction commit or rollback .

among ,TC For separately deployed Server Server side ,TM and RM For embedded in the application Client client

Server End storage mode

• file：( Default ) standalone mode , Read and write global transaction session information in memory and persist local files root.data, Higher performance ( Default ）
• db：（5.7+） High availability mode , Global transaction session information through db share , The corresponding performance is worse
• redis：Seata-Server 1.3 And above support , Higher performance , There is a risk of loss of transaction information , Please configure the... Suitable for the current scene in advance redis Persistent configuration

To configure db：

• open config/file.conf
• modify mode="db"
• Modify database connection information （URL\USERNAME\PASSWORD)
• Create database seata_server
• new table ： You can go to seata Download from the resource information provided ：\script\server\db\mysql.sql

The code uses seata To manage distributed transactions, you only need to annotate the methods @GlobalTransactional