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

This article introduces the relevant knowledge of "what is the content of Saga to achieve distributed transactions". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

With the rise of micro-service architecture, more and more companies will encounter the problem of distributed transactions in the actual scenario. Especially in the financial application scenario, several cross-process applications work together to complete a task, which is even more inseparable from the participation of distributed transactions. For distributed transactions, 2PC and TCC are also often mentioned, but in the face of long business processes and it is difficult to transform TCC, we will choose to use Saga distributed transactions. The contents of distributed transactions implemented by Saga include:

Distributed solution of Saga

Saga handles transaction consistency

Saga distributed transaction coordination

Distributed solution of Saga

With the rapid development of the Internet, the original single application has been difficult to support requests with high traffic and high concurrency, so the software system has gradually changed from the original single application to the distributed one. As shown in figure 1, the Web App on the left contains the modules of UI and services. After the transformation, it will correspond to the micro-service architecture on the right, and the services are related to each other.

Figure 1 transition from monolithic to distributed system architecture

After distributed deployment, there will be multiple services to complete a transaction operation together, and these services all exist in different servers or network environments. Services need to collaborate remotely through the network to complete transactions called distributed transactions. For example: bank transfer business, order fastener inventory and so on.

In a distributed transaction scenario, if there is a strong requirement for data consistency, the solution of "two-phase commit" (2PC) will be implemented at the business layer.

TCC (Try Confirm Cancel) mode can be adopted if final consistency is guaranteed. Although TCC's pattern of ensuring ultimate consistency is widely used in the industry, for some distributed transaction scenarios, there are many processes, long processes, and services of other companies may have to be invoked. Especially for uncontrollable services (services of other companies), these services can not follow the TCC development model, resulting in higher development costs of the TCC model. Reflected in the specific scenario, represented by the financial core business (channel layer, product layer, integration layer), its characteristics are: many processes, long processes, invocation of uncontrollable services. At the same time, it is due to the long process, long transaction boundary and long locking time, and the use of TCC mode will affect the concurrency performance.

In view of the distributed transaction processing of this kind of business scenario, the Saga distributed processing mode is proposed. Saga is a "long transaction solution", which is more suitable for the scenario of "long business processes and many business processes". In particular, the services participating in transactions are legacy system services, which can adopt TCC mode if they cannot provide three interfaces under Saga mode.

It is suitable for business scenarios, such as financial institutions docking system (need to connect external systems), channel integration (long process), distributed architecture services, and so on. Its advantages are that one-stage local transactions are committed without locks and high performance; participants can execute asynchronously with high throughput; compensation service is easy to implement because the reverse operation of an update operation is relatively easy to understand; of course, it also has disadvantages, but isolation is not guaranteed.

Saga handles transaction consistency

In 1987, Hector Garcia-Molina and Kenneth Salem of Princeton University published a Paper Sagas about how to deal with long lived transaction. Saga is a collection of long-lived transactions that can be decomposed into sub-transactions that can be staggered. Each of these sub-transactions is a real transaction that maintains database consistency.

In this man's paper, it is mentioned that each Saga consists of a series of sub-transaction Ti. Each Ti has a corresponding compensation action Ci, which is used to undo the results caused by Ti. It can be understood here that each execution action or step for each distributed transaction is a Ti, for example, inventory deduction is T1, creation order is T2, and payment service is T3. Then there is a compensation action Ci for each Ti, such as restore inventory C1, order rollback C2, payment rollback C3.

There are two recovery strategies for Saga transactions:

Forward recovery (forward recovery), that is, "go ahead".

For a failed transaction, an attempt is made to retry the transaction, and there is an assumption that each subtransaction will eventually succeed. This approach is suitable for scenarios that must be successful, as shown in figure 2. In the above illustration, the subtransactions are executed from left to right, followed by T2 after T1 execution, followed by T3, T4, and T5.

Figure 2 Strategy for Saga transaction execution

The order of transaction recovery is also in the direction of T1, T2, T3, T4, T5, and retry T1 if it fails to execute T1, and so on. Therefore, it is called "going forward bravely".

Backward recovery, which compensates for all completed transactions when the execution of a transaction fails, is a way of "going back to the bottom". As shown in figure 2, in the following illustration, the subtransaction is still executed from left to right, and when it is executed to transaction T3, the transaction fails, so the compensation transaction begins to be executed in the direction of the red line, first C3, then C2 and C1. Until the compensation transactions C1, C2 and C3 of T0, T1 and T2 are all executed. That is, the execution result of rolling back the entire Saga.

Saga distributed transaction coordination

The concept and transaction recovery method of Saga are introduced above. There are multiple sub-transactions in each transaction, and each sub-transaction has a compensation transaction, which is used when the transaction is rolled back. Because the operations corresponding to sub-transactions will be deployed in different services in the distributed system architecture, these sub-transactions need to cooperate in order to complete common transactions.

In fact, when a Saga transaction is started, the coordination logic tells the first Saga participant, the child transaction, to execute the local transaction. After the transaction is completed, the Saga invokes the next participating subtransaction of Saga in the order in which it is executed. This process continues until the completion of the Saga transaction.

If the local transaction corresponding to the subtransaction fails during the execution of the subtransaction, Saga executes the compensating transaction in the reverse order. Generally speaking, we refer to the order in which Saga performs transactions as the coordination logic of a Saga. There are two modes of this coordination logic, choreography (Choreography) and control (Orchestration) are as follows:

Choreography: invocation, allocation, decision-making, and sorting between participants (sub-transactions) through the exchange of events. It is a decentralized mode, in which participants communicate through the message mechanism and listen to the messages sent by other participants by the way of listeners, so as to perform the subsequent logical processing. Since there is no intermediate coordination point, we rely on participation to coordinate with each other.

Orchestration: Saga provides a control class that facilitates previous coordination among participants. The command executed by the transaction is initiated from the control class and requests the participants of the Saga in logical order, and after receiving feedback from the participants, the control class initiates calls to other participants. All Saga participants communicate and coordinate around this control class.

Let's introduce these two coordination modes through an example. Suppose there is a business that issues an order, which starts from the order creation operation of the order service, and then invokes the payment order in the payment service, the deduction of inventory in the inventory service and the delivery operation in the shipping service. Finally, if the operation (sub-transaction) in all the participants (service) is completed, the entire order transaction is completed.

Choreography, which is coordinated by sending messages because there is no central control class involved in coordinating the operations of the participants.

As shown in figure 3:

Figure 3 orchestration mode-transaction execution succeeded

1. The create order operation is performed in the order Service, and a create order message is sent to the queue.

two。 The payment Service listens to the order message in the queue, invokes the payment order operation, and sends a service-only message to the queue.

3. After listening to the "payment message", the "inventory service" processes the "inventory deduction" and sends the "inventory deduction message" for the next consumer to accept.

4. As the last sub-transaction of the whole transaction, the Shipping Service will execute the shipping subtransaction after receiving the inventory deduction message, and send the Shipping message to the order Service after completing the transaction. after receiving the message, the order service completes the whole transaction closed loop and commits.

The above is about the successful execution of the transaction. what should be done if the transaction fails?

As shown in figure 4:

Figure 4 orchestration mode-transaction execution failed

1. Suppose that the sub-transaction fails while performing the Shipping, and a Shipping failure message is sent.

two。 After receiving the "Shipping failure message", the inventory service performs a "rollback inventory" operation, which adds back the original deducted inventory and sends a "deduction failure message".

3. After receiving the deduction failure message, the payment service performs a "rollback payment", carries out a refund operation, and sends a "payment failure message". The order service marks the order transaction as failed after receiving the message.

The benefits of choreography can be seen from the above description:

Simple: each sub-transaction only needs to publish event messages when operating, and other sub-transactions listen for processing.

Loose coupling: participants (services) communicate with each other through subscription events, making the composition more flexible.

Of course, there are some disadvantages:

Difficult to understand: there is no complete description of the business process, and you need to read the code to understand the execution of the entire transaction. Make it more difficult for developers to understand and maintain the code.

There is a circular dependency on the service: as a result of communicating through messages and events, there will be circular dependencies among participants. That is, A service invokes B service, and B service invokes A service. This also increases the complexity of the architecture design, which needs to be carefully considered at the beginning of the design.

Tightly coupled risk: the method performed by each participant depends on the messages sent by the participant in the previous step, but all the messages of the participant in the previous step need to be subscribed in order to understand the true state of the participant, virtually increasing the coupling of the two services.

Orchestration, the core of which is to define a control class that tells the participant (service) what operations (sub-transactions) should be performed. The Saga control class interacts with participants through commands and asynchronous responses.

As shown in figure 5:

Figure 5 Control Mode-success

1. When the order service executes the order transaction, it sends a request command to the Saga coordinator, and after receiving the command, the Saga coordinator invokes the methods in the service in the order in which the child transactions are executed.

two。 At first, the "payment order" operation is executed, the "payment order" operation in the "payment service" is invoked, and the execution result "payment complete" is returned through the part of the dotted line.

3. Next, execute the "inventory deduction" method in the inventory service, and also return the deduction completed message to the "request feedback" module through the dotted line.

4. This is followed by the execution of the Shipping command, invoking the Shipping method in the Shipping Service, and returning the Shipping complete response.

5. Finally, after the execution of the three sub-transactions, the order service is returned to complete the entire distributed transaction.

After the successful completion of the transaction, let's take a look at the exception.

As shown in figure 6:

Figure 6 Control Mode-failed

1. When the Shipping command is executed, the Shipping failure is found, and the Shipping Service feeds back to the Saga coordinator.

two。 At this point, the coordinator invokes the Roll back inventory operation in the inventory Service to restore the deducted inventory.

3. Then call Roll back payment in the payment Service to complete the payment refund.

4. Finally, notify the order service that the transaction failed.

It should be pointed out that the control mode is also event-driven, and like the orchestration mode, it sends messages to inform participants to execute commands, and the execution and invocation of commands in the above two figures are also done through messages.

Advantages of controller design:

Avoid circular dependencies: there are circular calls between participants in orchestration mode, which can be avoided by centrally controlling the class.

Reduce complexity: all transactions are handed over to the controller, which is responsible for the execution of commands and reply processing, participants only need to complete their own tasks, do not need to consider the way to deal with messages, and reduce the complexity of participant access.

Easy to test: testing focuses on centralized control classes, while other services can test functions separately.

Easy to extend: if a transaction needs to add new steps, simply modify the control class to keep the transaction complexity linear and rollback easier to manage.

Of course, this approach also has its disadvantages:

Dependent controller: the risk of concentrating too much logic in the controller.

Increase the difficulty of management: this model not only manages various business services, but also requires additional management control services, which virtually increases the difficulty and complexity of management. And there is a single point of risk, once something goes wrong with the controller, the whole business is paralyzed.

Summary

Here is a summary of Saga. First of all, Saga is a solution for distributed long-live transactions, aiming at the chief, multiple and complex situations, especially the uncontrollability of services developed by multiple companies, and Saga mode can be used for distributed transaction processing. Saga adopts forward recovery strategy and backward recovery strategy in dealing with transaction consistency. The former ensures the completion of the transaction by constantly retrying, while the latter makes the transaction mark fail by rolling back the transaction one by one by compensating the transaction. In terms of distributed coordination, Saga adopts two modes: orchestration and control. The former allows participants (services) to communicate through messages and starts the execution process of the transaction according to the event, which is a decentralized mode. The latter handles the execution and rollback steps of the transaction through the central control class, uniformly invokes the service and receives feedback from the service.

This is the end of the content of "what is the content of Saga to implement distributed transactions". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.