Understanding of distributed transactions


Business scenario

E-commerce business

Understanding of distributed transactions

The above figure shows the business scenario of an e-commerce system when an order is paid:

  1. Change the status of the order to paid
  2. Deduct commodity inventory
  3. Add points to members
  4. Create an issue order and notify the warehouse of shipment

Imagine that when the order is paid, the personal points are delayed for a few minutes. Is this acceptable?

Train ticket purchase

Think about the scene of buying train tickets in life.

Imagine that when the last train ticket is purchased by two people at the same time, when you go to the ticket gate to check in, you are told that the ticket is invalid. Is this acceptable?

bank transfer

Think about bank transfers in your life.

Imagine that when a bank transfers money, after the transfer is successful, the amount of its own account decreases, but the other account has not been credited. Is this acceptable?

How do you understand and handle the above three business requirement scenarios?

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

What is a transaction?

A transaction is a series of operations performed as a single logical unit of work, either completely or not.

Database transactions must be familiar to everyone and will be often used in the development process.

Characteristics of transactions

  • Atomicity
  • Consistency
  • Isolation
  • Durability

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

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

IsolationIt means that the execution of a transaction cannot be disturbed by other transactions.

persistenceOnce a transaction is committed, its changes to the data in the database should be permanent.

What is distributed transaction?

Distributed transaction means that a large operation is composed of different small operations, which are distributed on different servers. Distributed transaction needs to ensure that these small operations are either completely executed or not completed.

Causes of distributed transactions

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

Distributed theory

Cap theory

  • Consistency
  • Availability
  • Partition tolerance

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

usabilityIt means that each request can obtain the expected response results within a reasonable time.

Partition tolerance It means that in case of any network partition failure, the system can still provide services normally, unless the whole network environment fails.

Understanding of distributed transactions

CAPTheory holds that a distributed system can only meet two of them at most. Because partition fault tolerance is inevitable, most distributed software systems choose between CP and AP.

For example:ZookeeperAdopt CP consistency, emphasize consistency and weaken availability,EurekaAdopt AP availability, emphasize availability and weaken consistency.

Base theory

  • Basically available
  • Soft state
  • Eventually consistent

Basically availableIt means not pursuing strong availability, but emphasizing that the system can basically run all the time and provide external services. When the distributed system encounters unpredictable faults, it is allowed to be unavailable to a certain extent, such as limiting the flow queuing of requests and degrading non core services.

Soft stateIt means that the data in the system is allowed to have an intermediate state, rather than the atomicity of the transaction: either all succeed or all fail.

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

BASEThe core idea of the 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.


2pc (two phase submission protocol)

3pc (three phase submission agreement)


Local message table

Rocketmq transaction message


This article is purely to attract jade. If there are problems, criticism and correction are welcome.

I will introduce the implementation scheme of distributed transactions in subsequent articles.

Recommended reading

Recommended Today

Seven Python code review tools recommended

althoughPythonLanguage is one of the most flexible development languages at present, but developers often abuse its flexibility and even violate relevant standards. So PythoncodeThe following common quality problems often occur: Some unused modules have been imported Function is missing arguments in various calls The appropriate format indentation is missing Missing appropriate spaces before and after […]