Preface
from CPU To the memory 、 To disk 、 To the operating system 、 To the network , There are unreliable factors in computer system . Engineers and scientists try to use a variety of hardware and software methods to combat this unreliable factor , Ensure that data and instructions are processed correctly . In the field of network, there are TCP Reliable transport protocol 、 In the field of storage, there are Raid5 and Raid6 Algorithm 、 In the field of database, there is a basis for ARIES The transaction mechanism of algorithm theory ……
This article first introduces the transaction of stand-alone database ACID characteristic , Then it points out the difficulties of operating multiple data sources in distributed scenarios , This paper introduces the common distributed transaction solution in distributed system , These solutions ensure that business code operates on multiple data sources , Be able to operate like a single data source , Have ACID characteristic . At the end of this paper, the mature distributed transaction framework is given ——Seata Of AT Implementation of pattern global transaction .
One 、 Single data source transactions & Multi data source transaction
If an application only connects and queries through the connection driver and data source interface in a business flow （ The query here is generalized , Including adding, deleting, checking and modifying ） A specific database , The application can take advantage of the transaction mechanism provided by the database （ If the database supports transactions ） Ensure the reliability of the operation of the records in the library , Reliability here has four semantics ：
- Atomicity ,A
- Uniformity ,C
- Isolation, ,I
- persistence ,D
The author will not explain the four meanings here , Learn about single source transactions and their ACID Characteristics are the premise for readers to read this article . It is a complex and delicate process for a single database to realize its own transaction characteristics , for example MySQL Of InnoDB The engine goes through Undo Log + Redo Log + ARIES Algorithm to achieve . This is a big topic , Beyond the scope of this article , If you are interested, you can study it yourself .
A single data source transaction can also be called a stand-alone transaction , Or local affairs .
In a distributed scenario , A system consists of multiple subsystems , Each subsystem has its own data source . Multiple subsystems are used to compose more complex business through mutual adjustment . In the current popular microservice system architecture , Each subsystem is called a microservice , Again, each microservice maintains its own database , To remain independent .
for example , An e-commerce system may be provided by shopping micro service 、 Inventory microservices 、 Orders, microservices, etc . Shopping microservices integrate shopping business by calling inventory microservices and order microservices . When the user requests the shopping micro service provider to complete the order , On the one hand, shopping microservices call inventory microservices to deduct the inventory quantity of corresponding goods , On the other hand, call the order microservice to insert the order record （ For the convenience of describing distributed transaction solutions later , Here is the simplest e-commerce system microservice division and the simplest shopping business process , Subsequent payments 、 Logistics and other businesses are not under consideration ）. The e-commerce system model is shown in the figure below ：
In the business scenario of user shopping ,shopping-service Our business involves two databases ： Inventory （repo_db） And the order Library （repo_db）, That is to say g Shopping business is a combination of multiple data sources . As a consumer oriented system , E-commerce system should ensure the high reliability of shopping business , The reliability here is also ACID Four meanings .
However, the local transaction mechanism of a database only deals with the query operations on itself （ The query here is generalized , Including addition, deletion, modification and search ） Work , Cannot interfere with queries on other databases . therefore , The local transaction mechanism provided by the database itself can not ensure the reliability of global operation of multiple data sources .
Based on this , The distributed transaction mechanism for multi data source operation appears .
Distributed transactions can also be called global transactions .
Two 、 Common distributed transaction solutions
2.1 Distributed transaction model
Describe distributed transactions , The following nouns are often used ：
- Transaction participants ： For example, each database is a transaction participant
- A business coordinator ： Services that access multiple data sources , for example shopping-service It's the business coordinator
- Explorer （Resource Manager, RM）： Often synonymous with transaction participants
- Transaction manager （Transaction Manager, TM）： Usually synonymous with transaction coordinator
In the distributed transaction model , One TM Manage multiple RM, That is, a service program accesses multiple data sources ;TM Is a global transaction manager , Coordinate the progress of multiple local transactions , Make it commit or roll back together , Finally, a global ACID characteristic .
2.2 Second, the general problem and idempotency
The second general problem is a classic problem in the field of network , Used to express the subtlety and complexity of internet protocol design in computer networks . A simplified version of the two generals problem is given here ：
A White army was besieged in a valley , On the left and right sides of the valley are the Blues . There are more white troops trapped in the valley than any blue army on either side of the valley , And less than the sum of the two Blues . If a blue army attacks the White army alone , You will surely lose ; But if two Blues attack at the same time , You can win . The commander in chief of the two blues is on the left side of the valley , He wants the two blues to attack at the same time , This will send the order to the blue army on the right side of the valley , To tell you when to launch the attack . Suppose they could only send soldiers across the valley where the White army was （ The only communication channel ） To deliver the message , So when you cross the valley , Soldiers could be captured .
It's only when the messenger gets back and forth , The commander-in-chief can confirm the victory of this war （ Above figure ）. Now comes the question , The soldiers sent out to send the letter did not come back , Can the commander-in-chief of the left-wing Blues decide to launch the attack at the time agreed in the order ？
The answer is not sure , The soldiers sent out to send the letter did not come back , He could be in two situations ：
1） He was captured before the order was delivered （ Middle picture ）, At this time, the right-wing Blues don't know when to attack ;
2） The order is served , But I was captured on the way back （ Below ）, At this point the right side know when to attack , But the left side doesn't know if the right side knows when to attack .
Similar problems are common in computer networks , For example, the sender sends a message to the receiver HTTP request , perhaps MySQL Client to MySQL The server sends an insert statement , Then it timed out and didn't get a response . Does the server write successfully or failed ？ The answer is not sure , There are several situations ：
1） Maybe the request was not sent to the server at all due to a network failure , So the write failed ;
2） Maybe the server received , It's also written successfully , But before sending the response to the client, the server went down ;
3） Maybe the server received , It's also written successfully , Also sent a response to the client , But it didn't reach the client due to network failure .
Whatever the scene , It seems to the client that it is the same result ： Its request was not responded to . To ensure that the server writes data successfully , The client can only resend the request , Until you receive a response from the server .
A similar problem is called the network two generals problem .
The existence of the network two generals problem makes the sender of the message often send the message repeatedly , It is not considered successful until the recipient's confirmation is received , But this often leads to repeated sending of messages . For example, when the order module in the e-commerce system calls the payment module to deduct money , If the network failure leads to the second general's problem , The deduction request is sent repeatedly , The result of repeated deduction is obviously unacceptable . So make sure that the debit request in a transaction is sent no matter how many times , The receiver has and only performs one deduction , This guarantee mechanism is called idempotency of the receiver .
2.3 Two-phase commit （2PC） & Three stage commit （3PC） programme
2PC It is a simple model to implement distributed transaction , These two stages are ：
1） Preparation stage ： The transaction coordinator initiates a query request to each transaction participant ：“ I'm going to perform the global transaction , The resources involved in this transaction are distributed among your data sources , Namely ……, You have your own resources （ In other words, they execute local transactions to the stage to be committed ）”. Each participant coordinator replies yes（ I'm ready , Allow global transactions to be committed ） or no（ Indicates that the participant is unable to obtain the local resources required by the global transaction , Because it's locked by other local transactions ） Or timeout .
2） Submission phase ： If all the participants responded with yes, The coordinator initiates a transaction commit operation to all participants , Then all participants receive the local transaction commit operation and send it to the coordinator ACK; If any of the participants reply no Or a timeout , The coordinator initiates a transaction rollback operation to all participants , Then, after receiving, all participants perform the local transaction rollback operation and send it to the coordinator ACK.
2PC The process is shown in the figure below ：
As can be seen from the above figure , To achieve 2PC, All participants implement three interfaces ：
- Prepare()：TM Call this interface to ask if each local transaction is ready
- Commit()：TM Calling this interface requires each local transaction to commit
- Rollback()：TM Calling this interface requires each local transaction to be rolled back
These three interfaces can be simply （ But not exactly ） Comprehend XA agreement .XA Agreement is X/Open The proposed distributed transaction processing standard .MySQL、Oracle、DB2 These mainstream databases all implement XA agreement , So it can be used to implement 2PC Transaction model .
2PC Easy to understand , But there are the following problems ：
1） Poor performance , In the preparation stage , Wait for all the participants to return , To enter stage two , in the meantime , The relevant resources on each participant are locked in exclusive ways , Local transactions that participants intend to use these resources can only wait for . Because of this synchronous blocking problem , So it affects the local transaction concurrency of each participant ;
2） When the preparation phase is complete , If the coordinator goes down , None of the participants received a commit or rollback instruction , Lead to all participants “ At a loss ”;
3） In the submission phase , The coordinator sent a submit instruction to all participants , If a participant does not return ACK, So the coordinator doesn't know what's going on inside this participant （ Due to the existence of the network two generals problem , The participant may not have received the commit command at all , Has been in the state of waiting to receive the commit instruction ; It may also have received , And successfully executed the local commit , But returned ACK The network failure did not reach the coordinator ）, It is impossible to decide whether to roll back all participants in the next step .
2PC And then again 3PC, Turning a two-stage process into a three-stage process , Namely ： Inquiry stage 、 Preparation stage 、 Commit or rollback phase , No more details here .3PC Using the timeout mechanism to solve 2PC The problem of synchronization blocking , Avoid permanent locking of resources , Further enhance the reliability of the whole transaction process . however 3PC It's also impossible to deal with similar downtime issues , However, the probability of data inconsistency in multiple data sources is smaller .
2PC Except for performance and reliability problems , It's also very limited in its application scenarios , It requires participants to implement XA agreement , For example, we have realized XA The protocol's database as a participant can complete 2PC The process . But in multiple systems, services take advantage of api When interfaces call each other , They don't abide by XA It's agreed , Now 2PC It doesn't apply . therefore 2PC Rarely used in distributed application scenarios .
Therefore, the e-commerce scenario mentioned above cannot be used 2PC, because shopping-service adopt RPC Interface or Rest Interface call repo-service and order-service Indirect access to repo_db and order_db. Unless shopping-service Direct configuration repo_db and order_db As your own database .
2.4 TCC programme
describe TCC The e-commerce micro service model used in the scheme is shown in the figure below , In this model ,shopping-service It's the business coordinator ,repo-service and order-service It's a transaction participant .
Mentioned above ,2PC Participants are required to implement XA agreement , It is usually used to solve the transaction problem between multiple databases , More limited . Service utilization in multiple systems api When interfaces call each other , They don't abide by XA It's agreed , Now 2PC It doesn't apply . Modern enterprises adopt distributed microservices , Therefore, it is more important to solve the problem of distributed transactions among multiple microservices .
TCC It is a solution to the problem of distributed transactions among multiple microservices .TCC yes Try、Confirm、Cancel An abbreviation for three words , Its essence is an application level 2PC, There are also two stages ：
1） Stage 1 ： Preparation stage . The coordinator invokes all of the try Interface , Lock the resources involved in the whole global transaction , If the lock is successful try Interface returns to the coordinator yes.
2） Stage two ： Submission phase . If all the services try The interface returns in phase one yes, Then it enters the commit phase , The coordinator invokes the confirm Interface , Each service commits the transaction . If there is any service try The interface returns in phase one no Or a timeout , Then the coordinator calls the cancel Interface .
TCC The process is shown in the figure below ：
Here's a key question , since TCC It's a service level 2PC, How does it solve 2PC Can't deal with the downtime problem defects ？ The answer is to try again and again . because try The operation locks all the resources involved in the global transaction , It ensures that all preconditions of business operation are satisfied , So whether or not confirm Stage failure or cancel Phase failure can be achieved by repeatedly retrying until confirm or cancel success （ Success is that all services are right confirm perhaps cancel Back to ACK）.
Here's another key question , Trying again and again confirm and cancel In the process of （ Considering the existence of general problem of network two ） It may have been repeated confirm or cancel, So we have to make sure that confirm and cancel Operations are idempotent , That is, in the whole global transaction , Each participant did it only once confirm perhaps cancel. Realization confirm and cancel Idempotence of operation , There are many solutions , For example, each participant can maintain a de duplication table （ It can be implemented by using database table or memory type KV Component implementation ）, Record every global transaction （ Mark with global transaction XID distinguish ） Have you ever done confirm or cancel operation , If it has been done , It is no longer repeated .
TCC Put forward by the Alipay team , Is widely used in the financial system . When we buy funds with bank account balances , It will be noted that the balance in the bank account used to purchase the fund will be frozen in the first place , From this we can guess , This process is probably TCC The first stage of .
2.5 Transaction state table scheme
There's another one that's similar to TCC Transaction solutions for , With the help of transaction state table . Suppose you want to implement a call in a distributed transaction repo-service Deducting the inventory 、 call order-service There are two processes to generate an order . In this scheme , The coordinator shopping-service Maintain a transaction status table as follows ：
The initial state is 1, The status is updated every time a service is successfully called , Finally, all service calls succeed , Status update to 3.
With this watch , You can start a background task , Scan the status of transactions in this table , If a distributed transaction always （ Set a transaction cycle threshold ） Not in state 3, This indicates that the transaction was not successfully executed , So you can call again repo-service Deducting the inventory 、 call order-service Generate order . Until all calls succeed , Transaction status to 3.
If multiple retries still remain in the State 3, You can set the transaction state to error, Intervene by artificial intervention .
Due to the existence of service call retries , Therefore, the interface of each service should be based on the global distributed transaction ID Do idempotent , The principle is the same as 2.4 The realization of idempotency of a section .
2.7 The final consistent transaction scheme based on message middleware
Whether it's 2PC & 3PC still TCC、 Transaction status table , Basically abide by XA The idea of agreement , In other words, these schemes are essentially transaction coordinators to coordinate the progress of local transactions of each transaction participant , Make all local transactions commit or roll back together , Finally, a global ACID characteristic . In the process of coordination , The coordinator needs to collect the current state of each local transaction , According to these States, the next stage operation instructions are issued .
However, these global transaction schemes are cumbersome to operate 、 The time span is large , Or lock the related resources exclusively during the global transaction , The concurrency of global transactions in the whole distributed system will not be too high . This is difficult to meet the transaction throughput requirements of e-commerce and other high concurrency scenarios , So Internet service providers have explored a lot with XA Distributed transaction solutions that run counter to protocols . The final consistent global transaction implemented by message middleware is a classic scheme .
To show the essence of this scheme , I will use the following e-commerce system microservice architecture to describe it ：
In this model , Users are no longer requested to integrate shopping-service Place an order , It's a direct request order-service Place an order ,order-service On the one hand, add order records , On the other hand, it calls repo-service Deducting the inventory .
This kind of final consistent transaction scheme based on message oriented middleware is often misunderstood as the following implementation mode ：
The process of this implementation is ：
1）order-service Responsible for providing MQ server Send stock deduction message （repo_deduction_msg）;repo-service subscribe MQ server Reduced inventory message in , Responsible for consumer information .
2） After the user orders ,order-service First execute the query statement to insert the order record , After the repo_deduction_msg Send to message middleware , These two processes are carried out in a local transaction , once “ Execute the query statement that inserts the order record ” Failure , Cause transaction rollback ,“ take repo_deduction_msg Send to message middleware ” It won't happen ; Again , once “ take repo_deduction_msg Send to message middleware ” Failure , Throw an exception , It can also lead to “ Execute the query statement that inserts the order record ” Operation rollback , In the end, nothing happened .
3）repo-service Received repo_deduction_msg after , Execute inventory deduction query statement first , Back MQ sever Feedback message consumption completed ACK, These two processes are carried out in a local transaction , once “ Execute inventory deduction query statement ” Failure , Cause transaction rollback ,“ towards MQ sever Feedback message consumption completed ACK” It won't happen ,MQ server stay Confirm Driven by the mechanism, it will continue to repo-service Push the message , Until the entire transaction is successfully committed ; Again , once “ towards MQ sever Feedback message consumption completed ACK” Failure , Throw an exception , It also leads to “ Execute inventory deduction query statement ” Operation rollback ,MQ server stay Confirm Driven by the mechanism, it will continue to repo-service Push the message , Until the entire transaction is successfully committed .
This seems to be a reliable approach . But did not take into account the existence of the network two generals problem , It has the following defects ：
1） There is a network of 2 General question , The above first 2） In step order-service send out repo_deduction_msg The news failed , For the sender order-service Come on , Maybe the message middleware didn't receive the message ; It may also be that the middleware has received the message , But to the sender order-service Responsive ACK Due to network failure, it was not order-service received . therefore order-service Hasty transaction rollback , revoke “ Execute the query statement that inserts the order record ”, It is not right , because repo-service It may have been received over there repo_deduction_msg And the inventory deduction is successful , such order-service and repo-service There is a data inconsistency between the two sides .
2）repo-service and order-service Call the network （ And MQ server signal communication ） Put it in a local database transaction , Long database transactions may occur due to network latency , Affect the concurrency of local transactions in the database .
The above is a misunderstood way to achieve , Here's how to do it , As shown below ：
The scheme shown above , Using message middleware such as rabbitMQ To achieve the final consistency of distributed order and inventory deduction process . Let's illustrate the picture below ：
1）order-service in ,
stay t_order Table add order record &&
stay t_local_msg Add the corresponding deduction stock message These two processes need to be completed in one transaction , Guarantee the atomicity of the process . Again ,repo-service in ,
Check whether the inventory deduction operation has been performed &&
Perform inventory deduction if this deduction has not been performed &&
Write a duplicate list &&
towards MQ sever Feedback message consumption completed ACKThese four processes should also be completed in one transaction , Guarantee the atomicity of the process .
2）order-service There's a background program in , The message in the message table is continuously transmitted to the message middleware , After success, delete the corresponding message in the message table . If it fails , And try to retransmit . Because of the network 2 General question , When order-service Message network timeout sent to message middleware , At this time, the message middleware may receive the message but respond ACK Failure , Maybe I didn't get it ,order-service The message will be sent again , Until the message middleware responds ACK success , This may cause repeated messages to be sent , But that's okay , As long as the message is not lost , Just keep in order , Back repo-service Will do reprocessing .
3） Message oriented middleware to repo-service push repo_deduction_msg,repo-service After successful processing, it will respond to the middleware ACK, Message middleware receives this ACK Just think repo-service Successfully processed the message , Otherwise, the message will be pushed repeatedly . But there are situations like this ：repo-service Successfully processed the message , Sent to middleware ACK Lost in network transmission due to network failure , As a result, middleware did not receive ACK Re pushed the message . It also depends on repo-service To avoid repeated message consumption .
4） stay 2） and 3） There are two causes of repo-service The reason for receiving the message repeatedly , First, producers produce repeatedly , Second, middleware retransmission . In order to realize the idempotency of business ,repo-service A duplicate table is maintained in , This table records the message that has been successfully processed id.repo-service Every time a new message is received, it is judged whether the message has been successfully processed , If so, don't repeat it .
Through this design , The message is not lost in the sender , Messages are not consumed repeatedly by the receiver , Together, the news is not missing or heavy , Strictly achieved order-service and repo-service The final consistency of the data in the two databases of .
The final consistent global transaction scheme based on message middleware is an innovative application mode explored by Internet companies in high concurrency scenarios , utilize MQ Realize asynchronous call between microservices 、 Decoupling and peak shaving , Support high concurrency of global transactions , And ensure the final consistency of distributed data records .
3、 ... and 、Seata in AT mode The implementation of the
The first 2 In this chapter, we give the common theory model of realizing distributed transaction . This chapter presents the industry open source distributed transaction framework Seata The implementation of the .
Seata It provides users with AT、TCC、SAGA and XA Transaction mode . among AT The pattern is Seata The main transaction mode , Therefore, this chapter analyzes Seata in AT mode The implementation of the . Use AT There is a premise , That is, the database used by microservices must be a transactional relational database .
3.1 Seata in AT mode Workflow Overview
Seata Of AT The schema is based on the local transaction characteristics of relational databases , Through the data source proxy class intercepts and parses the database execution SQL, Log custom rollback logs , To roll back , Replay these custom rollback logs .AT The pattern is based on XA Transaction model （2PC） Evolved from , however AT To break the XA The blocking constraints of the protocol , Balance between consistency and performance .
AT The pattern is based on XA The transaction model evolved from , Its overall mechanism is also an improved version of the two-phase commit protocol .AT The two basic stages of the model are ：
1） The first stage ： First get the local lock , Performing local transactions , Business data operations and logging rollback logs are committed in the same local transaction , Finally release the local lock ;
2） The second stage ： To submit globally , Delete the rollback log asynchronously , This process will soon be completed . If you need to roll back , The first phase of the rollback log is used for reverse compensation .
This chapter describes Seata in AT mode The working principle of e-commerce micro service model is shown in the figure below ：
In the diagram above , The coordinator shopping-service Call participants first repo-service Deducting the inventory , Then the participant is called order-service Generate order . This stream uses Seata in XA mode The global transaction flow after that is shown in the following figure ：
The global transaction execution process described in the above figure is ：
1）shopping-service towards Seata Register global transactions , And generate a global transaction identifier XID
2） take repo-service.repo_db、order-service.order_db The local transaction for is executed to the pending commit phase , The content of the transaction contains the right to repo-service.repo_db、order-service.order_db Query operations and write to each library undo_log Record
3）repo-service.repo_db、order-service.order_db towards Seata Register branch transactions , And include it in the XID Corresponding global transaction scope
4） Submit repo-service.repo_db、order-service.order_db The local affairs of
5）repo-service.repo_db、order-service.order_db towards Seata Reports the commit status of branch transactions
6）Seata Sum up all the DB The commit status of the branch transaction of , Decide whether the global transaction should be committed or rolled back
7）Seata notice repo-service.repo_db、order-service.order_db Submit / Rollback local transaction , If you need to roll back , It's a compensatory approach
among 1）2）3）4）5） It belongs to the first stage ,6）7） It belongs to the second stage .
3.1Seata in AT mode Workflow details
In the above e-commerce business scenario , Shopping service calls inventory service to deduct inventory , Call the order service to create an order , Obviously, these two calling procedures should be placed in one transaction . namely ：
start global_trx
call Inventory service deduction inventory interface
call Order service creation order interface
commit global_trxIn the inventory service database , There are the following inventory tables t_repo：
In the order service database , There are the following order forms t_order：
Now? ,id by 40002 The user wants to buy a commodity code for 20002 The mouse , The content of the whole distributed transaction is ：
1） The inventory table of the inventory service will record
It is amended as follows
2） Add a record to the order table of the order service
The above operation , stay AT The flow chart of the first phase of the pattern is as follows ：
from AT The process of the first stage of the model is , The local transaction of the branch is completed after the first phase commit , Local records locked by local transactions will be released . This is a AT Patterns and XA The biggest difference , stay XA Two phase commit of transaction , Locked records are not released until the end of the second phase . therefore AT The mode reduces the lock record time , Thus, the efficiency of distributed transaction processing is improved .AT The reason why the pattern is able to release the locked records after the first phase is completed , Because Seata In the database of each service, one is maintained undo_log surface , It's written about t_order / t_repo Mirror data recorded before and after operation , Even if the second phase is abnormal , Just play back the undo_log Global rollback can be realized by corresponding records in .
undo_log The table structure ：
After the first phase ,Seata The commit status of all branch transactions will be received , Then decide whether to commit the global transaction or roll back the global transaction .
1） If all branch transactions are successfully committed locally , be Seata Decide to commit globally .Seata Send the message submitted by the branch to each branch transaction , After each branch transaction receives the branch commit message , The message is put into a buffered queue , Then go straight to Seata Return submitted successfully . after , Each local transaction will slowly process the branch commit message , The way to deal with it is ： Delete... Of the corresponding branch transaction undo_log Record . The reason is that you only need to delete the branch transaction undo_log Record , There is no need to do other commit operations , Because the commit operation has been completed in the first phase （ This is also AT and XA Different places ）. This process is shown in the figure below ：
The reason why branch transactions can directly return success to Seata, Because the really critical commit operation has been completed in the first phase , eliminate undo_log The journal is just a finishing line , Even if the purge fails , It also has no substantial impact on the whole distributed transaction .
2） If any branch transaction local commit fails , be Seata Decide to roll back globally , Send the branch transaction rollback message to each branch transaction , Since the database of each service in the first phase recorded undo_log Record , The branch transaction rollback operation only needs to be based on undo_log Record and compensate . The global transaction rollback process is shown in the following figure ：
Here's the picture of 2、3 Step for further explanation ：
1） As given above undo_log The table structure , So you can go through xid and branch_id To find all the undo_log Record ;
2） Get the current branch transaction undo_log After recording , The first thing to do is to verify the data , If afterImage The record in is inconsistent with the current table record , Explain the period from the completion of the first stage to the present moment , There are other transactions that have modified these records , This causes the branch transaction not to be rolled back , towards Seata Feedback rollback failed ; If afterImage The record in is consistent with the current table record , Explain the period from the completion of the first stage to the present moment , No other transaction modifies these records , Branch transactions can be rolled back , And then according to beforeImage and afterImage Calculate the compensation SQL, Execution compensation SQL Roll back , Then delete the corresponding undo_log, towards Seata Feedback rollback successful .
The transaction is ACID characteristic , Global transaction solutions are also trying to implement these four features . The above is about Seata in AT mode It is obvious that AT The atomicity of 、 Consistency and persistence . Let's focus on AT How to ensure the isolation of multiple global transactions .
stay AT in , When multiple global transactions operate on the same table , To ensure transaction isolation through global lock . The following describes how global locks work in both read isolation and write isolation scenarios ：
1） Write isolation （ If there is a global transaction changing / Write / Delete the record , Another global transaction changes the same record / Write / The deletion should be isolated , That is, writing is mutually exclusive ）： Write isolation is used when multiple global transactions update the same field in the same table , To avoid the data involved in a global transaction being modified by other global transactions before it is successfully committed . The basic principle of write isolation is ： In the first stage, local affairs （ When opening local affairs , Local transactions will lock the records involved locally ） Before submitting , Make sure you get the global lock . If you can't get the global lock , You can't commit local transactions , And keep trying to get global locks , Until the number of retries is exceeded , Give up global lock , Rollback local transaction , Release the local lock imposed by the local transaction on the record .
Suppose there are two global transactions gtrx_1 and gtrx_2 In concurrent operation of inventory service , Intention to deduct the inventory quantity recorded below ：
AT The sequence diagram for the write isolation process is as follows ：
In the figure ,1、2、3、4 It belongs to the first stage ,5 It belongs to the second stage .
In the diagram above gtrx_1 and gtrx_2 All submitted successfully , If gtrx_1 Perform the rollback operation in the second phase , that gtrx_1 Need to re initiate local transaction to obtain local lock , And then according to undo_log For this id=10002 The records are rolled back competitively . here gtrx_2 Still waiting for global lock , And hold this id=10002 Local lock for records of , therefore gtrx_1 Will fail to roll back （gtrx_1 Rollback requires holding both global locks and pairs of id=10002 Local lock on records of ）, Rollback failed gtrx_1 Will always try to roll back . To the next one gtrx_2 The number of attempts to acquire a global lock exceeded the threshold ,gtrx_2 Will give up getting the global lock , Initiate local rollback , After the local rollback ends , It's natural to let go of this id=10002 Local lock on records of . here ,gtrx_1 Finally, we can succeed in this id=10002 A local lock has been added to the record , And I got both local and global locks gtrx_1 You can successfully roll back . The whole process , The global lock is always in gtrx_1 In the hands of , There's no dirty writing problem . The flow chart of the whole process is shown below ：
2） Reading isolation （ If there is a global transaction changing / Write / Delete the record , Another global transaction's reading of the same record should be isolated , Reading and writing are mutually exclusive ）： At the isolation level of database local transactions, read committed 、 Repeatable 、 When serializing （ Read uncommitted doesn't work as a quarantine , Generally not used ）,Seata AT The isolation level generated by the global transaction model is read uncommitted , That is to say, a global transaction will see the data not globally committed by another global transaction , Produce dirty reading , This can also be seen from the flow charts of the first and second stages . This is acceptable in a ultimately consistent distributed transaction model .
If required AT The model must implement read committed transaction isolation level , You can use Seata Of SelectForUpdateExecutor The actuator is right SELECT FOR UPDATE Statement to proxy .SELECT FOR UPDATE Statement will apply for a global lock when it is executed , If the global lock is already held by another global transaction , Then roll back SELECT FOR UPDATE Execution of statements , Release local lock , And try again SELECT FOR UPDATE sentence . In the process , Query requests will be blocked , Until you get the global lock （ In other words, the record to be read is committed by other global transactions ）, Read the data that has been committed by the global transaction before returning . This process is shown in the figure below ：
Four 、 Conclusion
XA Agreement is X/Open The proposed distributed transaction processing standard . Mentioned in the article 2PC、3PC、TCC、 Local transaction table 、Seata in AT mode, Either way , The essence is that the transaction coordinator coordinates the progress of the local transaction of each transaction participant , To cause all local transactions to commit or roll back together , Finally, a global ACID characteristic . In the process of coordination , The coordinator needs to collect the current state of each local transaction , According to these States, the next stage operation instructions are issued . The idea is XA The essence of the agreement , We can say that these transaction models comply with or generally comply with XA agreement .
The final consistent transaction scheme based on message middleware is an innovative application mode explored by Internet companies in high concurrency scenarios , utilize MQ Realize asynchronous call between microservices 、 Decoupling and peak shaving , Ensure the final consistency of distributed data records . It clearly does not comply XA agreement .
For a technology , There may be industry standards or protocols , However, practitioners need specific application scenarios or for convenience , The implementation of the standard is not completely consistent with the standard , Even completely inconsistent implementations , This is a common phenomenon in engineering .TCC This is the plan 、 The final consistent transaction scheme based on message middleware is as follows 、Seata in AT mode The pattern is the same . And new standards often emerge from these innovations .
Don't you really find out 2.6 section （ The final consistent transaction scheme based on message middleware ） Is there a business vulnerability in the right solution given ？ Please take a look at this picture again , Take a careful look at the calling directions of two microservices , Leave your thoughts in the comments section :-)
At the end
Welcome to my official account 【 Calm as a code 】, Massive Java Related articles , Learning materials will be updated in it , The sorted data will also be put in it .
Like what you write , Just pay attention ！ Focus , Neverlost , Continuous updating ！！！
