Concepts and theories related to distributed transactions

1 Basic concepts

1.1 What is business

What is business ？ Let me give you an example from life ： You go to the grocery store to buy ,“ Hand in hand , Delivery on one hand ” It's an example of a transaction , Payment and delivery must all be successful , Business is a success , Any activity fails , Transaction will undo all successful activities .
Understand examples , Let's look at the definition of business ：
Business can be seen as a big activity , It has different small activities , These activities are either all successful , All or nothing .

1.2 Local transactions

In computer system , It's more about controlling transactions through relational databases , This is achieved by using the characteristics of the database itself , So it's called database transaction , Because applications mainly rely on relational databases to control transactions , The database is usually on the same server as the application , Therefore, transactions based on relational databases are also called local transactions .
Review the four features of database transactions ：ACID.

A（Atomic）： Atomicity

All operations that make up a transaction , Or it's all done , Or none at all , Partial success and partial failure are not possible .

C（Consistency）： Uniformity

Before and after transaction execution , The consistency constraint of the database is not broken . such as ： Zhang San turns to Li Si 100 element , The data before and after the transfer is in the correct state, which is called consistency , If Zhang San turns out 100 element , Li Si's account number has not been increased 100 This leads to a data error , There is no consistency .

I（Isolation）： Isolation,

Transactions in a database are usually concurrent , Isolation means that the execution of two concurrent transactions does not interfere with each other , One transaction cannot see the intermediate state of other transaction running processes . Dirty reads can be avoided by configuring the transaction isolation level 、 Repeat reading and so on .

D（Durability）： persistence

After the transaction completes , Changes to data from this transaction are persisted to the database , And will not be rolled back .
When database transaction is implemented, all operations involved in a transaction will be incorporated into an indivisible execution unit , All operations in the execution unit are either successful , Or they all failed , As long as any of these operations fail , Will cause the entire transaction to roll back .

Distributed transactions

With the rapid development of Internet , Software system from the original single application to distributed application , The following figure describes the evolution of monomer applications to microservices ：

The distributed system will split an application system into multiple services that can be deployed independently , 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 , For example, users register to send points transaction 、 Create order inventory reduction transaction , Bank transfer transactions are distributed transactions .

We know that local transactions rely on the transaction features provided by the database itself to implement , So the following logic can control local transactions ：

begin transaction;
  //1.  Local database operations ： Zhang San reduces the amount 
  //2.  Local database operations ： Li Si increases the amount 
commit transaction;

But in a distributed environment , It's going to be like this ：

begin transaction;
  // 1. Local database operations ： Zhang San reduces the amount 
  // 2. The remote invocation ： Let Li Si increase the amount 
commit transaction;

You can imagine , When the remote call made Li Si increase the amount, it succeeded , The remote call did not return... Due to network problems , At this time, if the local transaction fails to commit, Zhang San's operation of reducing the amount is rolled back , At this time, the data of Zhang San and Li Si are inconsistent .
So on the basis of distributed architecture , Traditional database transactions cannot be used , The accounts of Zhang San and Li Si are not in the same database or even in the same application system , To implement the transfer transaction, you need to call , Due to network problems, it is good to cause distributed transaction problems .

1.4 Distributed transaction generation scenario

1、 The typical scenario is microservice architecture , The microservices complete the transaction operation through remote call . such as ： Order and inventory microservices , While placing an order, the order micro service requests the inventory micro service to reduce inventory . In short ： Span JVM Process generates distributed transaction .

2、 A single system accesses multiple database instances , When a single system needs to access multiple databases （ example ） Distributed transactions are generated . such as ： User information and order information are respectively in two MySQL Instance store , User management system delete user information , You need to delete user information and user order information respectively , Because the data is distributed in different data instances , Need to operate data through different database links , A distributed transaction is generated . in short ： Generate distributed transactions across database instances .

3、 Example of multiple services accessing the same database , such as ： Order and inventory microservices generate distributed transactions even if they access the same database , The reason is cross JVM process , The two micro services hold different Database link for database operation , A distributed transaction is generated .

All in all , A distributed transaction can be split into multiple local transactions , No matter whether the local transaction operates a database instance , Only different local transactions form a large logical transaction , This logical transaction is a distributed transaction .

2 Basic theory of distributed transaction

Through the previous study , We understand the basic concepts of distributed transactions . Unlike local transactions , Distributed system is called distributed system , It's because the nodes that provide services are distributed on different machines , Interact with each other through the Internet . The whole system can't provide services because of a little network problem , The network factor has become one of the criteria for distributed transactions . therefore , Distributed transactions need further theoretical support , Next , Let's first learn about distributed transactions CAP theory .
Before explaining the distributed transaction control solution, you need to learn some basic theories , Through theoretical knowledge, we can determine the goal of distributed transaction control , To help us understand each solution .

2.1 CAP theory

2.1.1 understand CAP

CAP yes Consistency、Availability、Partition tolerance An abbreviation for three words , They mean consistency 、 Usability 、 Zone tolerance .
Let's explain separately ：
For the convenience of CAP Theoretical understanding , We understand the business scenarios in e-commerce system CAP.
Here's the picture , Is the implementation process of commodity information management .

The overall implementation process is as follows ：

1. Commodity service requests the master database to write commodity information （ Add the goods 、 Modify the goods 、 Delete item ）.
2. The main database successfully writes the response of goods and services .
3. Commodity service requests to read commodity information from the database .

C-Consitency

Consistency means that the read operation after the write operation can read the latest data status , When The database is distributed on multiple nodes , The data read from any node is the latest state .
Above picture , To achieve consistency in reading and writing commodity information is to achieve the following goals ：

• Goods and services are successfully written into the master database , Then query the new data from the database successfully .
• Commodity service failed to write to master database , It also fails to query the new data from the database .
  How to achieve consistency ？
• Write into the master database to synchronize the data to the slave database .
• After writing into the main database , Lock the slave database during synchronization to the slave database , Release the lock after synchronization . So as not to write the new database successfully , Query old data from database .

Characteristics of distributed system consistency

• Because of the process of data synchronization , There will be a certain delay in the response of the write operation .
• In order to ensure data consistency, resources will be temporarily locked , Wait for data synchronization to finish releasing locked resources .
• An error message is returned if the node that failed to request data synchronization , Never return old data .

A-Availability

Availability means that any transaction operation can get response results , And there will be no response timeout or response error .
Above picture , Product information reading to meet the availability is to achieve the following goals ：

• Data query requests received from the database can immediately respond to the data query results .
• Response timeout or response error is not allowed from database .
  How to achieve usability
• Write into the master database to synchronize the data to the slave database .
• Because to ensure the availability of the slave database , You cannot lock resources from the database .
• Even if the data hasn't been synced , Return the data to be queried from the database , Even old data , If you don't have any old data, you can return a default message by convention , But can't return an error or response timeout .
  Features of distributed system availability
• All requests are answered , And there will be no response timeout or response error .

P-Partition tolerance

Usually each node of the distributed system is deployed in different subnets , This is the Internet Partition , Inevitably, the communication between nodes will fail due to network problems , At this time, we can still provide external services , It's called zone tolerance .
Above picture , Reading and writing commodity information to meet the tolerance of zoning is to achieve the following goals ：

• Failure to synchronize data from master data to slave database does not affect read and write operations .
• If one node is hung up, it will not affect the service provided by the other node .
  How to achieve partition tolerance
• Try to use asynchronous instead of synchronous operation , For example, use asynchronous method to synchronize data from database to slave database , In this way, loose coupling between nodes can be realized effectively .
• Add from database node , One of the nodes hangs up and the other slave nodes provide services .
  Characteristics of distributed partition tolerance
• Partition tolerance is the basic ability of distributed system .

CAP combination

• Whether there are examples of commodity management at work CAP Well ？
  In the scenario of indexed distributed transactions, there will not be CAP Three characteristics , Because I have P Under the premise of C and A Can't coexist .
  For example, the following figure satisfies P That means partition tolerance is achieved ：
  
  The meaning of partition tolerance in this figure is ：
• The master database synchronizes data to the slave database through the network , It can be considered that the primary database is deployed in different partitions , Interact through the network .
• When there is a problem in the network between the master database and the slave database, it will not affect the service provided by the master database and the slave database .
• When one node is down, it does not affect the other node to provide services .
  If we want to achieve C Data consistency must be ensured , In order to prevent inconsistent data from being queried from the slave database during database synchronization, the slave database needs to be locked , Unlock after synchronization , If the synchronization fails, an error message or timeout message should be returned from the database .

If we want to achieve A Data availability must be guaranteed , You can query data from the database at any time , Will not respond to timeout or return error messages .
Through the analysis, we found that in the satisfaction of P Under the premise of C and A There are contradictions .

CAP What are the combinations

Therefore, in the production of distributed processing, we should determine the satisfaction according to the needs CAP Those two aspects of .

• AP
  Give up consistency , The pursuit of partition tolerance and usability , This is the choice of many distributed system designs .
  for example ：
  Commodity management above , It can be realized AP, The premise is that as long as the user can accept that the queried data is not the latest within a certain period of time .
  Usually achieve AP Will guarantee final consistency , The following will be BASE Theory is the basis AP To expand , Some business scenarios , such as ： Order refund , Today's refund is successful , Tomorrow account arrival , As long as the user can accept the payment within a certain period of time .
• CP
  Discard availability , Pursue consistency and partition fault tolerance , our zookeeper In fact, the pursuit of strong consistency , Another example is inter-bank transfer , An inter-bank transfer request is not completed until the entire transaction is completed by both banking systems .
• CA
  Give up partition fault tolerance , That is to say, there is no partition , Do not consider the problem of network impassability or node hang up , You can achieve consistency and availability . Then the system will not be a standard distributed information , Our most commonly used relational databases meet CA.
  Commodity management above , If we want to achieve CA The structure is as follows ：
  
  There is no data synchronization between master database and slave data , The database can respond to every query request , Each query request can return the latest data through the transaction isolation level .

summary

Through the above we have learned CAP Knowledge of theory ,CAP It's a proven theory ： A distributed system can only satisfy the consistency at most 、 Availability and partition tolerance are two of the three . It can be used as our architecture design 、 Consideration criteria for technology selection . For most large Internet application scenarios , There are many nodes 、 Deployment is decentralized , And now the scale of the cluster is growing , So node failure 、 Network failure is the norm , And make sure the service availability reaches N individual 9（99.999…%）, And to achieve good response performance to improve the user experience , Therefore, the following choices are generally made ： Guarantee P and A, Abandon C Strong consistency , Ensure ultimate consistency .

BASE theory

Understand strong consistency and final consistency

CAP Theory tells us that a distributed system can only meet consistency at most 、 Availability and partition tolerance are two of the three , among AP More in practical application ,AP Abandon consistency , Ensure availability and partition tolerance , But in actual production, many scenarios need to achieve consistency , For example, in the previous example, the master data synchronizes data from the slave database , Even if there is no consistency , But in the end, we also need to synchronize data successfully to ensure data consistency , This consistency and CAP The consistency is different ,CAP The consistency of requires that the data of each node must be consistent at any time , It emphasizes strong consistency , But the ultimate consistency is to allow the data of each node to be inconsistent over a period of time , But after a period of time, the data of each node must be consistent , It emphasizes the consistency of the final data .

Base The theory is introduced

BASE yes Basically Availiable（ Basically ）、Soft state（ Soft state ） and Eventually consistent( Final consistency ） Abbreviations of three short messages .BASE The theory is right CAP An extension of , Availability achieved by sacrificing strong consistency , In case of failure, it is allowed that some parts are not available but the core functions shall be available , Allow data to be inconsistent over time , But in the end it's consistent . Satisfy BASE Theoretical business , We call it “ Flexible business ”.

• Basic available ： When the distributed system fails , Allow the loss of some available functions , Make sure the core functions are available . Such as , There is something wrong with the payment of e-commerce website transactions , Products can still be viewed normally .
• Soft state ： Because don't ask for strong consistency , therefore BASE Allow intermediate states in the system （ It's also called soft state ）, This state does not affect system availability , As of the order “ In the payment ”、“ Data synchronization ” Equal state , After the data is finally consistent, the status changes to “ success ” state .
• Final agreement ： Final agreement means after a period of time , All node data will be consistent . As of the order “ In the payment ” state , In the end, it will become “ Successful payment ” perhaps “ Failure to pay ”, Agree the order status with the actual transaction result , But it takes a certain delay 、 wait for .

3 Distributed transaction solution 2PC（ Two-phase commit ）

I've learned the basic theory of distributed transaction , Based on Theory , Common solutions for different distributed scenarios in the industry are 2PC、TCC、 The final consistency of reliable information 、 Try your best to inform several .

3.1 What is? 2PC

2PC I.e. two phase submission agreement , The whole transaction process is divided into two stages , Preparation stage （Prepare phase）、 Submission phase （Commit phase）,2 It means two stages ,P It means the preparation stage ,C It's the submission phase .
give an example ： Zhang San and Li Si haven't seen each other for a long time , Old friends have a dinner party , The boss of the restaurant asked to pay first , To issue tickets . At this time, Zhang San and Li Si respectively complained about the current situation , There's shyness in the bag , Don't want to treat , Then only AA. Only Zhang San and Li Si paid , Only the boss can arrange the meal . But because Zhang San and Li Si are iron roosters , It was an embarrassing scene ：

• Preparation stage ： The boss asked Zhang San to pay , Zhang San pays . The boss asked Li Si to pay , Li Si paid .
• Submission phase ： The boss issues tickets , The two of them took their seats for dinner .
  A transaction is formed in the example , If one of Zhang San or Li Si refuses to pay , Or there is not enough money , The shop owner will not issue tickets , And will return the collected money to .
  The whole transaction process is composed of transaction manager and participants , The shopkeeper is the thing manager , Zhang San 、 Li Si is the participant of things , The transaction manager is responsible for deciding whether to commit or rollback the entire distributed transaction , Transaction participants are responsible for committing and rolling back their local transactions .
  In the computer, some relational databases such as Oracle、MySQL Support for two-phase commit protocol .

1. Preparation stage （Prepare phase）： The transaction manager sends... To each participant Prepare news , Each database participant performs transactions locally , And write the local Undo/Redo journal , The transaction is not committed at this time .
   （Undo Log is to record the data before modification , For database rollback ,Redo Log is to record the modified data , Used to write data files after committing transactions ）.
2. Submission phase （Commit phase）： If the transaction manager receives an execution failure or timeout message from the participant , Send a rollback directly to each participant （Rollback） news ; otherwise , Send submit （Commit） news ; The participant performs commit or rollback operations according to the instructions of the transaction manager , And release the lock resources used in transaction processing . Be careful ： Resources must be released in the final stage .
   The following figure shows 2PC Two stages of , It is divided into success and failure ：
   Successful cases ：
   

3.2 Solution

3.2.1 XA programme

2PC The traditional solution is implemented at the database level , Such as Oracle、MySQL All support 2PC agreement , In order to unify standards and reduce unnecessary docking costs in the industry , Standard processing models and interface standards need to be formulated , International Open Standards Organization Open Group The distributed transaction processing model is defined DTP（Distributed Transaction Processing Reference Mode）.
In order to make it clear XA The content of the plan , The following new user registration send points as an example to illustrate ：

The execution process is as follows ：

1. Applications （AP） Hold two data sources: user database and credit database .
2. AP adopt TM Notify the user base RM New users , At the same time, inform the point bank RM Add points for this user ,RM The transaction is not committed at this time , At this time, users and integration resources are locked .
3. TM Received execution reply , As long as one side fails, think of the others RM Initiate a rollback transaction , Rollback complete , Resource lock release .
4. TM Received execution reply , All success , At this point, index RM Initiate commit transaction , Submitted , Resource lock release .
   DTP The model defines the following roles ：

• AP（Application Program）： Applications , Can be understood as using DTP The program of distributed transaction .
• RM（Resource Manager）： Resource manager , It can be understood as a participant in a transaction , In general, it refers to a database instance , Control the database through resource manager , The resource manager controls this branch transaction .
• TM（Transaction Manager）： Transaction manager , Responsible for coordination and management of affairs , The transaction manager controls the global transaction , Manage the life cycle of a transaction , And coordinate the various RM. Global transaction refers to the distributed transaction processing environment , You need to operate multiple databases to complete a work, which is a global transaction .
• DTP Model definition TM and RM The interface specification for communication between is XA, Simple understanding of the 2PC agreement , database-based XA Protocol to implement 2PC Also known as XA programme .
• The interaction between the above three roles is as follows ：
  • TM towards AP Provide application programming interface ,AP adopt TM Commit and roll back transactions .
  • TM adopt XA Interface to inform RM Start of database transaction 、 Close and submit 、 Roll back, etc .
    summary ：
    Whole 2PC The transaction flow of involves three roles AP、RM、TM.AP Use of fingers 2PC Applications for distributed transactions ;RM It means resource manager , It controls this branch transaction ;TM The transaction manager , It controls the whole global transaction .
    1） In the preparation stage RM Perform actual business operations , But don't commit the transaction , Resource locking ;
    2） In the submission phase TM Will receive RM In the preparation stage of the implementation of the reply , As long as there is any one RM Execution failure ,TM Will inform all RM Perform a rollback operation , otherwise ,TM All will be informed RM Commit the transaction . Commit phase end resource lock release .

XA The problem of the plan

1. Need local database support XA agreement .
2. The resource lock needs to wait until the end of two phases to release , Poor performance .

3.2.2 Seata programme

seata It is an open source project initiated by Alibaba middleware team Fescar, Later renamed Seata, It is an open source distributed transaction framework .
Tradition 2PC The problem is Seata It has been solved , It drives the completion of global transactions through the coordination of branch transactions of local relational databases , It's middleware working in the application layer . The main advantage is better performance , And it doesn't take long , It's efficient and 0 Intrusion is used to solve the distributed transaction problem in the microservice scenario , It currently offers AT Pattern （ namely 2PC） And TCC Distributed transaction solution of pattern .

Seata The design idea is as follows

Seata One of the design goals is to be non intrusive to the business , Therefore, there is no invasion from the business 2PC The plan begins , In tradition 2PC On the basis of evolution , And solve 2PC The problem with the program .
Seata A distributed transaction is understood as a global transaction containing several branch transactions . The responsibility of the global affairs is to coordinate the branch affairs under its jurisdiction to reach an agreement , Or submit it together successfully , Or fail to roll back together . Besides , Usually the branch transaction itself is a local transaction of a relational database , The diagram below shows the relationship between global transaction and branch transaction ：

With the traditional 2PC The model of is similar to ,Seata Defined 3 A component to protocol the processing of distributed transactions ：

• Transaction Coordinator（TC）： Transaction coordinator , It's independent middleware , Need to deploy independently to run , It maintains the running state of global transactions , receive TM Instruction initiate global transaction commit and rollback , Responsible for working with RM Communication coordinates the commit or rollback of individual branch transactions .
• Transaction Manager（TM）： Transaction manager ,TM Need to work embedded in the application , It is responsible for opening a global transaction , And finally think TC Instructions to initiate global transaction commit or global rollback .
• Resource Manager（RM）： Control branch transactions , Responsible for branch registration 、 Status report , And receive the transaction coordinator TC Instructions , Drive branch （ Local ） Transaction commit and rollback .
  Also take the new user registration to send points as an example Seata Distributed transaction process ：
  

The specific implementation process is as follows

1. User service TM towards TC Request to open a global transaction , The global transaction is created successfully and generates a globally unique XID.
2. User service RM towards TC Register branch transactions , The branch transaction performs the new user logic in the user service , And include it in XID Jurisdiction corresponding to global transaction .
3. The user service performs branch transactions , Insert a record into the user table .
4. The logic execution to remote call integral service is （XID Propagate in the context of the microservice call link ）. Points service RM towards TC Register branch transactions , This branch transaction performs the logic of increasing integral , And include it in XID Jurisdiction corresponding to global transaction .
5. The points service performs branch transactions , Insert a record into the integral record table , After execution , Return to user service .
6. User service branch transaction execution completed .
7. TM towards TC Launch against XID The global commit or rollback resolution for .
8. TC call XID All branch transactions under the jurisdiction complete the commit or rollback request .

Seata Realization 2PC With the traditional 2PC The difference between

Architecture level , Tradition 2PC Of the plan RM It's actually in the database layer ,RM Essentially, it's the database itself , adopt XA Protocol implementation , and Seata Of RM In order to jar The package is deployed on the application side as a middleware layer .
Two phase submission , Tradition 2PC No matter the resolution of the second stage is commit still rollback, The locks of transactional resources should be kept to Phase2 Release when finished . and Seata The way to do this is to Phase1 Commit local transaction , So we can save it Phase2 Time to hold lock , Overall efficiency .