Deep understanding of distributed transactions

Reproduced from:
Blog Park

I introduced spring's transaction principles in the previous issue (see Deep understanding of the spring Transaction principle), the spring transaction is essentially a stand-alone transaction and is guaranteed by the database itself. Today, I'm going to introduce a more complex transaction: distributed transactions.
1. What is a distributed transaction

A distributed transaction is the participant of a transaction, a server that supports transactions, a resource server, and a transaction manager located on different nodes of a different distributed system. The above is Baidu Encyclopedia explanation, simply said, is a big operation consists of different small operations, these small operations distributed on different servers, and belong to different applications, distributed transactions need to ensure that these small operations are either all successful, or all failed. In essence, distributed transactions are meant to ensure data consistency in different databases.
2, the cause of the distributed transaction
2.1. Database sub-tables

When the database sheet produced more than 1000W a year, it is necessary to consider the sub-Library, the principle of the specific sub-table in this do not explain, later have empty detail, simply said that the original database has become a number of databases. At this point, if an operation accesses both 01 libraries and 02 libraries, and ensures the consistency of the data, then a distributed transaction will be used.

2.2, the application of SOA

The so-called SOA is the service of the business. For example, the original stand-alone support of the entire electrical business site, now the entire site to dismantle, separated out the order center, User Center, Inventory Center. For the order center, there is a special database to store order information, the User Center also has a dedicated database to store user information, Inventory center will have a special database to store inventory information. At this point, if the order and inventory to operate at the same time, it will involve the order database and inventory database, in order to ensure data consistency, you need to use distributed transactions.

The above two situations are different, but the same is true because there are more databases to manipulate.
3, the ACID properties of the transaction
3.1. Atomic sex (A)

So-called atomicity means that all operations in the entire transaction are either complete, or all are done, and there is no intermediate state. In the event of an error in the execution of a transaction, all operations are rolled back and the entire transaction is as if it had never been performed.
3.2. Consistency (C)

The execution of a transaction must ensure the consistency of the system, take the transfer for example, A has 500 yuan, B has 300 yuan, if in a transaction a successful transfer to B50 yuan, then no matter how much, no matter what happens, as long as the success of the implementation of the transaction, then the last a account must be 450 yuan, B account must be 350 yuan.
3.3. Isolation (I)

The so-called isolation means that the transaction does not interact with the transaction, and the middle state of a transaction is not perceived by other transactions.
3.4, Durability (D)

The so-called durability, that is, a single transaction is complete, then the transaction to the data changes are completely stored in the database, even if there is a power outage, the system downtime.
4, the application of distributed transaction scenarios
4.1. Payment

The most classic scenario is to pay, a payment, the buyer's account is deducted, while the seller's account to add money, these operations must be carried out in a transaction, either all successful, or all failed. The buyer's account belongs to the buyer's center, corresponding to the buyer's database, and the seller's account belongs to the seller's center, corresponding to the seller database, the operation of different databases must be introduced into the distributed transaction.
4.2, the online order

Buyers in the electric business platform under the list, often involves two actions, one is deducted inventory, the second is to update order status, inventory and orders are generally different databases, need to use distributed transactions to ensure data consistency.
5. Common Distributed Transaction Solutions
5.1. Two-stage submission based on XA protocol

XA is a distributed transaction protocol, proposed by Tuxedo. Xa is roughly divided into two parts: the transaction manager and the local resource manager. Where the local resource manager is often implemented by the database, such as Oracle, DB2 these commercial databases all implement the XA interface, and the transaction manager as a global dispatcher, responsible for the individual local resources commit and rollback. The principle of XA implementing distributed transactions is as follows:

In general, the XA protocol is relatively simple, and once the business database has implemented the XA protocol, the cost of using distributed transactions is also relatively low. However, XA also has the fatal disadvantage, that is, performance is not ideal, especially in the single link under the transaction, often high concurrency, XA can not meet high concurrency scenarios. XA currently in the business database support is relatively ideal, in the MySQL database support is not ideal, the MySQL implementation of XA, there is no record prepare phase log, primary standby switch back to cause the main library and the standby data inconsistent. Many NoSQL also do not support XA, which makes XA's application scenario very narrow.
5.2, message transactions + final consistency

The so-called message transaction is a two-phase commit based on message middleware, which is essentially a special use of message middleware, where local transactions and messages are placed in a distributed transaction, ensuring that either the local operation succeeds successfully and the outgoing message succeeds or both fail. Open source ROCKETMQ Support this feature, the specific principle is as follows:

1. A system sends a preliminary message to the message middleware
2, message middleware Save the standby message and return to success
3. A performs local affairs
4, a send a submit message to the message middleware

Complete a message transaction with the above 4 steps. For each of the 4 steps above, each step can produce an error, and the following is an analysis:

An error occurs, the entire transaction fails, does not perform a local operation
Step two error, the entire transaction fails, does not perform a local operation
step three error, you need to rollback the preparatory message, how to roll back. The answer is a system to implement a message-oriented middleware callback interface, message-oriented middleware will continue to carry out the callback interface, check a transaction execution is successful, if the failure to roll back the preparatory message
step four error, at this time a local transaction is successful, then message middleware to roll back a. The answer is not needed, in fact, through the callback interface, message middleware can check the success of a execution, this time does not need a to send a message, message-oriented middleware can submit their own message to complete the entire message transaction

Two-stage submission based on message-oriented middleware is often used in high concurrency scenarios split a distributed transaction into a message transaction (a system local operation + message) +b The system's local operation, where the operation of the B system by the message-driven, as long as the message transaction is successful, then a operation must be successful, the message must be sent out, At this point B will receive a message to perform the local operation, if the local operation fails, the message will rejoin until the B operation succeeds, thus implementing A and B distributed transactions in disguise. The principle is as follows:

Although the above scheme is capable of completing A and B operations, A and B are not strictly consistent, but ultimately consistent, where we sacrifice consistency for a significant improvement in performance. Of course, this game is also risky, if B has been unsuccessful, then the consistency will be destroyed, specifically to play, or to see how much risk the business can bear.
5.3. TCC Programming Mode

The so-called TCC programming model is also a variant of two-stage submissions. TCC provides a programming framework that divides the entire business logic into three pieces: Try, confirm, and cancel three operations. Take the online order as an example, the try phase will be to withhold inventory, confirm phase is to update the order status, if the update order failed, enter cancel phase, will restore inventory. In short, TCC is through the code for the implementation of two-stage commit, different business scenarios are written in the same code, complexity is not the same, so this model is not well reused.
6, summary

Distributed transaction, which is essentially a unified control of multiple database transactions, can be divided into: uncontrolled, partial control and full control according to the control dynamics. Control is not to introduce distributed transactions, part of the control is a variety of two-phase commit, including the above mentioned message transaction + final consistency, TCC mode, and full control is to fully implement two-phase commit. Some of the benefits of control are concurrency and performance is good, the disadvantage is that data consistency is weakened, complete control is sacrificing performance, ensure consistency, in which way, ultimately, depending on the business scenario. As a technician, must not forget the technology is for business services, not for technology and technology, for different types of business technology selection is also a very important ability.