Understanding of distributed transactions

Business scene

E-commerce business

The picture above is an e-commerce system, when an order payment is completed, the business scenario:

1. Change the status of the order to "paid"
2. Deduction of commodity inventory
3. Add points to members
4. Create an outbound order to notify the warehouse to deliver goods

Imagine that when the order payment is completed, the personal points change is delayed for a few minutes. Is this acceptable?

Train ticket purchase

Think about the train ticket purchase scene in life.

Imagine that when the last train ticket was purchased by two people at the same time, and when they went to the ticket gate to check the ticket, they were told that the ticket was invalid. Is this acceptable?

Bank Transfer

Think about the bank transfer scenario in life.

Imagine that when the bank transfers money, after the transfer is successful, the amount in your account decreases, but the other party's account has not been credited. Is this acceptable?

Regarding the above three business demand scenarios, how do you understand and deal with them?

Before dealing with the above problems, let's first understand the following concepts.

What is a transaction?

A transaction refers to a series of operations performed as a single logical unit of work, either completely executed or not executed at all.

Everyone must be familiar with database affairs, and will be used frequently in the development process.

The characteristics of the transaction

• Atomicity (atomicity)
• Consistency
• Isolation
• Durability

atomicity means that the operations in the transaction are either not done or all done.

consistency means that the transaction must change the database from one consistent state to another consistent state.

isolation means that the execution of a transaction cannot be interfered by other transactions.

Persistence means that once a transaction is committed, its changes to the data in the database should be permanent.

What is a distributed transaction?

Distributed transaction refers to a large operation composed of different small operations, and these small operations are distributed on different servers. Distributed transactions need to ensure that these small operations are either completely executed or not executed completely.

Reasons for distributed transactions

• Business microservices, such as the e-commerce business scenario described at the beginning of the article.
• Database sub-database sub-table, for example: when the database sub-database sub-table occurs, there is a requirement to operate both the 01 database and the 02 database.

Distributed theory

CAP theory

• Consistency
• Availability
• Partition tolerance

consistency refers to the strong consistency of the data. If the data is updated at a node, the updated data needs to be seen at the other nodes at the same time.

availability of means that every request can obtain an expected response result within a reasonable time.

partition fault tolerance means that when any network partition fails, the system can still provide services normally, unless the entire network environment fails.

CAP theory believes that a distributed system can only satisfy two of them at the same time. Since partition fault tolerance is inevitable, most distributed software systems make a trade-off between CP and AP.

For example: Zookeeper adopts CP consistency, which emphasizes consistency and weakens usability, and Eureka adopts AP usability, which emphasizes usability and weakens consistency.

BASE theory

• Basically Available
• Soft state
• Eventually consistent

basically usable means that it does not pursue strong availability and emphasizes that the system can basically run all the time to provide services to the outside world. When the distributed system encounters an unpredictable failure, a certain degree of unavailability is allowed, such as: limiting the flow of requests and queuing, and degrading non-core services.

soft state refers to allowing the data in the system to exist in an intermediate state, not the atomicity of the transaction: either all succeed or all are unsuccessful.

final consistency means that the data cannot always be in a soft state, and the consistency of each node must be reached after a period of time. After that, the data of all nodes are consistent, and the system reaches final consistency.

BASE theory is: even if strong consistency cannot be achieved, each application can adopt an appropriate method to make the system achieve final consistency according to its own business characteristics.

solution

2PC (two-phase submission protocol)

3PC (three-phase submission protocol)

TCC

Local message table

RocketMQ transaction message

summary

This article is purely an introduction, there are problems, criticisms and corrections are welcome.

Regarding the feasible solution for distributed transactions, I will introduce it in a follow-up article.

Recommended reading

• Regarding the processing of the e-commerce system order status transfer, share my technical solution (with source code)
• How do I write Git Commit message?