CN115269128A

CN115269128A - Distributed transaction processing method, device, equipment and storage medium

Info

Publication number: CN115269128A
Application number: CN202210905320.6A
Authority: CN
Inventors: 唐晓东; 谢永恒; 火一莽
Original assignee: Beijing Ruian Technology Co Ltd
Current assignee: Beijing Ruian Technology Co Ltd
Priority date: 2022-07-29
Filing date: 2022-07-29
Publication date: 2022-11-01

Abstract

The invention discloses a distributed transaction processing method, a distributed transaction processing device, distributed transaction processing equipment and a storage medium. The method comprises the following steps: sending a preparation instruction to at least one resource manager associated with the to-be-processed transaction, wherein the preparation instruction is used for indicating the resource manager to perform pre-execution on the operation in the to-be-processed transaction; the preparation instruction comprises the operation matched with the resource manager in the transaction to be processed; determining an execution decision of the transaction to be processed according to the operation type of each operation in the transaction to be processed and a pre-execution result fed back by the resource manager; sending the execution decision to a resource manager for instructing the resource manager to execute a corresponding operation according to the execution decision; and responding to the operation execution completion message fed back by the resource manager, and executing the to-be-processed transaction according to the execution decision. The technical scheme of the embodiment of the invention can realize the balance between the fault tolerance and the consistency in the process of distributed transaction processing.

Description

Distributed transaction processing method, device, equipment and storage medium

Technical Field

The present invention relates to the field of data processing technologies, and in particular, to a method, an apparatus, a device, and a storage medium for processing a distributed transaction.

Background

With the development of society and economy, the business requirements of the internet software system are increasing day by day, and the performance requirements of business transaction processing are difficult to meet by a centralized database system. The distributed database system is a database system constructed on a distributed cluster, and the expansion of transaction processing performance is realized by dividing data into a plurality of nodes.

When a transaction involves multiple nodes, the transaction is a distributed transaction. A distributed transaction is completed by multiple small operations that are distributed among different nodes. These small operations may include retrieving messages from a message queue, storing messages in a Sql Server database, and removing existing message references from an Oracle Server database, etc.

Since the distributed transaction execution process needs to cross database resources, atomicity (Atomicity), consistency (Consistency), isolation (Isolation), and persistence (dual), referred to as ACID, of the distributed transaction need to be guaranteed. However, the forced meeting of the ACID characteristic can lead to poor fault tolerance of the distributed transaction processing system, and how to achieve a new balance between fault tolerance and strong consistency is very important for transaction processing.

Disclosure of Invention

The invention provides a distributed transaction processing method, a distributed transaction processing device, a distributed transaction processing equipment and a storage medium, which can realize the balance between fault tolerance and consistency in the process of processing distributed transactions.

According to an aspect of the present invention, a method for processing a distributed transaction is provided, which includes:

sending a preparation instruction to at least one resource manager associated with the to-be-processed transaction, wherein the preparation instruction is used for indicating the resource manager to perform pre-execution on the operation in the to-be-processed transaction; the preparation instruction comprises the operation matched with the resource manager in the transaction to be processed;

determining an execution decision of the transaction to be processed according to the operation type of each operation in the transaction to be processed and a pre-execution result fed back by the resource manager;

sending the execution decision to the resource manager, so as to instruct the resource manager to execute the corresponding operation according to the execution decision;

and responding to the operation execution completion message fed back by the resource manager, and executing the to-be-processed transaction according to the execution decision.

According to another aspect of the present invention, there is provided a distributed transaction processing apparatus, including:

the system comprises a preparation instruction sending module, a transaction processing module and a transaction processing module, wherein the preparation instruction sending module is used for sending a preparation instruction to at least one resource manager associated with a to-be-processed transaction, and the preparation instruction is used for indicating the resource manager to pre-execute an operation in the to-be-processed transaction; the preparation instruction comprises the operation matched with the resource manager in the transaction to be processed;

the execution decision determining module is used for determining an execution decision of the to-be-processed transaction according to the operation type of each operation in the to-be-processed transaction and a pre-execution result fed back by the resource manager;

an execution decision sending module, configured to send the execution decision to the resource manager, and instruct the resource manager to execute a corresponding operation according to the execution decision;

and the transaction processing module is used for responding to the operation execution completion message fed back by the resource manager and executing the to-be-processed transaction according to the execution decision.

According to another aspect of the present invention, there is provided an electronic apparatus including:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores a computer program executable by the at least one processor, the computer program being executable by the at least one processor to enable the at least one processor to perform a method of processing a distributed transaction according to any of the embodiments of the present invention.

According to another aspect of the present invention, there is provided a computer-readable storage medium storing computer instructions for causing a processor to implement a distributed transaction processing method according to any one of the embodiments of the present invention when the computer instructions are executed.

According to the technical scheme of the embodiment of the invention, a preparation instruction is sent to at least one resource manager associated with the to-be-processed transaction, the execution decision of the to-be-processed transaction is further determined according to the pre-execution result fed back by the resource manager, the execution decision is further sent to the resource manager for instructing the resource manager to execute the corresponding operation according to the execution decision, the operation execution completion message fed back by the resource manager is finally responded, the to-be-processed transaction is executed according to the execution decision, and the balance between fault tolerance and consistency can be realized in the distributed transaction processing process.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present invention, nor do they necessarily limit the scope of the invention. Other features of the present invention will become apparent from the following description.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

Fig. 1 is a flowchart of a processing method of a distributed transaction according to an embodiment of the present invention;

fig. 2 is a flowchart of a distributed transaction processing method according to a second embodiment of the present invention;

fig. 3 is a schematic structural diagram of a distributed transaction processing apparatus according to a third embodiment of the present invention;

fig. 4 is a schematic structural diagram of an electronic device implementing the distributed transaction processing method according to the embodiment of the present invention.

Detailed Description

In order to make those skilled in the art better understand the technical solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Example one

Fig. 1 is a flowchart of an embodiment of the present invention, which provides a method for processing a distributed transaction, where this embodiment is applicable to a case of performing a two-phase protocol commit on a distributed transaction, and the method may be executed by a processing apparatus of the distributed transaction, where the processing apparatus of the distributed transaction may be implemented in the form of hardware and/or software, and the processing apparatus of the distributed transaction may be configured in various general-purpose computing devices. As shown in fig. 1, the method includes:

s110, sending a preparation instruction to at least one resource manager associated with the to-be-processed transaction, wherein the preparation instruction is used for instructing the resource manager to perform pre-execution on the operation in the to-be-processed transaction; the preparation instruction comprises the operation matched with the resource manager in the transaction to be processed.

The processing system of the distributed transaction comprises a transaction manager, a resource manager, a transaction memory and a transaction restorer. The transaction manager serves as a coordinator, after the to-be-processed transaction is obtained, the to-be-processed transaction is split into a plurality of operations, and then the operations are respectively sent to the resource managers serving as participants to be processed. The transaction manager may call the transactional memory to perform a transaction persistence operation during the transaction execution process, and specifically, may record a log during the transaction execution process. In case of failure in the transaction processing process, the transaction restorer can call the transaction memory to acquire the transaction of the terminal, and then the transaction is restored.

Wherein the transaction manager runs in a master business service container and the resource manager runs in a slave business service container. The transaction to be processed initiated by the user is first sent to the main service container, and after relevant processing is performed in the main service container, the transaction to be processed is transferred to the slave service container through Remote Procedure Call (RPC), and relevant operations in the transaction to be processed are processed in the slave service.

In the embodiment of the present invention, after acquiring a to-be-processed transaction, a transaction manager first splits the to-be-processed transaction into a plurality of operations, and further sends a preparation instruction to a plurality of resource managers, where the preparation instruction includes an operation to be executed by a current resource manager, and is used to instruct the resource managers to execute a corresponding operation.

Illustratively, after acquiring a to-be-processed transaction of goods transfer, the transaction manager splits the transaction into an operation 1 of extracting goods from the warehouse a (i.e., reducing the number of goods in the warehouse a), an operation 2 of transferring goods to the warehouse B (i.e., increasing the number of goods in the warehouse B), and an operation 3 of sending a short message to the warehouse manager. Further, the operation 1, the operation 2 and the operation 3 are respectively sent to the resource manager 1, the resource manager 2 and the resource manager 3 to instruct the resource managers 1, 2 and 3 to respectively perform pre-execution on the operations 1, 2 and 3, that is, the number of goods is reduced in the database corresponding to the warehouse a, the number of goods is increased in the database corresponding to the warehouse B, and the short message is edited according to the goods transfer information.

S120, determining an execution decision of the to-be-processed transaction according to the operation type of each operation in the to-be-processed transaction and the pre-execution result fed back by the resource manager.

The operation types may be preset for a plurality of operations included in the transaction to be processed, and specifically, the operation types may be divided into a main operation and a branch operation. Illustratively, the pending transaction of the cargo transfer includes an operation 1 of extracting the cargo from the warehouse a, an operation 2 of transferring the cargo to the warehouse B, and an operation 3 of sending a short message to the warehouse manager. Wherein operations 1 and 2 determine whether the transaction for transferring the goods is successfully executed and thus belong to the main operation, while operation 3 is a subsequent operation for transferring the goods and is not determinative of whether the transaction for transferring the goods is successfully executed and thus belongs to the branch operation.

In the embodiment of the invention, after receiving the preparation instruction, the resource manager performs pre-execution on the operation contained in the preparation instruction, and feeds back the pre-execution result to the transaction manager. The transaction manager may determine an execution decision of the to-be-processed transaction according to the operation type of each operation in the to-be-processed transaction and the pre-execution result fed back by each resource manager.

Specifically, after receiving the preparation instruction, the resource manager performs pre-execution on operations included in the execution preparation instruction, including operations of writing data into the database or operations of rolling back in the case of write failure. Meanwhile, undo information and Redo information can be written into the log. Further, the resource manager feeds back the pre-execution result to the transaction manager, for example, feeding back an "agree" message when the data write operation is successful, and feeding back an "terminate" message when the data write operation is failed and a rollback operation is performed.

And after receiving the pre-execution results fed back by all the resource managers, the transaction manager determines the execution decision of the transaction to be executed according to the pre-execution results and the operation types of all the operations. Specifically, whether the pre-execution results fed back by the resource manager are successful or not is judged, that is, whether the pre-execution results fed back by the resource manager are 'consent' messages or not is judged; if yes, determining that the execution decision of the transaction to be processed is submission; if not, whether the operation associated with the resource manager feeding back the termination message is the main operation needs to be further judged, if so, the execution decision of the to-be-processed transaction is determined to be rollback, and if not, the execution decision of the to-be-processed transaction is determined to be submission.

In the prior art, the decision result of the to-be-processed transaction can be determined as submission only when all participants feedback the "agreement" message, and the decision result of the to-be-processed transaction is determined as rollback if one or more participants feedback the "termination". Compared with the prior art, the scheme provides a scheme for jointly determining the execution decision of the to-be-processed transaction according to the operation type of each operation in the to-be-processed transaction and the pre-execution result fed back by the resource manager, namely, the whole to-be-processed transaction is rolled back only when the pre-execution of the main operation in the to-be-processed transaction fails, otherwise, the transaction is continuously submitted, and the system compatibility can be improved while the consistency of the to-be-processed transaction is ensured.

Optionally, before determining an execution decision of the to-be-processed transaction according to the operation type of each operation in the to-be-processed transaction and the pre-execution result fed back by the resource manager, the method further includes:

modifying the state of the associated operation of the resource manager according to the pre-execution result fed back by the resource manager;

and repeatedly sending a preparation instruction to the resource manager when the pre-execution result is abnormal and the repeated execution number does not exceed the repeated number threshold.

In this optional embodiment, a specific step before determining an execution decision of the to-be-processed transaction according to the operation type of each operation in the to-be-processed transaction and the pre-execution result fed back by the resource manager is provided: after receiving the preparation instruction, the resource manager first pre-executes an operation corresponding to the preparation instruction, for example, an operation of writing data into a database. In case of failure of either the completion operation or the execution operation, the pre-execution result is fed back to the transaction manager. When a fault occurs in the operation executing process, the resource manager performs Rollback operation on the transaction through the compensatable interceptor and feeds back a pre-execution result to the transaction manager as termination, wherein the resource manager completes Rollback through a Rollback method, the Rollback method firstly obtains the current operation state, sets the operation state as cancel, further records an execution log of the operation, and judges whether asynchronous Rollback is required. Upon receipt of the termination message, the transaction manager may modify the state of the operations associated with the resource manager to a "canceled" state. Further, the transaction manager determines whether the number of times of execution of the operation exceeds a threshold number of times of repetition, for example, 3 times, and if not, repeatedly sends a preparation instruction to the resource manager so that the resource manager can repeatedly execute the operation. If the pre-execution is successful for more than 3 times, the preparation instruction is not re-initiated.

S130, sending the execution decision to the resource manager for instructing the resource manager to execute the corresponding operation according to the execution decision.

In the embodiment of the invention, after the execution decision of the to-be-processed transaction is determined, the execution decision is sent to each resource manager, so that each resource manager executes corresponding operation according to the execution decision. In particular, the execution decision includes a commit and a rollback. And after receiving the submission instruction, each resource manager carries out formal submission on the operation matched with the submission instruction. After receiving the rollback instruction, each resource manager performs rollback on the respective matched operation, specifically, may perform rollback by using Undo information recorded in the log in the preprocessing process.

S140, responding to the operation execution completion message fed back by the resource manager, and executing the to-be-processed transaction according to the execution decision.

In the embodiment of the invention, the resource manager feeds back a completion message to the transaction manager after the resource manager executes the corresponding operation according to the execution decision issued by the transaction manager. And after receiving the completion message, the resource manager performs final submission or rollback operation on the to-be-processed transaction according to the execution decision.

In one specific example, the transaction manager initiates a root transaction after receiving an execution complete message fed back by all resource managers. Specifically, a ROOT transaction is created by calling a Beginroot method, the state of the transaction is set to be TRYING, the type of the transaction is set to be ROOT, then a transaction memory is called to store the transaction to an external storage, and then a savetranslation method is called to store the attribute information of the transaction to a thread cache set.

According to the technical scheme of the embodiment of the invention, a preparation instruction is sent to at least one resource manager associated with the to-be-processed transaction, the execution decision of the to-be-processed transaction is further determined according to the operation type of each operation in the to-be-processed transaction and the pre-execution result fed back by the resource manager, the execution decision is further sent to the resource manager for instructing the resource manager to execute the corresponding operation according to the execution decision, the operation execution completion message fed back by the resource manager is finally responded, the to-be-processed transaction is executed according to the execution decision, and the balance between fault tolerance and consistency can be realized in the distributed transaction processing process.

Example two

Fig. 2 is a flowchart of a distributed transaction processing method according to a second embodiment of the present invention, and this embodiment further provides specific steps of determining an execution decision of a to-be-processed transaction according to an operation type of each operation in the to-be-processed transaction and a pre-execution result fed back by a resource manager, based on the above embodiment. As shown in fig. 2, the method includes:

s210, sending a preparation instruction to at least one resource manager associated with the to-be-processed transaction, wherein the preparation instruction is used for instructing the resource manager to perform pre-execution on the operation in the to-be-processed transaction; the preparation instruction comprises the operation matched with the resource manager in the transaction to be processed.

S220, determining whether the pre-execution result fed back by at least one resource manager contains an abnormal result.

In the embodiment of the invention, after the transaction manager receives the pre-execution result fed back by at least one resource manager, whether the pre-execution result fed back by one or more resource managers is an abnormal result is judged, so as to determine whether to continue to execute the commit operation of the current to-be-processed transaction according to the pre-execution result.

And S230, determining the operation type associated with the abnormal result under the condition that the abnormal result is contained.

In the embodiment of the present invention, if the pre-execution result fed back by one or more resource managers is an abnormal result, the operation type of the operation associated with the abnormal result needs to be determined. For example, if the resource manager 1 and the resource manager 2 feedback an abnormal result, it needs to determine whether the operation corresponding to the resource managers 1 and 2 is a main operation. The main operation is a key operation included in the current to-be-processed transaction and used for determining whether the transaction processing is successful, the branch operation is a branch in the to-be-processed transaction, and the failure of the branch operation cannot cause the failure of the whole to-be-processed transaction. For example, the to-be-processed transaction is an order-placing transaction, and the order-placing transaction includes three operations of commodity ex-warehouse, order production, order printing and short message sending, wherein the commodity ex-warehouse and the order production operation determine whether the transaction is successful and belong to a main operation, and the order printing and the short message sending belong to an additional operation in the transaction, which cannot play a decisive role in whether the transaction is successfully executed, and thus belong to a branch operation.

S240, determining that the execution decision of the transaction to be processed is a commit under the condition that the operation types related to the abnormal result are all branch operations.

In the embodiment of the present invention, in order to improve the fault tolerance and the transaction processing efficiency of the transaction when the operation types associated with the abnormal result are all branch operations, it may be determined that the execution decision of the to-be-processed transaction is commit. That is, in the case where only the branch operation handles the exception, the continued commit of the current pending transaction is not affected, and the incomplete branch operation can be subsequently compensated by the transaction compensation mechanism.

And S250, under the condition of the operation type main operation associated with the abnormal result, determining that the decision of the transaction to be processed is rollback.

In the embodiment of the present invention, if the pre-execution result fed back by one or more resource managers is an abnormal result, and the operation associated with the abnormal takeover includes a main operation, it may be determined that the decision of the to-be-processed transaction is rollback. The failure of the main operation executing process determines that the processing result of the to-be-processed transaction is failure, so that the pre-executed operations of all the resource managers need to be rolled back.

And S260, sending the execution decision to a resource manager for instructing the resource manager to execute the corresponding operation according to the execution decision.

And S270, responding to the operation execution completion message fed back by the resource manager, and executing the to-be-processed transaction according to the execution decision.

Optionally, executing the to-be-processed transaction according to the execution decision includes:

submitting the operation contained in the transaction to be processed under the condition that the execution decision is submission;

storing a transaction log in the submission process of the transaction into an external storage space by calling a transaction memory;

storing the attribute information of the transaction to be processed to a thread cache set; the attribute information includes the operation contained in the transaction to be processed, the execution state of the operation, and whether the operation belongs to the core operation.

In this optional embodiment, when the execution decision is commit, after receiving an operation execution completion message sent by the resource manager that agrees to commit, the transaction manager may commit an operation included in the transaction to be processed. In the process of committing, the transaction manager calls the transaction memory to store the transaction log in the process of committing the transaction into an external storage space, and then the transaction to be processed can be recovered according to the log associated with the incomplete branch transaction. In addition, the transaction manager stores attribute information of the pending transaction in the thread cache set, where the attribute information includes an identifier of an operation included in the pending transaction, an execution state of the operation, and whether the operation is a main operation in the pending transaction.

Optionally, after the transaction log in the commit process of the transaction is stored in the external storage space by calling the transaction memory, the method further includes:

reading an abnormal log of the operation from a transaction log of an external storage space;

and sending the abnormal log to a compensation processing service through the message queue, wherein the compensation processing service is used for indicating the compensation processing service to perform compensation processing on the operation associated with the abnormal log.

In this optional embodiment, when a branch transaction of the to-be-processed transaction fails, the to-be-processed transaction is still submitted. Therefore, after committing the operation included in the transaction to be processed, compensation needs to be performed for the branch transaction that is not completed in the transaction to be processed. Specifically, the transaction manager sends the exception log to the compensation processing service through the message queue, and the exception log is used for instructing the compensation processing service to perform compensation processing on an operation associated with the exception log.

In a specific example, the to-be-processed transaction is an order-placing transaction, and the order-placing transaction includes three operations of commodity warehouse-out, order production, order printing and short message sending, wherein the commodity warehouse-out and order production operations belong to main operations, and the order printing and short message sending belong to branch operations. The transaction manager will also continue to commit the pending transaction if only the order print operation feeds back an abnormal result. Therefore, the transaction manager is required to send the exception log of the order printing operation to the compensation processing service through the message queue for instructing the compensation processing service to perform compensation processing on the order printing operation.

Optionally, executing the to-be-processed transaction according to the execution decision further includes:

and rolling back the operation contained in the transaction to be processed according to the prestored operation image file under the condition that the execution decision is rolling back.

In this optional embodiment, when the execution decision is rollback, the transaction manager needs to rollback each operation of the to-be-processed transaction according to the operation image file associated with each operation stored in advance, so as to ensure consistency of the distributed transactions. The operation image files comprise image files before and after execution of each operation.

It is worth noting that the operation completion degree can be judged before rollback, if the operation completion degree exceeds a set threshold value, namely only a small amount of incomplete operation remains, an error can be reported, so that a manager can manually eliminate the abnormal fault, and the transaction processing efficiency can be improved compared with direct rollback; if the operation completion does not exceed the set threshold, the transaction may be suspended.

Optionally, after rolling back the operation included in the transaction to be processed, the method further includes:

judging whether the recovery times of the to-be-processed transaction reach a recovery time threshold value or not;

and under the condition that the recovery times do not reach the threshold of the recovery times, sending a preparation instruction to at least one resource manager associated with the to-be-processed transaction again for performing recovery operation on the to-be-processed transaction.

In this optional embodiment, after rolling back the to-be-processed transaction, the transaction manager may determine whether the recovery frequency of the to-be-processed transaction reaches the set recovery frequency threshold, and if not, send a preparation instruction to at least one resource manager associated with the to-be-processed transaction again to perform a recovery operation on the to-be-processed transaction. Specifically, the transaction manager increases the retry number of the transaction, then determines the status of the transaction to be processed, commits the transaction if the status of the transaction is recovering, rolls back the transaction if the status of the transaction is delete or tries to delete, and finally calls the transaction memory to delete the transaction log.

EXAMPLE III

Fig. 3 is a schematic structural diagram of a distributed transaction processing apparatus according to a third embodiment of the present invention. As shown in fig. 3, the apparatus includes:

a preparation instruction sending module 310, configured to send a preparation instruction to at least one resource manager associated with a to-be-processed transaction, where the preparation instruction is used to instruct the resource manager to perform pre-execution on an operation in the to-be-processed transaction; the preparation instruction comprises the operation matched with the resource manager in the transaction to be processed;

an execution decision determining module 320, configured to determine an execution decision of the to-be-processed transaction according to an operation type of each operation in the to-be-processed transaction and a pre-execution result fed back by the resource manager;

an execution decision sending module 330, configured to send the execution decision to the resource manager, and instruct the resource manager to execute a corresponding operation according to the execution decision;

the transaction processing module 340 is configured to respond to the operation execution completion message fed back by the resource manager, and execute the to-be-processed transaction according to the execution decision.

According to the technical scheme, the preparation instruction is sent to at least one resource manager associated with the to-be-processed transaction, the execution decision of the to-be-processed transaction is further determined according to the operation type of each operation in the to-be-processed transaction and the pre-execution result fed back by the resource manager, the execution decision is further sent to the resource manager and used for indicating the resource manager to execute the corresponding operation according to the execution decision, the operation execution completion message fed back by the resource manager is finally responded, the to-be-processed transaction is executed according to the execution decision, and balance between fault tolerance and consistency can be achieved in the distributed transaction processing process.

Optionally, the decision determining module 320 is specifically configured to:

determining whether the pre-execution result fed back by at least one resource manager contains an abnormal result;

determining an operation type associated with an abnormal result under the condition of containing the abnormal result;

determining that the execution decision of the transaction to be processed is a commit under the condition that the operation types associated with the abnormal results are all branch operations;

and determining that the decision of the to-be-processed transaction is rollback under the condition of the operation type main operation associated with the abnormal result.

Optionally, the transaction processing module 340 is specifically configured to:

storing a transaction log in the process of committing the transaction into an external storage space by calling a transaction memory;

storing the attribute information of the transaction to be processed to a thread cache set; the attribute information comprises the operation contained in the transaction to be processed, the execution state of the operation and whether the operation belongs to the core operation.

Optionally, the transaction processing module 340 is further configured to:

and under the condition that the execution decision is rollback, rolling back the operation contained in the transaction to be processed according to the prestored operation image file.

Optionally, the transaction processing module 340 is further configured to:

after rolling back the operation contained in the transaction to be processed, judging whether the recovery times of the transaction to be processed reach a threshold of the recovery times;

Optionally, the transaction processing module 340 is further configured to:

the method comprises the steps that by calling a transaction memory, after a transaction log in the process of submitting a transaction is stored in an external storage space, an abnormal log of operation is read in the transaction log in the external storage space;

and sending the abnormal log to a compensation processing service through a message queue, wherein the compensation processing service is used for indicating the compensation processing service to perform compensation processing on the operation associated with the abnormal log.

Optionally, the apparatus for processing a distributed transaction further includes:

the operation state modification module is used for modifying the state of the associated operation of the resource manager according to the pre-execution result fed back by the resource manager;

and the preparation instruction repeat sending module is used for repeatedly sending a preparation instruction to the resource manager under the condition that the pre-execution result is abnormal and the repeated execution times do not exceed the repeated times threshold value.

The processing device for distributed transactions provided by the embodiment of the invention can execute the processing method for distributed transactions provided by any embodiment of the invention, and has corresponding functional modules and beneficial effects of the execution method.

Example four

FIG. 4 shows a schematic block diagram of an electronic device 10 that may be used to implement an embodiment of the invention. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed herein.

As shown in fig. 4, the electronic device 10 includes at least one processor 11, and a memory communicatively connected to the at least one processor 11, such as a Read Only Memory (ROM) 12, a Random Access Memory (RAM) 13, and the like, wherein the memory stores a computer program executable by the at least one processor, and the processor 11 may perform various suitable actions and processes according to the computer program stored in the Read Only Memory (ROM) 12 or the computer program loaded from the storage unit 18 into the Random Access Memory (RAM) 13. In the RAM 13, various programs and data necessary for the operation of the electronic apparatus 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other via a bus 14. An input/output (I/O) interface 15 is also connected to bus 14.

A number of components in the electronic device 10 are connected to the I/O interface 15, including: an input unit 16 such as a keyboard, a mouse, or the like; an output unit 17 such as various types of displays, speakers, and the like; a storage unit 18 such as a magnetic disk, an optical disk, or the like; and a communication unit 19 such as a network card, modem, wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.

The processor 11 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various processors running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, or the like. The processor 11 performs the various methods and processes described above, such as the processing method of a distributed transaction.

In some embodiments, the method of processing distributed transactions may be implemented as a computer program tangibly embodied on a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and/or installed onto the electronic device 10 via the ROM 12 and/or the communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method of processing distributed transactions described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured by any other suitable means (e.g., by means of firmware) to perform the processing method of the distributed transaction.

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), system on a chip (SOCs), complex Programmable Logic Devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

Computer programs for implementing the methods of the present invention can be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the computer programs, when executed by the processor, cause the functions/acts specified in the flowchart and/or block diagram block or blocks to be performed. A computer program can execute entirely on a machine, partly on a machine, as a stand-alone software package partly on a machine and partly on a remote machine or entirely on a remote machine or server.

In the context of the present invention, a computer-readable storage medium may be a tangible medium that can contain, or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. A computer readable storage medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, the computer readable storage medium may be a machine readable signal medium. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the electronic device. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), blockchain networks, and the internet.

The computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also called a cloud computing server or a cloud host, and is a host product in a cloud computing service system, so that the defects of high management difficulty and weak service expansibility in the traditional physical host and VPS service are overcome.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present invention may be executed in parallel, sequentially, or in different orders, and are not limited herein as long as the desired results of the technical solution of the present invention can be achieved.

The above-described embodiments should not be construed as limiting the scope of the invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for processing a distributed transaction, comprising:

2. The method of claim 1, wherein determining the execution decision of the to-be-processed transaction according to the operation type of each operation in the to-be-processed transaction and the pre-execution result fed back by the resource manager comprises:

determining an operation type associated with an abnormal result under the condition that the abnormal result is contained;

determining that the execution decision of the transaction to be processed is a commit under the condition that the operation types associated with the abnormal result are all branch operations;

3. The method of claim 1, wherein executing the pending transaction in accordance with the execution decision comprises:

4. The method of claim 1, wherein executing the pending transaction in accordance with the execution decision further comprises:

5. The method of claim 4, further comprising, after rolling back operations involved in the transaction to be processed:

and under the condition that the recovery times do not reach the threshold value of the recovery times, sending a preparation instruction to at least one resource manager associated with the to-be-processed transaction again for performing recovery operation on the executed transaction.

6. The method of claim 3, wherein after storing the transaction log during the commit process of the transaction to the external storage space by calling the transaction memory, further comprising:

reading an abnormal log of operation in the transaction log of the external storage space;

7. The method of claim 1, wherein before determining the execution decision of the to-be-processed transaction according to the operation type of each operation in the to-be-processed transaction and the pre-execution result fed back by the resource manager, the method further comprises:

and repeatedly sending a preparation instruction to the resource manager when the pre-execution result is abnormal and the repeated execution times do not exceed the repeated times threshold value.

8. An apparatus for processing distributed transactions, comprising:

the execution decision determining module is used for determining an execution decision of the transaction to be processed according to the operation type of each operation in the transaction to be processed and a pre-execution result fed back by the resource manager;

9. An electronic device, characterized in that the electronic device comprises:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores a computer program executable by the at least one processor to enable the at least one processor to perform the method of processing a distributed transaction of any of claims 1-7.

10. A computer-readable storage medium storing computer instructions for causing a processor to perform a method of processing a distributed transaction according to any one of claims 1 to 7 when executed.