Transaction processing method, device, equipment, storage medium and program product

Abstract

The embodiment of the present application provides a transaction processing method, apparatus, device, storage medium and program product. The transaction processing method is applied to the transaction processing end, and the method includes: obtaining the processing request of the distributed transaction sent by the calling end, and obtaining at least one transaction parameter corresponding to the distributed transaction; determining the processing mode corresponding to the distributed transaction; determining the orchestration strategy of the distributed transaction according to the processing mode and the distributed transaction; generating the processing result of the distributed transaction based on the orchestration strategy and at least one transaction parameter, realizing a non-intrusive distributed transaction processing method, and the user does not need to master the internal mechanism of distributed processing, and can enter the input request and corresponding parameters, which is easy to operate and convenient to use, and the consistency of distributed transactions is realized through the determined processing mode.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of distributed data processing technology, and in particular, to a transaction processing method, apparatus, device, storage medium, and program product. Background Art

[0002] With the rapid development of Internet technology, distributed systems and microservice architectures are becoming popular. Distributed systems require multiple services and database instances to collaborate to complete the same transaction, thereby speeding up transaction processing efficiency and reducing the requirements for service architecture.

[0003] In a distributed system, each node can only know the operation results of this node, but cannot know the operation results of other nodes. When a transaction spans multiple nodes, it is a distributed transaction. In order to ensure the consistency of the distributed transaction, a coordination component needs to be introduced to uniformly manage the operation results of each node, thereby achieving the consistency of the distributed transaction.

[0004] In the prior art, common distributed transaction processing models are the TCC model and the SAGA model. Both models require users to design coordination components by themselves and make large-scale changes to their own systems to adapt to the TCC model or the SAGA model. Distributed transaction processing has high costs and low efficiency and cannot meet the needs. Summary of the invention

[0005] The embodiments of the present application provide a transaction processing method, apparatus, device, storage medium and program product, and provide a non-intrusive distributed transaction consistency processing solution for distributed transactions, so that the caller only needs to input the request and the transaction parameters of the distributed transaction in the request. At the same time, the caller does not need to master the transaction orchestration of the distributed processing model, thereby reducing the processing cost of distributed transactions and improving processing efficiency.

[0006] In a first aspect, an embodiment of the present application provides a transaction processing method, which is applied to a transaction processing end, and the method includes: obtaining a processing request for a distributed transaction sent by a calling end, and obtaining at least one transaction parameter corresponding to the distributed transaction; determining a processing mode corresponding to the distributed transaction; determining an orchestration strategy for the distributed transaction based on the processing mode and the distributed transaction; and generating a processing result of the distributed transaction based on the orchestration strategy and at least one transaction parameter.

[0007] Optionally, determining the processing mode corresponding to the distributed transaction includes: determining the processing mode corresponding to the distributed transaction according to a calling end corresponding to the distributed transaction and / or a transaction type of the distributed transaction.

[0008] Optionally, the processing mode corresponding to the distributed transaction is determined according to the calling end corresponding to the distributed transaction and / or the transaction type of the distributed transaction, including: if the distributed transaction is a flexible transaction, determining that the processing mode corresponding to the distributed transaction is a SAGA mode or a hybrid mode, wherein the hybrid mode includes a TCC mode and a SAGA mode; and / or, if the distributed transaction is a rigid transaction, determining that the processing mode corresponding to the distributed transaction is a TCC mode; and / or, if the distributed transaction is a long transaction, determining that the processing mode corresponding to the distributed transaction is a SAGA mode; and / or, if the distributed transaction is a short transaction, determining that the processing mode corresponding to the distributed transaction is a TCC mode.

[0009] Optionally, determining an orchestration strategy for the distributed transaction according to the processing mode and the distributed transaction includes: determining each branch transaction according to the distributed transaction; and determining the orchestration strategy according to the processing mode and each branch transaction.

[0010] Optionally, determining the orchestration strategy according to the processing mode and each of the branch transactions includes: determining a service process of the distributed transaction and a calling order of each of the branch transactions according to the processing mode and the type of the distributed transaction; and determining the orchestration strategy of the distributed transaction based on the service process and the calling order.

[0011] Optionally, generating a processing result of the distributed transaction based on the orchestration strategy and at least one transaction parameter includes: initializing the orchestration strategy based on the at least one transaction parameter; and executing the initialized orchestration strategy to generate a processing result of the distributed transaction.

[0012] Optionally, executing the orchestration strategy after initialization to generate a processing result of the distributed transaction includes: executing the orchestration strategy after initialization to obtain branch processing results of each branch transaction of the distributed transaction; if the branch processing results of each branch transaction are successful, determining that the processing result of the distributed transaction is successful; if the branch processing result of at least one branch transaction is a failure, restoring each executed branch transaction, and determining that the transaction processing result of the distributed transaction is a failure.

[0013] Optionally, when the processing mode is a hybrid mode, the orchestration strategy after initialization is executed to generate a processing result of the distributed transaction, including: executing each branch transaction based on the try method of the TCC mode, and recording the first branch processing result of each branch transaction; when at least one of the first branch processing results is a failure, executing the cancel method of the TCC mode corresponding to each branch transaction, and determining that the processing result of the distributed transaction is a failure; and / or, when each of the first branch processing results is successful, executing each branch transaction based on the SAGA mode, and recording the second branch processing result of each branch transaction; when at least one of the second branch processing results is a failure, rolling back each branch transaction that has been executed by the SAGA mode to restore each branch transaction, and determining that the processing result of the distributed transaction is a failure; and / or, when each of the second branch processing results is successful, executing the confirm method of the TCC mode corresponding to each branch transaction, and determining that the processing result of the distributed transaction is a success.

[0014] Optionally, initializing the orchestration strategy based on the at least one transaction parameter includes: determining an execution order and a calling parameter of each branch transaction in the orchestration strategy based on the at least one transaction parameter and the processing request.

[0015] Correspondingly, the orchestration strategy after initialization is executed to generate the processing result of the distributed transaction, including: executing each of the branch transactions based on the execution order; for each branch transaction, when the branch transaction needs to be remotely called, remotely calling the corresponding database based on the calling parameters of the branch transaction to generate the branch processing result of the branch transaction; determining the processing result of the distributed transaction according to the branch processing results of each of the branch transactions.

[0016] Optionally, based on the calling parameters of the branch transaction, a corresponding database is remotely called to generate a branch processing result of the branch transaction, including: determining a matching protocol adapter based on the protocol name corresponding to the branch transaction; performing data structure conversion on the calling parameters based on the matching protocol adapter to generate a parameter configuration class; based on the parameter configuration class and the calling algorithm in the matching protocol adapter, accessing the database of the remote server and returning the calling result; parsing the calling result based on the matching protocol adapter to obtain an access result; and generating a branch processing result of the branch transaction based on the access result.

[0017] Optionally, after obtaining the processing request of the distributed transaction sent by the calling end, the method further includes: determining a transaction template according to the processing request; and determining at least one item to be input according to the transaction template.

[0018] Correspondingly, obtaining at least one transaction parameter corresponding to the distributed transaction includes: obtaining each of the transaction parameters corresponding to each of the items to be input.

[0019] In a second aspect, an embodiment of the present application further provides a transaction processing device, which is applied to a transaction processing end, and includes: a request acquisition module, used to obtain a processing request for a distributed transaction sent by a calling end, and to obtain at least one transaction parameter corresponding to the distributed transaction; a mode determination module, used to determine a processing mode corresponding to the distributed transaction; an orchestration module, used to determine an orchestration strategy for the distributed transaction according to the processing mode and the distributed transaction; and a transaction processing module, used to generate a processing result of the distributed transaction based on the orchestration strategy and at least one transaction parameter.

[0020] Optionally, the mode determination module is specifically used to determine the processing mode corresponding to the distributed transaction according to the calling end corresponding to the distributed transaction and / or the transaction type of the distributed transaction.

[0021] Optionally, the mode determination module is specifically used to: if the distributed transaction is a flexible transaction, determine that the processing mode corresponding to the distributed transaction is a SAGA mode or a hybrid mode, wherein the hybrid mode includes a TCC mode and a SAGA mode; and / or, if the distributed transaction is a rigid transaction, determine that the processing mode corresponding to the distributed transaction is a TCC mode; and / or, if the distributed transaction is a long transaction, determine that the processing mode corresponding to the distributed transaction is a SAGA mode; and / or, if the distributed transaction is a short transaction, determine that the processing mode corresponding to the distributed transaction is a TCC mode.

[0022] Optionally, the orchestration module includes: a branch determination unit, used to determine each branch transaction according to the distributed transaction; and an orchestration unit, used to determine the orchestration strategy according to the processing mode and each branch transaction.

[0023] Optionally, the orchestration unit is specifically used to: determine the service process of the distributed transaction and the calling order of each of the branch transactions according to the processing mode and the type of the distributed transaction; and determine the orchestration strategy of the distributed transaction based on the service process and the calling order.

[0024] Optionally, the transaction processing module includes: an initialization unit, used to initialize the orchestration strategy based on the at least one transaction parameter; and a transaction processing unit, used to execute the initialized orchestration strategy to generate a processing result of the distributed transaction.

[0025] Optionally, a transaction processing unit is specifically used to: execute the orchestration strategy after the initialization to obtain branch processing results of each branch transaction of the distributed transaction; if the branch processing results of each branch transaction are successful, determine that the processing result of the distributed transaction is successful; if the branch processing result of at least one branch transaction is a failure, restore the executed branch transactions and determine that the transaction processing result of the distributed transaction is a failure.

[0026] Optionally, when the processing mode is a mixed mode of TCC and SAGA, the transaction processing unit is specifically used to: execute each branch transaction based on the try method of the TCC mode, and record the first branch processing result of each branch transaction; when at least one of the first branch processing results is a failure, execute the cancel method of the TCC mode corresponding to each branch transaction, and determine that the processing result of the distributed transaction is a failure; and / or, when each of the first branch processing results is successful, execute each branch transaction based on the SAGA mode, and record the second branch processing result of each branch transaction; when at least one of the second branch processing results is a failure, roll back each branch transaction executed by the SAGA mode to restore each branch transaction, and determine that the processing result of the distributed transaction is a failure; and / or, when each of the second branch processing results is successful, execute the confirm method of the TCC mode corresponding to each branch transaction, and determine that the processing result of the distributed transaction is a success.

[0027] Optionally, the base orchestration module is specifically configured to determine, based on the at least one transaction parameter and the processing request, an execution order and a calling parameter of each branch transaction in the orchestration strategy.

[0028] Correspondingly, the transaction processing unit includes: an execution subunit, which is used to execute each of the branch transactions based on the execution order; a calling subunit, which is used to remotely call the corresponding database based on the calling parameters of the branch transaction for each branch transaction when the branch transaction needs to be remotely called, so as to generate a branch processing result of the branch transaction; and a processing result determination subunit, which is used to determine the processing result of the distributed transaction according to the branch processing results of each of the branch transactions.

[0029] Optionally, a calling subunit is specifically used to: for each branch transaction, when the branch transaction needs to make a remote call, determine a matching protocol adapter based on the protocol name corresponding to the branch transaction; perform data structure conversion on the calling parameters based on the matching protocol adapter to generate a parameter configuration class; access the database of the remote server based on the parameter configuration class and the calling algorithm in the matching protocol adapter, and return the calling result; parse the calling result based on the matching protocol adapter to obtain an access result; and generate a branch processing result of the branch transaction based on the access result.

[0030] Optionally, the device further includes: a template determination module, which is used to determine a transaction template according to a processing request for a distributed transaction sent by a calling end after obtaining the processing request; and determine at least one item to be input according to the transaction template.

[0031] Correspondingly, the request acquisition module is specifically used to: acquire the processing request of the distributed transaction sent by the calling end, and acquire each of the transaction parameters corresponding to each of the items to be input.

[0032] In a third aspect, an embodiment of the present application also provides a transaction processing device, comprising a memory and at least one processor; the memory stores computer execution instructions; the at least one processor executes the computer execution instructions stored in the memory, so that the at least one processor executes the transaction processing method provided by any embodiment of the present application.

[0033] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, in which computer execution instructions are stored. When the computer execution instructions are executed by a processor, they are used to implement a transaction processing method as provided in any embodiment of the present application.

[0034] In a fifth aspect, an embodiment of the present application further provides a computer program product, including a computer program, which, when executed by a processor, implements a transaction processing method as provided in any embodiment of the present application.

[0035] The embodiments of the present application provide a transaction processing method, apparatus, device, storage medium and program product. When a user initiates a processing request for a distributed transaction at a calling end, the processing mode corresponding to the distributed transaction is automatically determined based on the processing request and various transaction parameters input by the user, and then the orchestration strategy is determined based on the distributed transaction and its processing mode, and then the processing result of the distributed transaction is generated based on the orchestration strategy and various transaction parameters. The user does not need to master the orchestration strategy, but only needs to input the transaction parameters of the distributed transaction to be processed. The operation is simple and convenient, and a non-intrusive distributed transaction processing method is implemented, which reduces development costs and improves the efficiency of distributed transaction processing. At the same time, based on the determined processing mode that matches the distributed transaction, the consistency of distributed transaction processing is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0037] Figure 1 An application scenario diagram of the transaction processing method provided in the embodiment of the present application;

[0038] Figure 2 A schematic diagram of the structure of the coordinator 130 based on Seata design provided in an embodiment of the present application;

[0039] Figure 3 A flowchart of a transaction processing method provided for one embodiment of the present application;

[0040] Figure 4 A flowchart of a transaction processing method provided for another embodiment of the present application;

[0041] Figure 5 For this application Figure 4 The flowchart of step S409 in the illustrated embodiment;

[0042] Figure 6 For this application Figure 4 The flowchart of step S409 in the illustrated embodiment;

[0043] Figure 7 A flowchart of a transaction processing method in a SAGA mode provided by an embodiment of the present application;

[0044] Figure 8 A flowchart of a transaction processing method provided for another embodiment of the present application;

[0045] Fig. 9 For this application Figure 8 The flowchart of step S806 in the illustrated embodiment;

[0046] Fig.10 For this application Figure 8 A schematic diagram of remote calling in the embodiment;

[0047] Fig.11 For this application Figure 8 A schematic diagram of the structure of a transaction processing device corresponding to the SAGA mode in the embodiment shown;

[0048] Fig.12 A schematic diagram of the structure of a transaction processing device provided in one embodiment of the present application;

[0049] Fig.13 A schematic diagram of the structure of a transaction processing device provided for one embodiment of the present application.

[0050] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0051] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0052] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0053] The application scenarios of the embodiments of the present application are explained below:

[0054] Figure 1 An application scenario diagram of the transaction processing method provided in the embodiment of the present application, such as Figure 1 As shown, when the calling end 110 needs to process a distributed transaction, the distributed transaction includes multiple branch transactions, each branch transaction corresponds to an execution unit 120. Figure 1 Taking three execution units 120 as an example, in order to solve the consistency problem of distributed transactions and avoid inconsistent branch transaction data of distributed transactions, it is necessary to design a coordinator 130 to control each branch transaction to obtain consistent distributed transaction processing results.

[0055] In the prior art, the coordinator 130 is often designed based on Seata (Simple Extensible Autonomous Transaction Architecture) to solve the consistency problem of distributed transactions. Figure 2 A schematic diagram of the structure of the coordinator 130 based on Seata design provided in an embodiment of the present application is shown in FIG. Figure 2 The coordinator 130 includes a TM (transaction manager) module, an RM (resource manager) module and a TC (distributed transaction processing coordinator) module. The TC module determines whether to commit or roll back the distributed transaction based on the transaction information submitted by the TM module and the RM module, including the processing results of each branch transaction, so as to achieve consistency in distributed transaction processing.

[0056] However, for the calling end 110, the coordinator 130 designed by Seata requires the developers of the calling end 110 to be familiar with the working principle of Seata, such as the configuration of the state machine, so as to write the corresponding state machine based on the syntax corresponding to the Seata state machine, and master the service orchestration of the coordinator 130, etc., which makes the development difficult and has high requirements for users, resulting in users spending more time writing files related to distributed transaction processing, and the efficiency of distributed transaction processing is low; and Seata only supports single transaction mode, such as TCC mode or SAGA mode. Since different modes are applicable to different types of distributed transactions, the single transaction mode is adopted, resulting in the consistency problem of distributed transactions cannot be effectively solved.

[0057] In order to improve the efficiency and convenience of distributed transaction processing, and at the same time improve the consistency of distributed transactions, an embodiment of the present application provides a transaction processing method, whose main concept is: through the processing request of the distributed transaction and the corresponding transaction parameters, the processing mode adopted is automatically determined, so as to achieve the matching between the mode and the distributed transaction and improve the adaptability of the distributed transaction processing; based on the determined processing mode, the orchestration strategy is determined, and based on the orchestration strategy and the various transaction parameters input by the user, the distributed transaction processing is automatically performed, and consistent processing results are generated, so as to ensure the consistency of the distributed transaction processing. At the same time, the user does not need to master the internal mechanism of the distributed processing, but only needs to initiate a request and input the corresponding transaction parameters. The operation is simple and convenient, and there is no need to develop the corresponding interface on the calling end based on the adopted processing mode, which reduces the development difficulty, realizes a non-intrusive distributed processing method, and improves the efficiency of distributed transaction processing.

[0058] Figure 3 A flowchart of a transaction processing method provided by an embodiment of the present application. The transaction processing method can be applied to a transaction processing end, which can be a transaction processing device, such as Figure 3 As shown, the transaction processing method provided in this embodiment includes the following steps:

[0059] Step S301: obtaining a processing request for a distributed transaction sent by a calling end, and obtaining at least one transaction parameter corresponding to the distributed transaction.

[0060] The calling end is the device corresponding to the user, which can be an ATM (Automated Teller Machine) of a bank, or a mobile terminal, computer or other terminal used by the user. The user initiates a processing request for a distributed transaction through the calling end, and inputs various transaction parameters of the distributed transaction. A distributed transaction includes multiple branch transactions, each of which is processed by a processing node. Transaction parameters may include the transaction amount and account number corresponding to the distributed transaction, and may also include various participants corresponding to the distributed transaction.

[0061] For example, taking the distributed transaction as remittance as an example, customer A needs to handle a third-party remittance business in the banking system, then the transaction parameters of the distributed transaction can be customer A's account, the third-party account and the remittance amount.

[0062] Specifically, the user can initiate a processing request for a distributed transaction in a preset interface of the calling end, and input various transaction parameters corresponding to the distributed transaction, and then the calling end sends the processing request and various transaction parameters to the transaction processing device.

[0063] Furthermore, the processing request and each transaction parameter of the distributed transaction sent by the calling end can be obtained through the user service module of the processing device, and each transaction parameter can be saved in the local database.

[0064] Furthermore, transaction templates corresponding to various distributed transactions can be generated in advance, and the common parameters corresponding to various distributed transactions are stored in the transaction templates. Therefore, when a user initiates a processing request for a distributed transaction, he only needs to provide the transaction parameters of the distributed transaction excluding the common parameters, thereby reducing the user's operations.

[0065] Step S302: determine a processing mode corresponding to the distributed transaction.

[0066] The processing mode is a model used to process distributed transactions to ensure the consistency of distributed transaction data, which can be a TCC mode, a SAGA mode, or a hybrid mode of TCC and SAGA.

[0067] Specifically, the processing mode of the distributed transaction may be determined according to the processing request of the distributed transaction, that is, the user may specify the processing mode adopted by the distributed transaction in the processing request when initiating the processing request.

[0068] Specifically, the processing mode corresponding to the distributed transaction may be determined according to the transaction attributes of the distributed transaction.

[0069] The transaction attributes may include the type of distributed transaction, the number of participants, etc. The type of distributed transaction may be determined by factors such as the consistency requirements of the distributed transaction and the complexity of the transaction process.

[0070] For example, the processing mode of distributed transactions with short transaction processes, certain execution time and high consistency requirements can be the TCC mode, such as remittances, corporate deposits, real-time fund collection, etc.; the processing mode of distributed transactions with long transaction processes and no strong consistency requirements can be the SAGA mode, such as mall orders.

[0071] By setting a variety of optional distributed transaction processing modes, the consistency of distributed transaction data is improved.

[0072] Step S303: determining an orchestration strategy for the distributed transaction according to the processing mode and the distributed transaction.

[0073] The orchestration strategy is used to formulate the processing flow of the distributed transaction, so as to realize the collaboration and interaction between the processing nodes corresponding to the distributed transaction based on the orchestration strategy, so as to complete the distributed transaction.

[0074] Specifically, each processing mode adopts a different service architecture, and different distributed transactions correspond to different transaction processes. Therefore, the orchestration strategy of the distributed transaction can be determined based on the determined processing mode and the type of distributed transaction.

[0075] Specifically, for the TCC mode, the orchestration strategy is mainly divided into two stages. The first stage: based on the try method of the TCC mode, resources are detected and reserved; the second stage: based on the confirm or cancel method, transactions are committed or rolled back. Committing means completing the confirmation of the reserved resources, and rolling back requires releasing the reserved resources. The reserved resources are determined by the transaction parameters of the distributed transaction.

[0076] Specifically, for the SAGA mode, the orchestration strategy mainly includes: determining the execution order of each branch transaction, executing each branch transaction based on the execution order, and when a branch transaction fails, executing the compensation process corresponding to the branch transaction, so as to restore the executed or completed branch transactions, so that the distributed transaction is successful only when all branch transactions are executed successfully, that is, the consistency of distributed transactions is achieved.

[0077] Furthermore, when the processing mode is SAGA mode, it is also necessary to determine the state machine based on the processing request of the distributed transaction and each transaction parameter, start the state machine engine based on the state machine, initiate each branch transaction, and obtain the processing results of each branch transaction.

[0078] Specifically, for distributed transactions of the transfer type, that is, distributed transactions in which customers transfer money to third parties, the transaction process corresponding to the orchestration strategy mainly includes: freezing customer accounts, initiating third-party remittances, unfreezing customer accounts, charging bank accounts, and transferring money from customers to third parties.

[0079] Step S304: Generate a processing result of the distributed transaction based on the orchestration strategy and at least one transaction parameter.

[0080] Specifically, the orchestration strategy can be initialized through various transaction parameters, and then the initialized orchestration strategy is executed to obtain the processing result of the distributed transaction.

[0081] Specifically, based on the transaction parameters, the parameters corresponding to each process node of the orchestration strategy can be determined, and then the orchestration strategy is executed to obtain the processing result of the distributed transaction.

[0082] The transaction processing method provided in the embodiment of the present application, when a user initiates a processing request for a distributed transaction at the calling end, automatically determines the processing mode corresponding to the distributed transaction based on the processing request and various transaction parameters input by the user, and then determines the orchestration strategy based on the distributed transaction and its processing mode, and then generates the processing result of the distributed transaction based on the orchestration strategy and various transaction parameters. The user does not need to master the orchestration strategy, but only needs to input the transaction parameters of the distributed transaction to be processed. The operation is simple and convenient, and a non-intrusive distributed transaction processing method is implemented, which reduces development costs and improves the efficiency of distributed transaction processing. At the same time, based on the determined processing mode that matches the distributed transaction, the consistency of distributed transaction processing is improved.

[0083] Figure 4 A flowchart of a transaction processing method provided by another embodiment of the present application. The transaction processing method provided by this embodiment is Figure 3Based on the embodiment shown, step S302, step S303 and step S304 are further refined, and steps related to determining the transaction template and the items to be input are added after step S301, such as Figure 4 As shown, the transaction processing method provided in this embodiment may include the following steps:

[0084] Step S401, obtaining a distributed transaction processing request sent by the calling end.

[0085] Step S402: determining a transaction template according to the processing request.

[0086] The transaction template can be used to describe the common parameters of the same type of distributed transactions.

[0087] Specifically, the transaction template may be determined based on the transaction type in the processing request of the distributed transaction.

[0088] Specifically, a general transaction template may be established in advance for each type of distributed transaction, and then after obtaining a distributed transaction processing request from the calling end, a matching transaction template may be determined based on the transaction type in the processing request.

[0089] Step S403: determining at least one item to be input according to the transaction template.

[0090] The items to be input are the items in the transaction template that need to be input by the user and whose contents are empty.

[0091] Exemplarily, taking a transfer distributed transaction as an example, the items to be input in the transfer transaction template may include a paying account, a receiving account, and a transfer amount.

[0092] Step S404: Acquire each of the transaction parameters corresponding to each of the items to be input.

[0093] Specifically, each acquired transaction parameter may be matched one-to-one with each item to be input in the transaction template, thereby obtaining a complete transaction template for the distributed transaction.

[0094] By establishing transaction templates, users only need to input a small amount of easily determined transaction parameters, without having to determine the state machine, set various interfaces, and other operations based on the internal mechanism of the adopted processing mode. This simplifies user operations and makes distributed transaction processing more convenient.

[0095] Step S405: determining a processing mode corresponding to the distributed transaction according to the calling end corresponding to the distributed transaction and / or the transaction type of the distributed transaction.

[0096] Specifically, a first correspondence between the calling end of a distributed transaction and / or the transaction type of a distributed transaction and a processing mode may be pre-established, so as to configure a corresponding processing mode for each calling end or each transaction type. Then, based on the first correspondence and the current calling end and / or the transaction type of the distributed transaction, the processing mode of the distributed transaction is determined.

[0097] Optionally, determining a processing mode corresponding to the distributed transaction according to a calling end corresponding to the distributed transaction and / or a transaction type of the distributed transaction includes:

[0098] If the distributed transaction is a flexible transaction, it is determined that the processing mode corresponding to the distributed transaction is a SAGA mode or a hybrid mode, wherein the hybrid mode includes a TCC mode and a SAGA mode; and / or, if the distributed transaction is a rigid transaction, it is determined that the processing mode corresponding to the distributed transaction is a TCC mode; and / or, if the distributed transaction is a long transaction, it is determined that the processing mode corresponding to the distributed transaction is a SAGA mode; and / or, if the distributed transaction is a short transaction, it is determined that the processing mode corresponding to the distributed transaction is a TCC mode.

[0099] Among them, rigid transactions are distributed transactions that follow the ACID principle, that is, they have atomicity, consistency, isolation, and durability, and require strong consistency; flexible transactions are flexible distributed transactions, which follow the BASE (Basically Available) theory and require eventual consistency. Unlike rigid transactions, flexible transactions allow data inconsistency at different nodes within a certain period of time and only require eventual consistency. Long transactions are distributed transactions with more complex transaction processes, such as distributed transactions with a number of process nodes greater than or equal to a preset number. Short transactions are distributed transactions with relatively simple transaction processes, such as distributed transactions with a number of process nodes less than a preset number.

[0100] Specifically, the user can set the transaction type of the distributed transaction in the processing request, such as long transaction type, short transaction type, flexible transaction type, rigid transaction type, etc.

[0101] Step S406: determine each branch transaction according to the distributed transaction.

[0102] Specifically, each branch transaction may be determined based on a transaction template corresponding to the distributed transaction.

[0103] Specifically, each branch transaction may correspond to a processing node or a database, or a branch transaction may correspond to a service.

[0104] For example, taking a distributed transaction of transferring money through a bank as an example, it involves 5 branch transactions, namely 5 services, including payment account freezing service, receiving account initiation remittance service, payment account unfreezing service, bank account charging service and transfer service.

[0105] Step S407: determining the orchestration strategy according to the processing mode and each of the branch transactions.

[0106] Specifically, the service architecture of the distributed transaction can be determined based on the processing mode, and then based on each branch transaction, the execution order and specific process of each branch transaction can be determined to fill the service architecture and obtain the orchestration strategy of the distributed transaction.

[0107] Optionally, determining the orchestration strategy according to the processing mode and each of the branch transactions includes:

[0108] According to the processing mode and the type of the distributed transaction, the service process of the distributed transaction and the calling sequence of each branch transaction are determined; based on the service process and the calling sequence, the orchestration strategy of the distributed transaction is determined.

[0109] The service process may include the required services and the execution order of the services.

[0110] Specifically, the service architecture corresponding to various processing modes can be pre-configured. After the processing mode is determined, the service architecture corresponding to the processing mode is pre-loaded, and then based on the type of distributed transactions, the services corresponding to each branch transaction under the service architecture and their execution order are determined.

[0111] Step S408: Initialize the orchestration strategy based on the at least one transaction parameter.

[0112] Specifically, based on each transaction parameter, the parameters corresponding to each service in the orchestration strategy are initialized.

[0113] Step S409: execute the initialized orchestration strategy to generate a processing result of the distributed transaction.

[0114] Specifically, based on the orchestration strategy after initialization, the processing result of the distributed transaction is successful only after all branch transactions are successfully processed, thereby ensuring the consistency of the distributed transaction data.

[0115] In this embodiment, when the user initiates a processing request for a distributed transaction through the calling end, the matching processing mode is adaptively determined based on the user end and the transaction type of the distributed transaction, thereby improving the accuracy of the processing mode; based on the processing mode and each branch transaction of the distributed transaction that needs to be processed, the orchestration strategy corresponding to the distributed transaction is determined, thereby achieving the consistency of the distributed transaction results by executing the orchestration strategy, that is, when all branch transactions are successfully processed, the distributed transaction is successfully processed, and when at least one branch transaction fails, the distributed transaction fails, and the executed branch transaction is restored, thereby effectively ensuring the data consistency of each branch transaction. In the transaction processing method provided in this embodiment, the user only needs to initiate a processing request and input transaction parameters at the user end, without having to master the internal mechanism of distributed transaction processing, and without having to make major changes to the calling end, the operation is simple and the development cost is low.

[0116] Optional, Figure 5 For this application Figure 4 The flowchart of step S409 in the embodiment shown is as follows: Figure 5 As shown, step S409 may include the following steps:

[0117] Step S4091, executing the initialized orchestration strategy to obtain branch processing results of each branch transaction of the distributed transaction.

[0118] Step S4092: If the branch processing result of each branch transaction is successful, it is determined that the processing result of the distributed transaction is successful.

[0119] Step S4093: If the branch processing result of at least one of the branch transactions is failure, restore each executed branch transaction and determine that the transaction processing result of the distributed transaction is failure.

[0120] Specifically, when any branch transaction in the branch transaction fails, that is, when the branch processing result is a failure, the subsequent part of the orchestration strategy is stopped and the executed branch transactions are restored, so that the branch processing results of all branch transactions and the processing results of distributed transactions are all failures, ensuring the consistency of distributed transaction processing and avoiding inconsistent transaction data.

[0121] Optional, Figure 6 For this application Figure 4 The flowchart of step S409 in the embodiment shown in the figure is for the case where the processing mode is a mixed mode of TCC and SAGA, such as Figure 6 As shown, when the processing mode is a mixed mode of TCC and SAGA, step S409 may include the following steps:

[0122] Step S4094: Execute each branch transaction based on the try method of the TCC mode, and record the first branch processing result of each branch transaction.

[0123] Specifically, the try method of the TCC mode will reserve the intermediate state of the resources corresponding to each branch transaction. After the cancel method of the TCC mode is executed, the reserved resources, that is, the intermediate states, will be released, thereby restoring each branch transaction, that is, the distributed transaction execution fails, and the state before the distributed transaction is executed is maintained, thereby achieving consistency in distributed transaction processing.

[0124] Step S4095: When at least one of the first branch processing results is failure, execute the cancel method of the TCC mode corresponding to each branch transaction, and determine that the processing result of the distributed transaction is failure.

[0125] The first branch processing result is failure, which means that the branch transaction processing fails.

[0126] Step S4096: When the processing results of each of the first branches are successful, each branch transaction is executed based on the SAGA mode, and the second branch processing result of each of the branch transactions is recorded.

[0127] Step S4097, when at least one of the second branch processing results is a failure, roll back each branch transaction that has been executed in the SAGA mode to restore each branch transaction, and determine that the processing result of the distributed transaction is a failure.

[0128] Specifically, each branch transaction that has been executed in the SAGA mode is rolled back, that is, the compensation service of the SAGA mode is executed, so as to restore each branch transaction that has been executed.

[0129] Step S4098, when the processing results of each of the second branches are successful, execute the confirm method of the TCC mode corresponding to each branch transaction, and determine that the processing result of the distributed transaction is successful.

[0130] When all branch transactions in the SAGA mode are successfully processed, the confirm method of the TCC mode is executed to complete the confirmation of each intermediate state or reserved resource, that is, the distributed transaction is completed and the distributed transaction processing is successful, thereby achieving the consistency of distributed transaction processing.

[0131] Optional, Figure 7 A flowchart of a transaction processing method in a SAGA mode provided by an embodiment of the present application is shown as follows: Figure 7 As shown, when the processing mode is the SAGA mode, the transaction processing method of the distributed transaction may include the following steps:

[0132] Step S701: receiving a processing request from the calling end.

[0133] The processing request includes the transaction type and transaction parameters of the distributed transaction.

[0134] Step S702: Generate a state machine based on the distributed transaction type and transaction parameters in the call request.

[0135] Step S703, register the state machine and start the state machine engine.

[0136] Step S704: Execute each service based on the state machine engine.

[0137] Step S705, determine whether the current service is executed successfully, if so, execute step S706; if not, execute step S708.

[0138] Step S706, determine whether there is a next service; if so, return to step S704; if not, execute step S707.

[0139] Step S707, returning the successful processing to the calling end.

[0140] Step S708, executing the compensation service of the executed service in reverse order, and returning the processing failure to the calling end.

[0141] Figure 8 A flowchart of a transaction processing method provided by another embodiment of the present application. The transaction processing method provided by this embodiment is Figure 3 Based on the embodiment shown, step S303 is further refined. This embodiment is aimed at the situation where a branch transaction needs to be remotely called, such as Figure 8 As shown, the transaction processing method provided in this embodiment may include the following steps:

[0142] Step S801: obtaining a processing request for a distributed transaction sent by a calling end, and obtaining at least one transaction parameter corresponding to the distributed transaction.

[0143] The distributed transaction includes multiple branch transactions.

[0144] Step S802: determine the processing mode corresponding to the distributed transaction.

[0145] Step S803: Determine the orchestration strategy according to the processing mode and each branch transaction.

[0146] Step S804: Determine the execution order and calling parameters of each branch transaction in the orchestration strategy based on the at least one transaction parameter and the processing request.

[0147] Step S805: execute each of the branch transactions based on the execution order.

[0148] Step S806: for each branch transaction, when the branch transaction needs to be remotely called, a corresponding database is remotely called based on the calling parameters of the branch transaction to generate a branch processing result of the branch transaction.

[0149] The calling parameters may include calling address, protocol name, calling content and other parameters.

[0150] Specifically, when a branch transaction needs to make a remote call, that is, when the branch transaction needs to call data in a database of a remote server, a connection is established with the remote server based on various call parameters of the branch transaction, and data in its database is called.

[0151] Furthermore, different remote servers may use different protocols, such as custom protocols. Therefore, when a branch transaction needs to make a remote call, the call parameters need to be converted based on the protocol corresponding to the remote server to generate data that can be parsed by the remote server to obtain data in the remote server database.

[0152] Optional, Fig. 9 For this application Figure 8 The flowchart of step S806 in the embodiment shown in FIG. Fig. 9 As shown, step S806 may include the following steps:

[0153] Step S8061: Determine a matching protocol adapter based on the protocol name corresponding to the branch transaction.

[0154] The protocol adapter is an interface used to match the protocol of the remote server.

[0155] Specifically, based on the protocol name corresponding to the branch transaction, the protocol selector may determine a matching protocol adapter based on the protocol name.

[0156] Specifically, the protocol selector may store the correspondence between each protocol name and the protocol adapter, so as to determine the protocol adapter matching the protocol name corresponding to the branch transaction based on the correspondence.

[0157] Step S8062: Perform data structure conversion on the call parameters based on the matched protocol adapter to generate a parameter configuration class.

[0158] Specifically, the protocol adapter may be initialized in advance based on a parameter-free initialization method in the protocol adapter, and then the call parameters may be format-converted based on a remote call algorithm in the protocol adapter, thereby converting the format into the parameter format required by the protocol.

[0159] Specifically, during initialization, the protocol adapter scans all contents within the visible range. If a custom unified interface is detected, the adapter is determined to be a custom protocol adapter, and then the parameterless initialization method corresponding to the protocol adapter is called to initialize it, and the protocol name is extracted as the tag of the custom protocol adapter.

[0160] Specifically, when the protocol selector receives a call request from the processing node corresponding to the branch transaction, it determines the matching protocol adapter based on the protocol name in the call request, that is, selects the protocol adapter whose marked protocol name is the same as the protocol name in the call request, and generates a parameter configuration class based on the conversion of the call parameter data structure by the protocol to access the remote server based on the parameter configuration class.

[0161] Step S8063: Based on the parameter configuration class and the matching calling algorithm in the protocol adapter, access the database of the remote server and return the calling result.

[0162] Specifically, after the format of the calling parameters is converted, the remote server database is accessed based on the generated parameter configuration class and the calling method stored in the protocol adapter to obtain the calling result, and the calling result is returned.

[0163] Step S8064: parse the call result based on the matched protocol adapter to obtain an access result.

[0164] Specifically, the call result is parsed based on the matching protocol adapter to obtain an access result that can be processed by the processing node of the branch transaction.

[0165] For example, Fig.10 For this application Figure 8 A schematic diagram of remote calling in the embodiment is shown in FIG. Fig.10 As shown, when the processing node of the branch transaction needs to make a remote call, the protocol name and call parameters are sent to the protocol selector through a call request. The protocol selector determines the matching protocol adapter based on the protocol name. Fig.10 In the example, three protocol adapters are taken, namely, protocol adapter A, protocol adapter B and protocol adapter C. When the interface of the protocol adapter is a custom protocol unified interface, the protocol adapter is a custom protocol adapter, the protocol adapter is used to convert the format of the call parameters, and the remote server is accessed in combination with the call method to obtain the data in the database of the remote server, and the call result is returned to the protocol adapter, and the call result is parsed by the protocol adapter to obtain the access result that can be processed by the processing node.

[0166] Step S8065: Generate a branch processing result of the branch transaction based on the access result.

[0167] Step S807: Determine the processing result of the distributed transaction according to the branch processing results of each branch transaction.

[0168] For example, Fig.11 For this application Figure 8 The structural diagram of the transaction processing device corresponding to the SAGA mode in the embodiment shown is as follows: Fig.11 As shown, the transaction processing device or distributed transaction middleware (DTC) includes a user service module, a state machine engine and a remote call module. The user initiates a distributed transaction processing request to the DTC through the calling end, and sends various transaction parameters to the DTC. The DTC performs distributed transaction processing based on the processing request and various transaction parameters, and returns the processing result to the calling end. The specific processing process is: based on the user service module, the processing request and various transaction parameters are received, and each transaction parameter is stored in the local database, and a state machine is generated; the local database generates various call parameters based on the distributed transaction and each transaction parameter; based on the state machine, the state machine engine is started, and the remote call module is called through the state machine engine. Based on the remote call module and each call parameter, the service of the processing node of each transaction participant or branch transaction is remotely called to obtain the access result, and the access result is stored in the local database; based on the access result corresponding to each branch transaction, the processing result is obtained; and the processing result is returned to the user (calling end) through the user service module.

[0169] In this embodiment, distributed transactions are processed based on an adaptive processing mode, thereby achieving consistency in distributed transaction processing; when a branch transaction of a distributed transaction needs to be remotely called, data conversion is automatically performed based on a protocol adapter, without the need for the user to modify the calling end based on the adopted protocol, thereby reducing development costs and improving transaction processing efficiency.

[0170] Fig.12 A schematic diagram of the structure of a transaction processing device provided by an embodiment of the present application is shown in FIG. Fig.12 As shown, the transaction processing device provided by this embodiment includes: a request acquisition module 1210, a mode determination module 1220, an orchestration module 1230 and a transaction processing module 1240.

[0171] Among them, the request acquisition module 1210 is used to obtain the processing request of the distributed transaction sent by the calling end, and obtain at least one transaction parameter corresponding to the distributed transaction; the mode determination module 1220 is used to determine the processing mode corresponding to the distributed transaction; the orchestration module 1230 is used to determine the orchestration strategy of the distributed transaction according to the processing mode and the distributed transaction; the transaction processing module 1240 is used to generate the processing result of the distributed transaction based on the orchestration strategy and at least one transaction parameter.

[0172] Optionally, the mode determination module 1220 is specifically used to determine a processing mode corresponding to the distributed transaction according to a calling end corresponding to the distributed transaction and / or a transaction type of the distributed transaction.

[0173] Optionally, the mode determination module 1220 is specifically used to: if the distributed transaction is a flexible transaction, determine that the processing mode corresponding to the distributed transaction is a SAGA mode or a hybrid mode, wherein the hybrid mode includes a TCC mode and a SAGA mode; and / or, if the distributed transaction is a rigid transaction, determine that the processing mode corresponding to the distributed transaction is a TCC mode; and / or, if the distributed transaction is a long transaction, determine that the processing mode corresponding to the distributed transaction is a SAGA mode; and / or, if the distributed transaction is a short transaction, determine that the processing mode corresponding to the distributed transaction is a TCC mode.

[0174] Optionally, the orchestration module 1230 includes: a branch determination unit, configured to determine each branch transaction according to the distributed transaction; and an orchestration unit, configured to determine the orchestration strategy according to the processing mode and each branch transaction.

[0175] Optionally, the orchestration unit is specifically used to: determine the service process of the distributed transaction and the calling order of each of the branch transactions according to the processing mode and the type of the distributed transaction; and determine the orchestration strategy of the distributed transaction based on the service process and the calling order.

[0176] Optionally, the transaction processing module 1240 includes: an initialization unit, configured to initialize the orchestration strategy based on the at least one transaction parameter; and a transaction processing unit, configured to execute the initialized orchestration strategy to generate a processing result of the distributed transaction.

[0177] Optionally, a transaction processing unit is specifically used to: execute the orchestration strategy after the initialization to obtain branch processing results of each branch transaction of the distributed transaction; if the branch processing results of each branch transaction are successful, determine that the processing result of the distributed transaction is successful; if the branch processing result of at least one branch transaction is a failure, restore the executed branch transactions and determine that the transaction processing result of the distributed transaction is a failure.

[0178] Optionally, when the processing mode is a mixed mode of TCC and SAGA, the transaction processing unit is specifically used to: execute each branch transaction based on the try method of the TCC mode, and record the first branch processing result of each branch transaction; when at least one of the first branch processing results is a failure, execute the cancel method of the TCC mode corresponding to each branch transaction, and determine that the processing result of the distributed transaction is a failure; and / or, when each of the first branch processing results is successful, execute each branch transaction based on the SAGA mode, and record the second branch processing result of each branch transaction; when at least one of the second branch processing results is a failure, roll back each branch transaction executed by the SAGA mode to restore each branch transaction, and determine that the processing result of the distributed transaction is a failure; and / or, when each of the second branch processing results is successful, execute the confirm method of the TCC mode corresponding to each branch transaction, and determine that the processing result of the distributed transaction is a success.

[0179] Optionally, the base orchestration module 1230 is specifically configured to determine, based on the at least one transaction parameter and the processing request, an execution order and a calling parameter of each branch transaction in the orchestration strategy.

[0180] Correspondingly, the transaction processing unit includes: an execution subunit, which is used to execute each of the branch transactions based on the execution order; a calling subunit, which is used to remotely call the corresponding database based on the calling parameters of the branch transaction for each branch transaction when the branch transaction needs to be remotely called, so as to generate a branch processing result of the branch transaction; and a processing result determination subunit, which is used to determine the processing result of the distributed transaction according to the branch processing results of each of the branch transactions.

[0181] Optionally, a calling subunit is specifically used to: for each branch transaction, when the branch transaction needs to make a remote call, determine a matching protocol adapter based on the protocol name corresponding to the branch transaction; perform data structure conversion on the calling parameters based on the matching protocol adapter to generate a parameter configuration class; access the database of the remote server based on the parameter configuration class and the calling algorithm in the matching protocol adapter, and return the calling result; parse the calling result based on the matching protocol adapter to obtain an access result; and generate a branch processing result of the branch transaction based on the access result.

[0182] Optionally, the device further includes: a template determination module, which is used to determine a transaction template according to a processing request for a distributed transaction sent by a calling end after obtaining the processing request; and determine at least one item to be input according to the transaction template.

[0183] Correspondingly, the request acquisition module 1210 is specifically used to: acquire the processing request of the distributed transaction sent by the calling end, and acquire each of the transaction parameters corresponding to each of the items to be input.

[0184] The transaction processing device provided in the embodiment of the present application can execute the present application Figure 3-Figure 9 The transaction processing method provided by any corresponding embodiment has the functional modules and beneficial effects corresponding to the execution method.

[0185] Fig.13 A schematic diagram of the structure of a transaction processing device provided in one embodiment of the present application, such as Fig.13 As shown, the transaction processing device includes: a memory 1310, a processor 1320 and a computer program.

[0186] The computer program is stored in the memory 1310 and is configured to be executed by the processor 1320 to implement the present application. Figure 3-Figure 9 The transaction processing method provided by any corresponding embodiment. The transparent transmission device can be the above-mentioned master device or slave device.

[0187] The memory 1310 and the processor 1320 are connected via a bus 1330 .

[0188] For related instructions, please refer to Figure 3-Figure 9 The relevant descriptions and effects corresponding to the steps are understood, and no further elaboration is given here.

[0189] An embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and the computer program is executed by a processor to implement the present application. Figure 3-Figure 9 The transaction processing method provided by any one of the corresponding embodiments.

[0190] Among them, the computer-readable storage medium may be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

[0191] An embodiment of the present application provides a computer program product, including a computer program, which is executed by a processor of a transparent transmission device to control a transaction processing device to implement the present application. Figure 3-Figure 9 The transaction processing method provided by any one of the corresponding embodiments.

[0192] The processor may be an integrated circuit chip having the ability to process signals. The above-mentioned processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc. The disclosed methods, steps and logic block diagrams in the embodiments of the present application may be implemented or executed. The general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0193] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0194] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the disclosure disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the claims.

[0195] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A transaction processing method, characterized in that: The method is applied to a transaction processing end, and the method comprises: Obtaining a processing request for a distributed transaction sent by a calling end, and obtaining at least one transaction parameter corresponding to the distributed transaction; Determine a processing mode corresponding to the distributed transaction; Determining an orchestration strategy for the distributed transaction according to the processing mode and the distributed transaction; Based on the orchestration strategy and at least one transaction parameter, generating a processing result of the distributed transaction; Generating a processing result of the distributed transaction based on the orchestration strategy and at least one transaction parameter, including: initializing the orchestration strategy based on the at least one transaction parameter; Executing the initialized orchestration strategy to generate a processing result of the distributed transaction; When the processing mode is the hybrid mode, executing the initialized orchestration strategy to generate the processing result of the distributed transaction includes: Execute each branch transaction based on the try method of the TCC mode, and record the first branch processing result of each branch transaction; When at least one of the first branch processing results is a failure, executing the cancel method of the TCC mode corresponding to each branch transaction, and determining that the processing result of the distributed transaction is a failure; and / or, When the processing results of each of the first branches are successful, executing each branch transaction based on the SAGA mode, and recording the second branch processing results of each of the branch transactions; When at least one of the second branch processing results in failure, rolling back each branch transaction executed in the SAGA mode to restore each branch transaction, and determining that the processing result of the distributed transaction is failure; and / or, When the processing results of each of the second branches are successful, the confirm method of the TCC mode corresponding to each branch transaction is executed, and it is determined that the processing result of the distributed transaction is successful.

2. The method according to claim 1, characterized in that Determining a processing mode corresponding to the distributed transaction includes: A processing mode corresponding to the distributed transaction is determined according to a calling end corresponding to the distributed transaction and / or a transaction type of the distributed transaction.

3. The method according to claim 2, characterized in that Determining a processing mode corresponding to the distributed transaction according to a calling end corresponding to the distributed transaction and / or a transaction type of the distributed transaction includes: If the distributed transaction is a flexible transaction, determining that the processing mode corresponding to the distributed transaction is a SAGA mode or a hybrid mode, wherein the hybrid mode includes a TCC mode and a SAGA mode; and / or, If the distributed transaction is a rigid transaction, determining that the processing mode corresponding to the distributed transaction is a TCC mode; and / or, If the distributed transaction is a long transaction, determining that the processing mode corresponding to the distributed transaction is a SAGA mode; and / or, If the distributed transaction is a short transaction, it is determined that the processing mode corresponding to the distributed transaction is a TCC mode.

4. The method according to claim 1, characterized in that: Determining an orchestration strategy for the distributed transaction according to the processing mode and the distributed transaction includes: Determine each branch transaction according to the distributed transaction; The orchestration strategy is determined according to the processing mode and each of the branch transactions.

5. The method according to claim 4, characterized in that Determining the orchestration strategy according to the processing mode and each of the branch transactions includes: Determining the service flow of the distributed transaction and the calling order of each branch transaction according to the processing mode and the type of the distributed transaction; Based on the service process and the calling sequence, an orchestration strategy for the distributed transaction is determined.

6. The method according to claim 1, characterized in that Executing the initialized orchestration strategy to generate a processing result of the distributed transaction includes: Executing the initialized orchestration strategy to obtain branch processing results of each branch transaction of the distributed transaction; If the branch processing results of each of the branch transactions are successful, then determining that the processing result of the distributed transaction is successful; If the branch processing result of at least one of the branch transactions is failure, each executed branch transaction is restored, and it is determined that the transaction processing result of the distributed transaction is failure.

7. The method according to claim 1, characterized in that Initializing the orchestration strategy based on the at least one transaction parameter includes: Determining, based on the at least one transaction parameter and the processing request, an execution order and a calling parameter of each branch transaction in the orchestration strategy; Accordingly, executing the initialized orchestration strategy to generate the processing result of the distributed transaction includes: Execute each of the branch transactions based on the execution order; For each branch transaction, when the branch transaction needs to be remotely called, based on the calling parameters of the branch transaction, the corresponding database is remotely called to generate the branch processing result of the branch transaction; The processing result of the distributed transaction is determined according to the branch processing results of each branch transaction.

8. The method according to claim 7, characterized in that Based on the calling parameters of the branch transaction, remotely calling a corresponding database to generate a branch processing result of the branch transaction includes: Determining a matching protocol adapter based on the protocol name corresponding to the branch transaction; Performing data structure conversion on the call parameters based on a matched protocol adapter to generate a parameter configuration class; Based on the parameter configuration class and the matching calling algorithm in the protocol adapter, access the database of the remote server and return the calling result; Parsing the call result based on the matched protocol adapter to obtain an access result; Based on the access result, a branch processing result of the branch transaction is generated.

9. The method according to any one of claims 1 to 8, characterized in that: After obtaining the distributed transaction processing request sent by the calling end, the method further includes: Determining a transaction template according to the processing request; Determining at least one item to be input according to the transaction template; Accordingly, obtaining at least one transaction parameter corresponding to the distributed transaction includes: Obtain each of the transaction parameters corresponding to each of the items to be input.

10. A transaction processing device, characterized in that: The device is applied to a transaction processing end, and comprises: A request acquisition module, used to acquire a processing request for a distributed transaction sent by a calling end, and to acquire at least one transaction parameter corresponding to the distributed transaction; A mode determination module, used to determine a processing mode corresponding to the distributed transaction; An orchestration module, configured to determine an orchestration strategy for the distributed transaction according to the processing mode and the distributed transaction; A transaction processing module, used to generate a processing result of the distributed transaction based on the orchestration strategy and at least one transaction parameter, the transaction processing module comprising an initialization unit and a transaction processing unit; an initialization unit, configured to initialize the orchestration strategy based on the at least one transaction parameter; A transaction processing unit, configured to execute the initialized orchestration strategy and generate a processing result of the distributed transaction; The transaction processing unit is specifically used for: Execute each branch transaction based on the try method of the TCC mode, and record the first branch processing result of each branch transaction; When at least one of the first branch processing results is a failure, executing the cancel method of the TCC mode corresponding to each branch transaction, and determining that the processing result of the distributed transaction is a failure; and / or, When the processing results of each of the first branches are successful, executing each branch transaction based on the SAGA mode, and recording the second branch processing results of each of the branch transactions; When at least one of the second branch processing results in failure, rolling back each branch transaction executed in the SAGA mode to restore each branch transaction, and determining that the processing result of the distributed transaction is failure; and / or, When the processing results of each of the second branches are successful, the confirm method of the TCC mode corresponding to each branch transaction is executed, and it is determined that the processing result of the distributed transaction is successful.

11. A transaction processing device, characterized in that: include: memory and at least one processor; The memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the transaction processing method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions. When the processor executes the computer-executable instructions, the transaction processing method according to any one of claims 1 to 9 is implemented.

13. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the transaction processing method according to any one of claims 1 to 9 is implemented.

Images