[distributed theory] (I) distributed transactions

Distributed transactions

1, What is distributed transaction

Local transactions ： Transactions controlled by relational databases , All transactions have ACID Four characteristics , And here's C It means strong consistency , Depend on AID Realize and realize .Mysql The implementation of transactions depends on logs 、MVCC、ReadView methods .

Distributed transactions ： In a distributed system , Multiple systems operate a transaction together , This transaction can occur in a database , It can also occur in multiple databases , These are all distributed transaction problems . There is another case , Our business has carried out sub database operation , A business involves multiple data sources , It is also a distributed transaction problem .

so , As long as cross system data interaction occurs, distributed transactions are involved . Typical scenes are , Order system and inventory system of e-commerce system ; Recharge and payment in the financial scene .

2, The theoretical basis of distributed transaction processing

2.1,CAP theory

How to deal with distributed transactions , Usually we should follow CAP theory .

CAP：— Sexual nature (Consistency); Usability (Availability); Partition tolerance (Partition Tolerance). There's only two out of three .

Consistency requirements , The data read by the client from the node must be consistent ; Availability requirements , The data read by the client from the node is not necessarily the latest , But you must be able to read the data ; Partition fault tolerance requirements , Node failure , Other nodes can still provide services .P It must be implemented in distributed systems .

CAP Combination of ：

1、CA： Give up zoning tolerance , Enhance consistency and availability , For example, relational databases follow CA Design ;

2、AP： Give up consistency , Enhance availability and partition tolerance , The pursuit of ultimate consistency , quite a lot NoSQL Database according to AP Design . explain ： Abandoning consistency here means abandoning strong consistency , Strong consistency is to query the latest data immediately after the write is successful . The pursuit of final consistency means allowing temporary data inconsistencies , As long as the end user accepts the data within the time It's OK to be consistent .

3、CP： Discard availability , Strengthen consistency and zoning tolerance , Some systems with strong consistency requirements are CP Design , For example, inter-bank transfer , A transfer request is not complete until the banking systems of both parties have completed the whole transaction .

In our actual system design , It's using AP+ The final consistent plan . For example, our order refund , The form of delayed arrival .

2.2,Base theory

BASE The theory is CAP In theory AP Extension of contract , Emphasize basic availability （Basically Available）、 Soft state (Soft State) And final conformity (Eventual Consistency).

Basic available ： The sacrificial part is available , Ensure the normal operation of the core system ;

Soft state ： There is an intermediate state in operation , For example, the delay in master-slave synchronization ;

Final consistency ： Reach consistency at the final time .

3, Distributed transaction solutions

3.1,2PC

I.e. two phase submission agreement , By introducing a transaction manager as coordinator .

The first stage ： vote . The transaction manager sends CanCommit request , Other nodes agree , Then execute the transaction operation in the request , Write to the log ; If you disagree, terminate the operation ;

The second stage ： Submit . The transaction manager receives yes After reply , Send to participants DoCommit The commit instruction executes the commit operation ; otherwise , Send rollback instructions DoAbort, Participants perform rollback locally , End of transaction .

analysis ： There is a synchronization blocking problem in transactions , Single point problem , Data inconsistency （ Some participants' networks are abnormal ）.2PC Strong consistency , such as Mysql Medium redolog Log submission adopts 2PC programme .

3.2,3PC

2PC Improvement , Introduce pre submission and timeout mechanisms , solve 2PC Synchronization blocking in . It is divided into CanCommit,PreCommit,DoCommit Stage .3PC Is characterized by , If there is no response for a long time , The transaction is committed by default , Not like 2PC So consistent blocking .

however 3PC Undoubtedly, it increases the communication complexity of the system , And it will also lock resources , Cannot solve the problem of data consistency .

3.3,TCC

2PC Improvement , Pay attention to business compensation . differ 2PC,3PC Implement transactions at the database level ,TCC It is to solve business problems at the business level . Include Try,Confirm,Cancle Three stages .TCC The transaction scheme interface needs to meet idempotency , And each interface needs to be implemented Try,Confirm,Cancle Interface , High development cost .

3.4, Message queuing achieves final consistency

That is, through the retry mechanism of message queue , Try again and again , Achieve ultimate consistency . The premise is that the business interface is idempotent .