Introduction to distributed transactions

Catalog

One 、 Distributed transaction concept

1、 What is business

2、 Local transactions

3、 Distributed transactions

4、 Distributed transaction generation scenario

Two 、 Basic theory of distributed transaction

1、CAP theory

2、BASE theory

---

One 、 Distributed transaction concept

1、 What is business

Business can be seen as a big activity , It's made up of different little activities , These activities are either all successful , All or nothing .

2、 Local transactions

Four features of database transaction 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 transfer is in correct status, which is called consistency , If Zhang San turns out 100 element , Li Si's account didn't increase 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 reading can be avoided by configuring 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 .

3、 Distributed transactions

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 .

4、 Distributed transaction generation scenario

• The typical scenario is microservice architecture , Between microservices   The remote call completes the transaction   operation . such as ： Order and inventory microservices , When placing an order, the order micro service requests the inventory micro service to reduce the inventory . in short ：  Span JVM Process generates distributed transaction  .
• A single system accesses multiple database instances ,  Generate distributed transactions across database instances  .
• Multiple services access the same database instance  , such as ： Order and inventory microservices generate distributed transactions even if they access the same database , The reason is that   Span JVM process  , The two microservices hold different database links for database operation , A distributed transaction is generated .

Two 、 Basic theory of distributed transaction

1、CAP theory

1） Concept

CAP yes Consistency、Availability、Partition tolerance Abbreviations of three words , They mean consistency 、 Usability 、 Zone tolerance .

2） combination

In all distributed transaction scenarios, there will be no CAP Three characteristics , Because I have P Under the premise of C and A Can't coexist .

• AP： Give up consistency , The pursuit of partition tolerance and usability . This is the choice of many distributed systems when they are designed  .Eureka Cluster is adopted AP design idea .
• CP： Discard availability , Pursue consistency and partition fault tolerance .zookeeper colony .
• CA： Give up zoning tolerance , That is to say, there is no partition , Don't consider the problem of network failure or node hang up , You can achieve consistency and availability . Then the system will not be a standard distributed system , Our most commonly used relational data is enough CA.

3） summary

CAP It's a proven theory ： A distributed system can only satisfy at most Uniformity （Consistency）、 Usability （Availability） And zone tolerance （Partition tolerance） Two of these 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.99..%）, 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  .

2、BASE theory

1） Strong consistency and final consistency

• Strong consistency ：CAP Consistency in requires that each node data must be consistent at any time when queried , It emphasizes strong consistency .
• Weak consistency ： After the data is updated successfully , The system does not promise to read the latest written value immediately , I don't promise how long it will take to read .
• Final consistency ： Allow yes   In a period of time, the data of each node is inconsistent  , But after a period of time, the data of each node must be consistent , It emphasizes   Consistency of final data  .

2） Concept

BASE yes Basically Available( Basic available )、Soft state( Soft state ) and Eventually consistent ( Final consistency ) Abbreviations of three phrases .

BASE The theory is right CAP in AP An extension of , Get availability 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 a 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 in system   There is an intermediate state  （ 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 consistency  ： 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 .