Distributed transaction solution

 We all know that traditional local affairs pass Spring Of @Transactional Can be realized 
 When we place an order   Change order status , Inventory deduction is written in one method , adopt @Transactional You can rollback or commit local transactions 

 But with the development of our business , Our meeting, library and table are separated ,  Now a complete database is split into multiple databases , An order payment operation is designed to 2 Operations   One is   Payment order   update  state  , One is to reduce inventory , Now operate in a method 2 Databases     This scenario   Use @Tr  Is it done 

 What should we do in such a scenario , This is just a distributed transaction across databases 
 Single system cross database   Transactions are also distributed transactions ,  Because it's time to use @Transactional  It can't help us solve cross database transactions , At this time, submit the agreement in two stages 

 The two-phase commit protocol has a role division   A transaction coordinator and participant will be abstracted ,
 Where is our cross database problem , Order payment we want to achieve results   That is, the order status is changed to paid , reduce stock , We hope this 2 Operations either succeed at the same time   Or fail at the same time , This is a whole business 

 If transactions are not used, the order status may be changed successfully , But inventory deduction failed 
 There are many reasons for the failure of inventory deduction   For example, inventory is not enough to reduce , The inventory is suspended , This will cause 2 Side transactions are inconsistent , Generally speaking, in case of transaction inconsistency, the first step is to change the status to payment succeeded   Second parts   Inventory reduction failed 

 We introduce a two-phase commit protocol to help us solve this cross database transaction  , We will first introduce the transaction manager （ Intermediate coordinator ）, Then the first step is that I finish sql  But I don't submit    I just told the intermediate coordinator about the result , After the intermediate coordinator receives it , If all this succeeds , The transaction manager normally notifies all libraries to commit transactions 
 In the first stage, there is a professional term called pre submission , you sql If you don't submit after execution, it is called pre submission , He didn't really land in the database , Just tell the Resource Coordinator the result of the execution , Lock resources 
 If the first stage 2 All stages are successful    The transaction manager notifies all databases   To commit a transaction 
 There is an error report in the first stage   The second stage is to do rollback operation    This is the bottom idea of two-stage submission  

 The transaction manager notifies each transaction in the second phase  commit/rollback, Can this happen 
 I succeeded in notifying the order warehouse 
 I failed to notify the inventory 
 I can't feel it either 100% To solve the problem of distributed transactions 
 Distributed transactions cannot 100% solve . During the second stage of notification, some nodes may fail to notify due to network reasons . Only try to improve the probability of success   This will trigger the retry mechanism , Or SMS notification 
 The corresponding operation and maintenance personnel shall be compensated 
 If you don't have to commit in two stages . The most likely situation is that you execute the order and change the status correctly 
 Inventory reduction failed during the second operation , Can our two-stage submission solve this problem 
 situation 
 Our two-phase commit protocol greatly improves the probability of transaction commit