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

This article mainly introduces "how to understand the TCC pattern in the distribution". In the daily operation, I believe that many people have doubts about how to understand the TCC pattern in the distribution. The editor has consulted all kinds of materials and sorted out the simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how to understand the TCC pattern in the distribution". Next, please follow the editor to study!

TCC Review

What on earth is TCC?

In the case of the classic e-commerce system, when a customer buys a commodity, the system needs three services to cooperate. Order service increases order, inventory service deducts inventory, account service deducts amount. As shown below:

If we use the method shown above, each service commits its own transaction, there is a good chance of data inconsistency. Because the three services use different databases, it is not an atomic operation, for example, the order service is successfully submitted and the account service fails, so the data is inconsistent.

The idea of TCC is to use 2-phase commit, the try phase first tries to reserve resources for each service, if the reservation succeeds, it enters the commit phase to commit the transaction, and if there is a service reservation failure, enter the cancel phase to cancel the transaction. This requires the addition of a coordination node to issue commands to the three services and get the branch transaction execution results for each service. The try phase is shown in the following figure:

In the try phase, if the reservation of resources for each service succeeds, the coordinator node issues a commit command to each service, as shown below:

After all the service commit succeeds, the entire transaction is completed.

Code implementation

The orchestrating node needs to provide each distributed transaction with a global transaction id, called xid, which is used to bind to the local transaction of each service. Taking the account service as an example, let's take a look at the code of these three phases of try/commit/cancel:

This code uses jdbc to handle local transactions. In the try phase, we get the connection and save it in connectionMap,key as xid, so in the commit/cancel phase, we take the connection from the connectionMap to commit/rollback.

There are problems

Is there a problem with the code implementation of the TCC pattern above?

Service cluster

As shown in the figure below, if the order service cluster is deployed on three machines, the try request is sent to order service 1, and the commit request is sent to order service 2. How can the connectionMap of order service 2 have this value of xid=123? The order service local transaction cannot be submitted.

So if you really want to commit the transaction in a way that keeps connection, the orchestrating node needs to ensure that the try/commit/cancel request corresponding to the same xid is on the same machine.

The solution must be to transform the registry, or coordinate the node to maintain its own list of services. The former allows the registry to couple the business code, while the latter is equivalent to abandoning the registry.

Empty submission

The transformation of registries and orchestrating nodes requires a lot of work, is there any other way? Let's make an improvement. Here the orm framework uses mybatis and the code is as follows:

The try phase needs to reserve resources. If this code succeeds in reserving resources, it has already committed the branch transaction, while the commit phase is just an empty commit and has no practical effect.

Another way is to return the true directly in the try phase and actually commit the transaction in the commit phase.

But both of these approaches run counter to TCC's ideas.

Idempotent

If the orchestrator node sets a timeout retry, as shown in the figure below, order service 1 fails after executing the try method, and the orchestrator node will retry if it does not receive a successful reply, so that the order service will repeatedly execute the try method.

In order to avoid this problem, the try/confirm/cancel method must add idempotent logic to record the execution state of the global transaction xid corresponding to the local transaction.

Empty rollback

When using the framework to implement the TCC pattern, there will be an empty rollback.

As shown in the figure above, due to the failure of the order service node 1, the try method fails, but the global transaction has been opened, and the framework must push the global transaction to the end state, so the order service cancel method has to be called for rollback. As a result, the order service has run the cancel method once.

To solve this problem, the try phase needs to record the execution status of the branch transaction corresponding to the xid, and the cancel phase judges according to this record.

Suspension

As mentioned above, an empty rollback will occur during the use of seata. If an empty rollback occurs, the global transaction ends after the cancel method is executed. However, due to network problems, the order service receives another try request. Resources are successfully reserved after the try method is executed, but these resources cannot be released.

The way to solve this problem is to record the execution status of the branch transaction corresponding to xid in the cancel method, and determine whether the branch transaction has been rolled back when the try phase is executed.

High code intrusion

Try/commit/cancel of TCC invades business code. If idempotent, empty rollback, suspension and so on are taken into account, code intrusion will be even higher.

Summary

TCC is a very classic pattern in distributed transactions, but even with the help of the framework, the code implementation is more complex.

Service cluster, empty commit, idempotent, empty rollback, suspension and other problems need to be considered in practical use.

It is highly intrusive to business code.

At this point, the study on "how to understand the TCC pattern in distribution" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.