Deep understanding of distributed transactions

This article by the Code Rural network-Wu Heart original, reproduced please see the text at the end of the reprint requirements, welcome to participate in our paid contribution program!

I introduced spring's transaction principle in the previous issue (see "Understanding Spring Transaction Principles" for details), and spring transaction is essentially a single-machine transaction, guaranteed by the database itself. Today, I'll present a more complex transaction: a distributed transaction.

1. What is a distributed transaction

Distributed transactions refer to the participants of the transaction, the servers that support the transaction, the resource servers, and the transaction manager on different nodes of the different distributed systems. The above is the explanation of Baidu Encyclopedia, simply said, is a large operation by 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. Essentially, distributed transactions are designed to ensure data consistency across different databases.

2, the generation of distributed transactions cause 2.1, Database sub-Library table

When the database single-table generation of data more than 1000W, then you need to consider the sub-database sub-table, the specific sub-database of the principle of the table does not explain, after the empty details, simply said that the original database has become a number of databases. In this case, if an operation accesses 01 libraries and accesses 02 libraries, and to ensure the consistency of the data, the distributed transaction is used.

2.2. Application of SOA

The so-called SOA, is the service of business. For example, the original stand-alone support the entire e-commerce 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 storage order information, the User Center also has a dedicated database storage user information, inventory center will also have a dedicated database storage inventory information. At this time, if the order and inventory to operate, then it will involve the order database and inventory database, in order to ensure data consistency, you need to use distributed transactions.

The above two cases are different, but the essence is the same, because the database to operate a lot more!

3, the acid characteristics of the transaction 3.1, atomicity (A)

The so-called atomicity means that all operations in the entire transaction are either complete or not, with no intermediate state. In the event of an error in the execution of the transaction, all operations are rolled back and the entire transaction is as if it had never been executed.

3.2. Consistency (C)

The implementation of the 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 successfully transferred to B50 yuan, then regardless of how much, regardless of what happens, as long as the transaction execution succeeds, then the final a account must be 450 yuan, B account must be 350 yuan.

3.3. Isolation (I)

The so-called isolation means that there is no interaction between transactions and transactions, and that the middle state of a transaction is not perceived by other transactions.

3.4. Persistence (D)

The so-called persistence, that is, a single transaction is completed, then the transaction changes to the data is completely stored in the database, even if there is a power outage, the system is down.

4. Application scenario of Distributed Transaction 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 executed in one transaction, or all success, or all failed. For 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 introduce distributed transactions.

4.2. Order Online

Buyers in the e-commerce platform orders, often involves two actions, one is to buckle inventory, the second is to update the order status, inventory and orders generally belong to different databases, need to use distributed transactions to ensure data consistency.

5. Common Distributed Transaction Solution 5.1, two-phase commit based on XA protocol

XA is a distributed transaction protocol, presented by Tuxedo. Xa is broadly 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 business databases have implemented XA interfaces, and the transaction manager as a global dispatcher, responsible for the submission and rollback of the local resources. The principle of XA implementation of distributed transactions is as follows:

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

5.2. Message Transaction + final consistency

The so-called message transaction is a two-phase commit based on the message middleware, which is essentially a special use of the message middleware, which is to put the local transaction and send the message in a distributed transaction, to ensure that either the local operation succeeds successfully and the outgoing message succeeds, or both fail. The ROCKETMQ of open source supports this feature, with the following specific principles:

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

A message transaction is completed with the above 4 steps. For each of the 4 steps above, each step can produce an error, which is analyzed below:

• An error occurs, the entire transaction fails, and a local operation is not performed
• Step two error, the entire transaction fails, does not perform a local operation
• Step three error, this time need to roll back the preliminary message, how to roll back? The answer is that a system implements a callback interface for the message middleware, and the message middleware will go on executing the callback interface, checking whether a transaction executes successfully, and if it fails, rolls back the prestaged message
• Step four error, when a local transaction is successful, then the message middleware to roll back a? The answer is no, in fact, through the callback interface, the message middleware can check the success of a execution, this time actually do not need a to commit the message, the message middleware can submit their own messages, so as to complete the message transaction

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

Although the above scheme can do a and B operations, but A and B are not strictly consistent, but ultimately consistent, we here sacrifice consistency, in exchange for a significant increase in performance. Of course, this kind of play 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 take.

5.3. TCC Programming Mode

The so-called TCC programming model is also a variant of the two-phase commit. TCC provides a programming framework that divides the entire business logic into three blocks: Try, confirm, and cancel three operations. Take the online order for example, the try phase will be to buckle inventory, the Confirm phase is to update the order status, if the update order failed, then into the cancel phase, will be to restore inventory. In short, the TCC is through the code to achieve a two-phase commit, different business scenarios write code is not the same, the complexity is not the same, therefore, this model is not very good to be reused.

6. Summary

Distributed transactions, in essence, are unified control of multiple database transactions, according to the control force can be divided into: No control, partial control and complete control. No control is not the introduction of 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 the two-phase commit. Some of the benefits of control are concurrency and performance is good, the disadvantage is that data consistency is weakened, full control is sacrificing performance, ensuring consistency, in which way, ultimately depends on the business scenario. As a technical personnel, must not forget the technology is for business services, not for technology and technology, for different business technology selection is also a very important ability!

This article link: http://www.codeceo.com/article/distributed-transaction.html
This Article code rural network – Wu Jicen
[ original works, reproduced must be in the text to mark and retain the original link and the author and other information. ]

Deep understanding of distributed transactions