The business scenario
Electrical business
The above picture is an e-commerce system, and the business scenario after the payment of an order is completed:
- Change order status to “paid”
- Deducting inventory of goods
- Add points to members
- Create an outbound order to notify the warehouse of delivery
Imagine a delay of a few minutes for individual points to change when the order is paid. Is that acceptable?
Train ticket
Think about buying a train ticket in your life.
Imagine, when the last train ticket is bought by two people at the same time, go to the ticket barrier and be told that the ticket is invalid, is that acceptable?
Bank transfer
Think about a bank transfer scenario in your life.
Imagine, when the bank transfer, after the transfer is successful, the amount of your account is reduced, but the other party’s account has not been received, this is acceptable?
How do you understand and handle these three business requirements scenarios?
Before dealing with the above problems, let’s understand the following concepts.
What is a transaction?
A transaction is a series of operations that are performed as a single logical unit of work, either completely or not.
Database transactions are certainly familiar to all of you and will be used frequently in your development process.
Transaction characteristics
- Atomicity
- Consistency
- Isolation
- “Durability”
Atomicity means that all or none of the operations in a transaction are done.
Consistency means that transactions must change the database from one consistent state to another.
Isolation means that the execution of one transaction cannot be interfered with by other transactions.
Persistence is the idea that once a transaction is committed, its changes to the data in the database should be permanent.
What is a distributed transaction?
A distributed transaction is one in which a large operation is composed of different small operations that are distributed across different servers, and the distributed transaction needs to ensure that these small operations are either fully executed or not executed at all.
Causes of distributed transactions
- Microservitization of businesses, such as the e-commerce business scenario described at the beginning of this article.
- Database database sub-table, for example: when the database sub-table, there is a need to operate both 01 library and 02 library.
Distributed theory
Theory of CAP
- Consistency
- Availability, Availability
- Partition tolerance
Consistency is a strong consistency of data. If data is updated at one node, the updated data needs to be seen at other nodes at the same time.
Availability is the ability to get an expected response to each request within a reasonable time.
Partition fault tolerance means that the system can still provide services when any network partition is faulty, unless the entire network environment is faulty.
According to CAP theory, a distributed system can only satisfy two of them at most. Since partition fault tolerance is inevitable, most distributed software systems choose between CP and AP.
For example, Zookeeper uses CP consistency to emphasize consistency and weaken availability. Eureka uses AP availability to emphasize availability and weaken consistency.
The BASE theory of
- Basically Available
- Soft state
- Eventually consistent
Basic availability refers to not pursuing strong availability, but emphasizing that the system can basically run all the time to provide services. When a distributed system encounters an unpredictable failure, it allows a certain level of unavailability, such as traffic limiting and queuing requests, and downgrading non-core services.
Soft state refers to allowing data in a system to have an intermediate state, rather than the atomicity of transactions: all or nothing succeeds.
The final consistency means that the data cannot be soft all the time and must reach the consistency of each node after a time period. After that, the data of all nodes are consistent and the system reaches the final consistency.
The core idea of BASE theory is that even if strong consistency cannot be achieved, each application can adopt appropriate ways to achieve the final consistency of the system according to its own business characteristics.
The solution
2PC(Two-phase commit Protocol)
3PC(Three-phase Delivery Protocol)
TCC
Local message table
RocketMQ transaction message
summary
This article is purely a brick to attract jade, there are problems, welcome criticism and correction.
I will discuss the landable solution for distributed transactions in a future article.
Recommended reading
- About the process of the order status of the e-commerce system flow, share my technical solution (with source code)
- How do I write Git Commit message?