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

This article will explain in detail what the solution to TCC affairs is, and the content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Preface

Before we begin, let's talk about what microservices are. As the name implies, microservices have to be understood from two aspects: what is "micro" and what is "service". In a narrow sense, the small, famous "2 pizza team" well explains this explanation (2 pizza team was first put forward by Amazon CEO Bezos, which means the design of a single service. All participants need only 2 pizzas from design, development, testing, operation and maintenance. The so-called service must be different from the system, service an or a group of relatively small and independent functional units, is the minimum set of functions that users can perceive.

Scene

Here do not talk about what things, Baidu a lot of, we use the code to see the problem ~.

In the traditional single architecture business, Mysql transactions can be used to maintain data consistency. If cross-system, cross-service, cross-database, how to maintain data consistency?

Concept introduction

Before you understand distributed transactions, you need to understand these two concepts: BASE theory and CAP theorem.

BASE theory

BASE is the abbreviation of Basically Available (basic availability), Soft state (soft state) and Eventually consistent (final consistency). BASE is the result of the tradeoff between consistency and availability in CAP. It comes from the conclusion of the distributed practice of large-scale Internet systems and is gradually evolved based on the CAP theorem. The core idea is that even if strong consistency (Strong consistency) cannot be achieved, each application can be based on its own business characteristics. Use the appropriate way to make the system achieve final consistency (Eventual consistency).

BA: Basic Availability basic business availability (failed to support partition)

S: Soft state flexible state (state allows for short periods of async, async)

E: Eventual consistency final consistency (final data is consistent, but not real-time consistent)

CAP theorem

For a shared data system, you can only have two of the CAP at the same time, not all three. Any combination of the two has its own applicable scenarios. The real system should be a mixture of ACID and BASE, and different types of business can and should be treated differently.

TCC of flexible transaction solution

Let's go to the topic and introduce the technical solution of distributed transaction TCC, which starts with the previous picture.

Realize

Here, I describe the implementation ideas and methods in the code, for your reference, the method is not necessarily the best, mainly talking about a basic idea of implementation, there may be a lot of content not taken into account, need your correction.

The design phases of the business include:

Try trial phase: set aside deductions (increase) resources

Confirm submission phase: confirm deduction (increase) of resources

Cancel rollback phase: rollback reserved resources

That is to say, each service provider must implement the method of these three stages.

A complete business activity consists of a master business service and several slave business services.

The main business service is responsible for initiating and completing the entire business activity.

Provide TCC business operations from business services

The business activity manager controls the consistency of business activities, registers operations in business activities, confirms confirm operations of all TCC operations when the business activity is submitted, and invokes cancel operations of all TCC operations when the business activity is cancelled

Concurrency control of TCC transaction considerations

When implementing TCC, users should consider the problem of concurrency and minimize the granularity of locks in order to maximize the concurrency of distributed transactions.

In the one-stage Try operation, the resources reserved by distributed transaction T1 and distributed transaction T2 respectively do not interfere with each other. In this way, in the second phase of a distributed transaction, whether T1 is committed or rolled back, T2 will not be affected, so that T1 and T2 can be executed in parallel on the same business data.

Allow empty rollback

As shown in the following figure, the transaction coordinator may experience a network timeout due to packet loss when invoking a phase of the Try operation of the TCC service. At this point, the transaction manager triggers a two-phase rollback and invokes the Cancel operation of the TCC service, while the Cancel operation call does not time out.

The TCC service receives an Cancel request without receiving a Try request, which is called an empty rollback. Empty rollback often occurs in production environment, and users should allow empty rollback to be performed when implementing TCC service, that is, return success when an empty rollback is received.

Anti-suspension control

As shown in the following figure, the transaction coordinator may time out due to network congestion when invoking one phase of the Try operation of the TCC service. At this point, the transaction manager triggers a two-phase rollback and invokes the Cancel operation of the TCC service, and the Cancel call does not time out. After that, the one-stage Try packet congested on the network is received by the TCC service, and the two-stage Cancel request is executed earlier than the first-stage Try request. After executing the late Try, the TCC service will never receive the second-stage Confirm or Cancel, causing the TCC service to hang.

When implementing the TCC service, the user should allow an empty rollback, but refuse to perform a Try request after a null rollback and avoid hanging.

Idempotent control

Whether it is the retransmission of network packets or the compensation execution of abnormal transactions, the Try, Confirm or Cancel operations of TCC services will be executed repeatedly. When implementing TCC services, users need to consider idempotent control, that is, the business result of Try, Confirm, Cancel execution is the same as that of multiple execution.

On the TCC transaction solution is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.