Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to understand database distributed transactions under high concurrency". In daily operation, I believe many people have doubts about how to understand database distributed transactions under high concurrency. Xiaobian consulted all kinds of materials and sorted out simple and easy operation methods. I hope to help you answer the doubts of "how to understand database distributed transactions under high concurrency"! Next, please follow the small series to learn together!

1 What is a distributed transaction?

Distributed transaction means that the participants of the transaction, the servers supporting the transaction, the resource servers, and the transaction manager are located on different nodes of the distributed system. The above is Baidu encyclopedia explanation, simply put, is a large operation by different small operations, these small operations are 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 about ensuring data consistency across different databases.

2. The causes of distributed transactions

2.1 Database sub-database sub-table

When the data generated by a single database table exceeds 1000W in one year, it is necessary to consider sub-database tables. The principle of specific sub-database tables is not explained here. In the future, it will be free to say in detail that simply one original database has become multiple databases. At this time, if an operation accesses both 01 and 02 libraries, and to ensure data consistency, then it is necessary to use distributed transactions.

2.2 Application SOA

So-called SOA is the service-oriented business. For example, the original single machine supported the entire e-commerce website, but now the entire website is disassembled to separate out the order center, user center and inventory center. For the order center, there is a special database to store order information, the user center also has a special database to store user information, and the inventory center also has a special database to store inventory information. At this time, if you want to operate on orders and inventory at the same time, you will involve the order database and inventory database. In order to ensure data consistency, you need to use distributed transactions.

The above two situations have different appearances, but the essence is the same, because the database to be operated has become more!

3. ACID characteristics of transactions

3.1 Atomicity (A)

Atomicity means that all operations in the transaction are either done or not done, with no intermediate state. If an error occurs in the execution of a transaction, all operations are rolled back, and the entire transaction is as if it had never been executed.

3.2 Consistency (C)

The execution of transactions must ensure the consistency of the system. Take the transfer as an example. A has 500 yuan and B has 300 yuan. If A successfully transfers 50 yuan to B in a transaction, no matter how many concurrent transactions occur, no matter what happens, as long as the transaction is successfully executed, then the final account A must be 450 yuan and the account B must be 350 yuan.

3.3 Isolation (I)

The so-called isolation means that transactions do not affect each other, and the intermediate state of one transaction is not perceived by other transactions.

3.4 Persistence (D)

Persistence means that when a single transaction is completed, the changes made by the transaction to the data are completely preserved in the database, even if there is a power outage and the system is down.

4. Application scenarios of distributed transactions

4.1 Payment

The most classic scenario is payment. A payment is to deduct the buyer's account and add money to the seller's account at the same time. These operations must be performed in one transaction, either all successful or all failed. For the buyer account belongs to the buyer center, corresponding to the buyer database, and the seller account belongs to the seller center, corresponding to the seller database, the operation of different databases inevitably needs to introduce distributed transactions.

4.2 Online order

Buyers placing orders on e-commerce platforms often involve two actions, one is to deduct inventory, and the second is to update order status. Inventory and orders generally belong to different databases, so distributed transactions need to be used to ensure data consistency.

5. Common distributed transaction solutions

5.1 Two-phase commit based on XA protocol

XA is a distributed transaction protocol proposed by Tuxedo. XA is roughly divided into two parts: transaction manager and local resource manager. Local resource managers are often implemented by databases, such as Oracle and DB2, which implement XA interfaces, while transaction managers, as global dispatchers, are responsible for the submission and rollback of local resources. XA implements distributed transactions as follows:

In general, XA protocol is relatively simple, and once commercial databases implement XA protocol, the cost of using distributed transactions is relatively low. However, XA also has fatal shortcomings, that is, the performance is not ideal, especially in the transaction order link, often high concurrency, XA can not meet the high concurrency scenario. XA is currently ideal in commercial databases, but not ideal in mysql databases. XA implementation of mysql does not record the prepare stage log. Switching back from active to standby causes inconsistent data between the primary and standby databases. Many nosqls also don't support XA, which makes XA's application scenarios very narrow.

5.2, Message Transaction + Final Consistency

The so-called message transaction is a two-phase commit based on message middleware. It is essentially a special use of message middleware. It puts local transactions and messages in a distributed transaction to ensure that either local operations succeed and external messages succeed, or both fail. The open source RocketMQ supports this feature. The specific principle is as follows:

System A sends a preliminary message to the messaging middleware.

2. Message middleware saves the prepared message and returns success.

3. A performs local affairs

4. A sends a commit message to the messaging middleware

The above four steps complete a message transaction. For the above four steps, each step may produce errors, the following analysis:

Step 1 error, the entire transaction fails, will not execute A's local operation Step 2 error, the entire transaction fails, will not execute A's local operation Step 3 error, this time need to roll back the preparation message, how to roll back? The answer is that system A implements a callback interface of messaging middleware. The messaging middleware will continuously execute the callback interface to check whether the execution of transaction A is successful. If it fails, it will roll back the prepared message step 4. At this time, the local transaction of A is successful. Does the messaging middleware want to roll back A? The answer is no. In fact, through the callback interface, the message middleware can check that A has successfully executed. At this time, there is no need for A to send a commit message. The message middleware can submit the message itself to complete the entire message transaction. Two-phase commit based on message middleware is often used in high-concurrency scenarios to split a distributed transaction into a message transaction.(Local operation of system A + sending messages)+ local operation of system B, where the operation of system B is driven by messages. As long as the message transaction is successful, the operation of A must be successful and the message must be sent out. At this time, B will receive the message to execute the local operation. If the local operation fails, the message will be resubmitted until the operation of B is successful. In this way, the distributed transaction between A and B is realized in disguise. The principle is as follows:

Although the above scheme can complete the operations of A and B, A and B are not strictly consistent, but ultimately consistent, and we sacrifice consistency here in exchange for a large increase in performance. Of course, this kind of play is also risky, if B has been unsuccessful, then consistency will be destroyed, whether to play specifically, or depends on how much risk the business can bear.

5.3, TCC programming mode

The so-called TCC programming model is also a variant of two-phase commit. TCC provides a programming framework that divides the entire business logic into three blocks: Try, Confirm, and Cancel. Take online order as an example, Try stage will deduct inventory, Confirm stage is to update order status, if update order fails, enter Cancel stage, will restore inventory. In short, TCC is an artificial implementation of two-phase commit through code. The code written in different business scenarios is different and the complexity is different. Therefore, this pattern cannot be reused well.

At this point, the study of "how to understand database distributed transactions under high concurrency" is over, hoping to solve everyone's doubts. Theory and practice can better match to help you learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.