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

This article mainly explains "What are the common distributed transaction solutions?" Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let Xiaobian take you to learn "what common distributed transaction solutions are there"!

1 Development of microservices

Microservices advocate splitting a complex monolithic application into several simple, loosely coupled services, which can reduce development difficulty, enhance scalability, and facilitate agile development. At present, it is respected by more and more developers, and many Internet industry giants and open source communities have begun to discuss and practice microservices. Hailo has 160 different service components and NetFlix has about 600 services. Domestically, Alibaba, Tencent, 360, Jingdong, 58 Tongcheng and many other Internet companies have carried out micro-service practice. There are also many microservice development frameworks, such as Dubbo, SpringCloud, thrift, grpc, etc.

2 Problems with microservices landing

Although microservices are in full swing, their implementation is still in the exploratory stage. Many small and medium-sized Internet companies, in view of experience, technical strength and other problems, micro-service landing is more difficult. As noted architect Chris Richardson says, the main challenges are:

1) After a single application is split into a distributed system, the communication mechanism and fault handling measures between processes become more complex.

2) After the system is micro-serviced, a seemingly simple function may need to call multiple services and operate multiple database implementations internally, and the distributed transaction problem of service invocation becomes very prominent.

3) The large number of microservices makes it more difficult to test, deploy and monitor them.

As the RPC framework matures, the first problem has gradually been solved. For example, dubbo can support multiple communication protocols, and springcloud can support restful calls very well. As for the third question, with the development of docker and devops technologies and the launch of automated O & M tools for public cloud paas platforms, the testing, deployment and O & M of microservices will become easier and easier.

As for the second problem, there is no universal solution to the transaction problem generated by microservices. Distributed transactions have become the biggest obstacle to microservice implementation and one of the most challenging technical problems. To this end, this article will discuss various solutions for distributed transactions under the microservice architecture, and focus on interpreting the distributed transaction solution proposed by Alibaba---GTS. The GTS mentioned in this solution is a new generation of distributed transaction Internet middleware that solves microservice problems.

3 SOA Distributed Transaction Solution 3.1 Two-phase commit solution based on XA protocol

Transaction middleware and database use two-phase commit to complete a global transaction through XA interface specification. XA specification is based on two-phase commit protocol.

The first stage is the voting stage, in which all participants send feedback on whether the transaction is successful to the coordinator; the second stage is the execution stage, in which the coordinator notifies all participants to commit or roll back on all branches in unison based on feedback from all participants.

The two-phase commit scheme is widely used, and almost all commercial OLTP databases support the XA protocol. However, the two-phase commit scheme has a long locking time and a great impact on performance, which is basically not suitable for solving microservice transaction problems.

3.2 TCC Programme

TCC schemes have been implemented more in the fields of e-commerce and finance. The TCC scheme is actually an improvement of a two-phase submission. It explicitly divides each branch of the whole business logic into three operations: Try, Confirm and Cancel. The Try part completes the preparation of the business, the confirm part completes the submission of the business, and the cancel part completes the rollback of the transaction. The basic principle is shown below.

At the beginning of a transaction, the business application registers the initiating transaction with the transaction coordinator. Then the business application calls the try interface of all services to complete the first phase of preparation. The transaction coordinator then decides to invoke the confirm interface or cancel interface based on what the try interface returns. If the interface call fails, a retry occurs.

The TCC scheme allows applications to define their own granularity of database operations, making it possible to reduce lock conflicts and improve throughput. Of course, the TCC scheme also has shortcomings, which are concentrated in the following two aspects:

Invasive to applications. Each branch of business logic needs to implement three operations: try, confirm and cancel. The application is more invasive and the transformation cost is high.

It is difficult to realize. Different rollback strategies need to be implemented according to different failure reasons such as network state and system failure. To satisfy consistency requirements, the confirm and cancel interfaces must be idempotent.

For the reasons mentioned above, TCC scheme is mostly adopted by large companies with strong R & D strength and urgent needs. Microservices advocate lightweight and easy deployment of services, while many transaction processing logics in TCC solutions need to be implemented by their own coding, which is complex and requires a large amount of development.

3.3 Message Based Final Consistency Scheme

Message consistency scheme is to ensure consistency of upstream and downstream application data operation through message middleware. The basic idea is to put local operations and message sending into a single transaction, ensuring that local operations and message sending either succeed or fail. The downstream application subscribes to the message system and performs corresponding operations after receiving the message.

A messaging scheme essentially transforms a distributed transaction into two local transactions and then relies on retry mechanisms of downstream businesses to achieve final consistency. The message-based final consistency scheme is also highly invasive to applications, requiring a lot of business transformation and high cost.

At this point, I believe that everyone has a deeper understanding of "what common distributed transaction solutions are available". Let's actually operate them! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

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.