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

Today, I will talk to you about how to choose the distributed transaction implementation scheme in the micro-service architecture. Many people may not know much about it. In order to make you understand better, the editor summarized the following contents for you. I hope you can get something from this article.

1 distributed transaction solution

According to the characteristics of distributed system, different distributed transaction solutions are produced based on different consistency requirements, such as strong consistent two-phase commit, flexible transaction and transaction message and so on. All kinds of schemes are not absolutely good or bad, and apart from the specific scenarios, we can not evaluate them, let alone make reasonable choices. When choosing a distributed transaction scheme, we need to fully understand the principle and design intention of various solutions, and then combine with the actual business scenarios, so as to make a scientific and reasonable choice.

2 strong consistent solution

2.1 two-phase submission

There are two roles in the two-phase commit algorithm: transaction coordinator and transaction participant. A transaction usually involves multiple transaction participants. The specific two-phase process is shown in the following figure:

The first stage: after the completion of the write library operation, the coordinator sends a Prepare message to all participants, asking whether the local transaction of each participant can be submitted, and the participant returns yes or no to the coordinator according to his or her own situation.

The second stage: after receiving the feedback from all participants, the coordinator sends a commit transaction command to all participants if all returns can be committed. As long as one participant returns that it cannot be submitted, a rollback command is sent to all participants. As shown in the following figure:

Figure 1 two-phase submission

In the above two-phase model, there may be downtime of the coordinator or individual participants in the transaction commit process, but in most cases, the nodes involved in the transaction can know the status of the transaction by asking other nodes and do the correct operation. However, in extreme cases, the transaction may be in an unknown state. In view of the shortcomings of the two phases, a three-phase submission protocol is proposed.

2.2 three-phase submission

The three-stage submission is to split the second stage into two stages: pre-submission and confirmation submission. In this way, during the transaction commit process, no matter which node is down, as long as one of the surviving nodes is in pre-commit or commit state, we can determine that the transaction can be committed (the first phase has confirmed that the transaction can be committed). On the contrary, if there are no nodes in these two states, the transaction is rolled back.

Figure 2 three-phase submission

From the above analysis, we can see that whether two-phase or three-phase final "commit" is a very short time-consuming operation, even in the distributed system, the probability of failure is very small, so we can think that two-phase commit can basically guarantee the atomicity of distributed transactions.

3 landing plan

What is described above is only the theoretical basis. XA specification is a distributed transaction specification based on the theoretical model of two-phase commit, in which the resource manager is equivalent to the transaction participant; the transaction manager is equivalent to the transaction coordinator. At present, many mainstream relational databases have implemented the XA interface.

In practical application, we will find some problems in two-phase submission:

1. Database products need to be locked in order to ensure data completion, so the locking time of database resources may be too long in the whole process of distributed transaction coordination, which is not suitable for business scenarios with high concurrency and long life cycle of sub-transactions.

2. XA specification requires the transaction manager to record the transaction execution status locally, so as a stateful service, the transaction manager does not support transaction remote recovery.

XA can maximize data consistency, but the performance degradation is very serious in high concurrency scenarios, so it is not recommended if it is not "strongly consistent" in data consistency requirements.

3.1 final consistency solution

In most of our business scenarios, we pursue the ultimate consistency of data, and the industry has also proposed a lot of flexible transaction solutions, which can ensure the consistency of data to a large extent, which can be weighed and used according to the actual scenario. There are many specific solutions, and their design ideas can be divided into the following three models:

3.1.1 TCC (Try-Confirm-Cancel)

TCC divides the transaction into three phases of Try,Confirm,Cancel.

1. Try phase: try to execute the business and reserve resources

2. Confirm phase: confirm the execution of the business and use the Try phase resources

3. Cancel phase: cancel the execution of business and release the resources reserved in Try phase

We use a business scenario of transfer and remittance to illustrate the specific process of TCC. For example, Zhang San transfers 100 yuan to Li Si, and the one-time transfer business consists of two local transactions: 1, deducting 100 yuan from Zhang San's account; 2, increasing Li Si's account by 100 yuan.

The successful transaction processing process is shown in figure 3:

Figure 3 Try-Confirm transaction successful processing flow

The transaction failure processing flow is shown in figure 4:

Figure 4 Try-Cancel transaction successful processing flow

Try phase:

1. Check Zhang San's account, meet the requirements of the account deduction of 100 yuan, record deduction events (reserved resources)

2. Check the validity of Li Si's account

Confirm:

If the Try is successful, Li Si's account will be increased by 100 yuan and the transaction will be completed.

Cancel:

If Try fails, Zhang San's account will be increased by 100 yuan, the deduction event record will be deleted (the reserved resources will be released), and the transaction will be cancelled.

From a performance point of view, the TCC process does not lock resources and has almost no impact on system concurrency performance, but there are some additional auxiliary operations. It should be noted that there are two technical difficulties that need to be addressed to ensure data consistency in this model:

1. A role similar to a transaction manager is required to ensure the integrity of the TCC process

2. Confirm and Cancel methods need to be idempotent (idempotent due to inevitable retry operations)

TCC is very intrusive to the business, very unfriendly to RD students, and the cost of business transformation is quite high.

3.1.2 SAGA model

The SAGA model divides a distributed transaction into multiple local transactions, and each local transaction has a corresponding execution module and compensation module. When any local transaction in the transaction goes wrong, the previous transaction can be restored by calling the corresponding compensation method, so as to achieve the final consistency of the data. The transaction manager of SAGA is responsible for performing compensation logic when a transaction fails, which can be achieved by invoking reverse operations of the execution module (such as generating inverse SQL while executing subtransactions) or by invoking compensation methods provided by business developers (which need to ensure the idempotency of compensation).

You can see that although SAGA has caused some intrusions into the business, it is much better than TCC, and the transaction manager can theoretically compensate backward (undo all completed operations and return to the transaction start state) or forward compensation (continue to complete unfinished transactions, so that business requests can be processed successfully, more in line with business expectations).

3.1.3 MQ transaction messages

MQ transaction message simplifies the distributed transaction model, the focus is no longer to ensure the atomicity of all sub-transactions, but to ensure the atomicity of local transactions and sending MQ messages. We can take advantage of this feature to transform distributed transactions into local transactions and several operations that send MQ messages, and then require consumers to ensure the success of consumption. By using MQ transaction message, the role of transaction manager in TCC and SAGA schemes is removed from the system, which simplifies the distributed transaction model. At the same time, it is also the lowest and most friendly scheme for business intrusion (no compensation interface is provided).

Of course, there are two basic premises:

1. MQ system ensures that messages are not lost.

two。 Consumers ensure that consumption is idempotent (ensuring that it is not lost, it is difficult to avoid repeated consumption).

It should be noted that MQ transaction messages simplify the transaction model and reduce business intrusion, so the guarantee of data consistency is relatively low.

4. Summary

Let's compare several distributed transaction solutions:

Consistency guarantee: XA > TCC = SAGA > transaction messages

Business friendliness: XA > transaction message > SAGA > TCC

Energy loss: XA > TCC > SAGA = transaction message

Finally, when designing the system, we must choose the appropriate scheme according to the consistency requirements of the business itself. We can see that the higher the data consistency guarantee, the greater the development cost, maintenance difficulty and system performance loss. We must not blindly pursue high-end solutions and over-design the system.

After reading the above, do you have any further understanding of how to choose the distributed transaction implementation scheme in the micro-service architecture? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.