CN112416535A

CN112416535A - Distributed transaction processing method and system

Info

Publication number: CN112416535A
Application number: CN202011326313.8A
Authority: CN
Inventors: 程冲; 滕达; 张丹枫; 唐冬雪
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2020-11-24
Filing date: 2020-11-24
Publication date: 2021-02-26
Anticipated expiration: 2040-11-24
Also published as: CN112416535B

Abstract

The application provides a distributed transaction processing method and a system, which can be used in the financial field or other fields, and the method comprises the following steps: applying a direct sub-transaction table corresponding to each transaction in a target distributed transaction, and determining a bottom sub-transaction corresponding to a main transaction in the target distributed transaction, wherein each direct sub-transaction table comprises: the corresponding relation between the affair and the next layer affair of the affair; performing distributed processing operations on the bottom sub-transaction; the distributed processing operations include: executing the transaction of the current layer and judging whether the transaction of the previous layer is a main transaction; if the upper layer transaction is determined to be not the main transaction, performing the distributed processing operation on the upper layer transaction; and if the last layer transaction is determined to be the main transaction, finishing the processing of the target distributed transaction. The method and the device can improve the reliability of the distributed transaction processing.

Description

Distributed transaction processing method and system

Technical Field

The present application relates to the field of distributed service technologies, and in particular, to a distributed transaction processing method and system.

Background

The distributed transaction means that an initiator, a participant, a server supporting the transaction, a resource server and a transaction manager of the transaction are located on different nodes of a distributed system, and for a complex service scene, layered nested sub-transactions exist, that is, the sub-transactions can call other sub-transactions on a lower layer.

In the process of distributed transaction processing, in a transaction information transmission part, common input and output of transaction information are usually defined, and the input and output of a service interface in the mode must be inherited from the common input and output, so that the invasion is high, and the switching principle is damaged; in the transaction information storage part, one solution is that the main transaction side stores the transaction information of all the sub-transactions on the link, and two-phase calling of all the sub-transactions is uniformly initiated by the main transaction.

Disclosure of Invention

In view of at least one technical problem in the foregoing background, the present application provides a distributed transaction processing method and system, which can improve reliability of distributed transaction processing.

In order to solve the technical problem, the present application provides the following technical solutions:

in a first aspect, the present application provides a distributed transaction processing method, including:

applying a direct sub-transaction table corresponding to each transaction in a target distributed transaction, and determining a bottom sub-transaction corresponding to a main transaction in the target distributed transaction, wherein each direct sub-transaction table comprises: the corresponding relation between the affair and the next layer affair of the affair;

performing distributed processing operations on the bottom sub-transaction; the distributed processing operations include: executing the transaction of the current layer and judging whether the transaction of the previous layer is a main transaction;

if the upper layer transaction is determined to be not the main transaction, performing the distributed processing operation on the upper layer transaction;

and if the last layer transaction is determined to be the main transaction, finishing the processing of the target distributed transaction.

Further, the determining, by applying the direct sub-transaction table corresponding to each transaction in the target distributed transaction, the bottom sub-transaction corresponding to the master transaction in the target distributed transaction includes:

performing a judgment operation on the master transaction; the judging operation comprises the following steps: acquiring a direct sub-transaction table corresponding to the transaction of the current layer; judging whether a next layer transaction exists or not based on a direct sub-transaction table corresponding to the transaction of the current layer and the main transaction;

if the next layer of transaction exists, the judging step is carried out on the next layer of transaction;

and if the next layer of transaction does not exist, taking the transaction of the current layer as the bottom layer sub-transaction.

Further, the determining whether a next-layer transaction exists based on the direct sub-transaction table corresponding to the transaction at the current layer and the main transaction includes:

writing the transaction identifier corresponding to the transaction of the current layer and the main transaction identifier corresponding to the main transaction into an RpcContext context;

applying a Filter mechanism to obtain the transaction identifier and the main transaction identifier from the RpcContext context;

and judging whether a next layer of transaction exists according to the direct sub-transaction table, the transaction identifier and the main transaction identifier corresponding to the transaction of the current layer.

Further, after the executing the transaction of the current layer, the method further includes:

marking the state corresponding to the transaction of the current layer as successful;

correspondingly, if it is determined that the previous layer transaction is the main transaction, completing the processing of the target distributed transaction, including:

if the last layer transaction is determined to be the main transaction, the state of the main transaction is marked to be successful, and the processing of the target distributed transaction is completed.

In a second aspect, the present application provides a distributed transaction processing system, comprising:

a determining device, configured to apply a direct sub-transaction table corresponding to each transaction in a target distributed transaction, and determine a bottom sub-transaction corresponding to a main transaction in the target distributed transaction, where each direct sub-transaction table includes: the corresponding relation between the affair and the next layer affair of the affair;

executing means for executing distributed processing operations on the bottom sub-transactions; the distributed processing operations include: executing the transaction of the current layer and judging whether the transaction of the previous layer is a main transaction;

processing means for performing the distributed processing operation on the previous-layer transaction if it is determined that the previous-layer transaction is not the master transaction;

and the main transaction determining device is used for finishing the processing of the target distributed transaction if the last layer transaction is determined to be the main transaction.

Further, the determining device includes:

the judging module is used for executing judging operation on the main affair; the judging operation comprises the following steps: acquiring a direct sub-transaction table corresponding to the transaction of the current layer; judging whether a next layer transaction exists or not based on a direct sub-transaction table corresponding to the transaction of the current layer and the main transaction;

the next judgment module is used for carrying out the judgment step on the next layer of transaction if the next layer of transaction is determined to exist;

and the bottom layer sub-transaction determining module is used for taking the transaction of the current layer as the bottom layer sub-transaction if the next layer transaction does not exist.

Further, the determining module includes:

a writing unit, configured to write a transaction identifier corresponding to the transaction of the current layer and a main transaction identifier corresponding to the main transaction into an RpcContext context;

an obtaining unit, configured to apply a Filter mechanism, and obtain the transaction identifier and the master transaction identifier from the RpcContext context;

and the transaction judgment unit is used for judging whether a next layer of transaction exists according to the direct sub-transaction table, the transaction identifier and the main transaction identifier corresponding to the transaction of the current layer.

Further, the execution device further includes:

a marking unit, configured to mark a state corresponding to the transaction of the current layer as successful;

correspondingly, the device for determining the master transaction includes:

and the main transaction determining unit is used for marking the state of the main transaction as successful if the last layer transaction is determined to be the main transaction, and finishing the processing of the target distributed transaction.

In a third aspect, the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the distributed transaction processing method when executing the program.

In a fourth aspect, the present application provides a computer readable storage medium having stored thereon computer instructions that, when executed, implement the distributed transaction processing method.

According to the technical scheme, the application provides a distributed transaction processing method and system. Wherein, the method comprises the following steps: applying a direct sub-transaction table corresponding to each transaction in a target distributed transaction, and determining a bottom sub-transaction corresponding to a main transaction in the target distributed transaction, wherein each direct sub-transaction table comprises: the corresponding relation between the affair and the next layer affair of the affair; performing distributed processing operations on the bottom sub-transaction; the distributed processing operations include: executing the transaction of the current layer and judging whether the transaction of the previous layer is a main transaction; if the upper layer transaction is determined to be not the main transaction, performing the distributed processing operation on the upper layer transaction; and if the last layer transaction is determined to be the main transaction, finishing the processing of the target distributed transaction. The reliability of distributed transaction processing can be improved; the transaction information can be implicitly transmitted, the input and the output are not required to be modified by a service interface, and the service is not sensible; by adopting the idea of hierarchical autonomy, the transaction information of all next-layer sub-transactions is stored in the local database of the hierarchically nested sub-transactions, so that the redundant reference of a service consumer can be eliminated, the single-point pressure in the system can be reduced, and the execution result of the whole link of the main transaction can be sensed in time; in particular, the advantages are as follows: 1. the traffic intrusiveness is small. The RpcContext context of the basic distributed service implicitly finishes the transmission of the transaction information, does not need a service interface to modify input and output, and achieves no service sense. 2. The two-stage result is quickly perceived. And storing the transaction information of all the next-layer sub-transactions based on a local database, and quickly sensing the execution result of the whole link of the main transaction.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a schematic flow chart diagram of a distributed transaction processing method in an embodiment of the present application;

FIG. 2 is a schematic flow chart diagram of a distributed transaction processing method according to another embodiment of the present application;

fig. 3 is a schematic flowchart of steps 301 to 303 of a distributed transaction processing method in an embodiment of the present application;

FIG. 4 is a flow chart of a distributed transaction processing method in an application example of the present application;

FIG. 5 is a schematic structural diagram of a distributed transaction processing system in an embodiment of the present application;

fig. 6 is a schematic block diagram of a system configuration of an electronic device according to an embodiment of the present application.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, 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 application.

In order to facilitate understanding of the technical solutions provided in the present application, the following first describes relevant contents of the technical solutions in the present application.

TCC (Try-Confirm-Cancel) is a two-phase distributed transaction model that is mainstream in the industry. Through the decomposition of the business logic, the TCC model decomposes the business logic into two phases, wherein one phase is a Try phase, and the two phases are Confirm or Cancel phases:

try: and finishing all service checks, reserving necessary service resources, and ensuring that the Confirm can be successfully completed after the Try is finished.

Confirm: the really executed service logic does not perform any service check, and only uses the service resources reserved in the try stage.

Cancel: and releasing the reserved service resources in the try stage.

The one-stage Try operation explicitly completes the call in the whole transaction link and the transmission of the upper and lower layer transaction information through the transaction initiator.

For the two-stage Confirm/Cancel operation, there is no displayed call link between the transaction initiator and the participant, how the transaction information before the upper and lower layers is transferred, and how the upper and lower layer relations before the transaction participant are stored. How to realize the transmission of the transaction information and the storage of the upper-layer relation and the lower-layer relation under the condition of no sense of business logic.

The distributed transaction processing method and system provided by the embodiment of the application can be used for solving the problems of transmission and storage of transaction information between an upper layer and a lower layer of layered nested sub-transactions in the two-stage distributed transaction model; a Filter mechanism based on a distributed service Dubbo protocol adopts a hierarchical autonomy idea, stores the transaction information of all next-layer sub-transactions in a local database of hierarchically nested sub-transactions, eliminates the redundant reference of a service consumer, and can sense the execution result of the whole link of a main transaction in time.

Based on this, in order to reduce the single-point storage pressure in the system and further improve the reliability of distributed transaction processing, an embodiment of the present application provides a distributed transaction processing system, where the system may be a server or a client device, and the client device may include a smart phone, a tablet electronic device, a network set-top box, a portable computer, a desktop computer, a Personal Digital Assistant (PDA), a vehicle-mounted device, an intelligent wearable device, and the like. Wherein, intelligence wearing equipment can include intelligent glasses, intelligent wrist-watch and intelligent bracelet etc..

In practical applications, part of the distributed transaction may be performed on the server side as described above, or all operations may be performed in the client device. The selection may be specifically performed according to the processing capability of the client device, the limitation of the user usage scenario, and the like. This is not a limitation of the present application. The client device may further include a processor if all operations are performed in the client device.

The client device may have a communication module (i.e., a communication unit), and may be communicatively connected to a remote server to implement data transmission with the server. The server may include a server on the task scheduling center side, and in other implementation scenarios, the server may also include a server on an intermediate platform, for example, a server on a third-party server platform that is communicatively linked to the task scheduling center server. The server may include a single computer device, or may include a server cluster formed by a plurality of servers, or a server structure of a distributed apparatus.

The server and the client device may communicate using any suitable network protocol, including network protocols not yet developed at the filing date of this application. The network protocol may include, for example, a TCP/IP protocol, a UDP/IP protocol, an HTTP protocol, an HTTPS protocol, or the like. Of course, the network Protocol may also include, for example, an RPC Protocol (Remote Procedure Call Protocol), a REST Protocol (Representational State Transfer Protocol), and the like used above the above Protocol.

It should be noted that the distributed transaction processing method and system disclosed in the present application can be used in the field of financial technology, and can also be used in any field other than the field of financial technology.

The following examples are intended to illustrate the details.

In order to reduce the single-point storage pressure in the system and further improve the reliability of the distributed transaction processing, the embodiment provides a distributed transaction processing method in which the execution subject is a distributed transaction processing system, the distributed transaction processing system includes but is not limited to a server, as shown in fig. 1, the method specifically includes the following contents:

step 101: applying a direct sub-transaction table corresponding to each transaction in a target distributed transaction, and determining a bottom sub-transaction corresponding to a main transaction in the target distributed transaction, wherein each direct sub-transaction table comprises: a correspondence between a transaction and a transaction that is next to the transaction.

Specifically, the direct sub-transaction tables corresponding to the respective transactions may be different, multiple transactions of the same application may correspond to the same direct sub-transaction table, the direct sub-transaction table corresponding to each transaction may be stored in the database corresponding to the transaction, and data in each direct sub-transaction table may be set according to actual needs; the sub-transaction directly called by the transaction can be used as the next layer transaction corresponding to the transaction, namely the next layer transaction can be equivalent to a direct sub-transaction; the bottom layer sub-transaction is a leaf node corresponding to the main transaction, and the two-stage logic of the bottom layer sub-transaction can be executed when the next layer transaction does not exist. The main transaction can nest a plurality of sub-transactions and can be at least one layer of sub-transactions; after receiving a transaction processing request corresponding to the target distributed transaction sent by a client, determining a bottom-layer sub-transaction corresponding to a main transaction in the target distributed transaction by applying a direct sub-transaction table corresponding to each transaction in the target distributed transaction; if the next layer transaction does not exist in the transaction, the corresponding relationship between the transaction and the next layer transaction of the transaction can be null; each transaction in the target distributed transaction may contain a master transaction.

Step 102: performing distributed processing operations on the bottom sub-transaction; the distributed processing operations include: and executing the transaction of the current layer and judging whether the transaction of the previous layer is the main transaction.

Specifically, it may be determined whether a transaction identifier of a previous layer transaction corresponding to a current layer transaction is the same as the main transaction identifier, if so, the previous layer transaction is the main transaction, otherwise, the previous layer transaction is a direct sub-transaction or an indirect sub-transaction corresponding to the main transaction.

Step 103: and if the upper layer transaction is determined to be not the main transaction, performing the distributed processing operation on the upper layer transaction.

Step 104: and if the last layer transaction is determined to be the main transaction, finishing the processing of the target distributed transaction.

As can be seen from the above description, the distributed transaction processing method provided in this embodiment can improve the reliability of distributed transaction processing; the method adopts the idea of hierarchical autonomy, sets a direct sub-transaction table corresponding to each transaction, stores the transaction information of all the sub-transactions of the next layer in a local database of the sub-transactions nested in a hierarchical manner, can eliminate redundant reference of a service consumer, and can sense the execution result of the whole link of the main transaction in time.

To further improve the reliability of the distributed transaction, referring to fig. 2, in an embodiment of the present application, step 101 includes:

step 201: performing a judgment operation on the master transaction; the judging operation comprises the following steps: acquiring a direct sub-transaction table corresponding to the transaction of the current layer; and judging whether a next layer transaction exists or not based on the direct sub-transaction table corresponding to the transaction of the current layer and the main transaction.

Specifically, a direct sub-transaction table corresponding to the transaction of the current layer may be obtained from a database corresponding to the transaction of the current layer; the direct sub-transaction table corresponding to the transaction of the current layer can be queried according to the transaction identifier corresponding to the transaction of the current layer and the main transaction identifier, whether a transaction record corresponding to the transaction identifier and the main transaction identifier exists in the direct sub-transaction table or not is judged, if yes, the next layer of transaction is determined to exist, and if not, the next layer of transaction does not exist.

Step 202: and if the next layer of transaction exists, performing the judging step on the next layer of transaction.

Step 203: and if the next layer of transaction does not exist, taking the transaction of the current layer as the bottom layer sub-transaction.

In order to implement implicit transfer of transaction information, avoid modification of input and output of a service interface, and make a service noninductive, referring to fig. 3, in an embodiment of the present application, the determining whether a next-layer transaction exists based on the direct sub-transaction table corresponding to the transaction at the current layer and the main transaction in step 201 includes:

step 301: and writing the transaction identifier corresponding to the transaction of the current layer and the main transaction identifier corresponding to the main transaction into an RpcContext context.

Specifically, a distributed transaction call may be applied to write a transaction identifier and a main transaction identifier corresponding to a transaction of a current layer into the RpcContext context; while writing in the transaction identifier and the main transaction identifier, writing a two-stage identifier into the RpcContext context, wherein the two-stage identifier can be used for judging whether to execute the judging step or not, so that the reliability of distributed transaction processing can be further improved; the transaction identifier is used for distinguishing different transactions and can be a string of character strings, such as transaction ID; the master transaction identification may be a transaction identification of a master transaction.

Step 302: and applying a Filter mechanism to acquire the transaction identifier and the main transaction identifier from the RpcContext context.

Specifically, an Rpcontext context mechanism of a distributed service Dubbo protocol can be applied to implicitly transfer the transaction information without modifying input and output of a service interface, so that the influence on the service process can be avoided, and the safety of the transaction information transfer process can be improved. And acquiring the transaction identifier and the main transaction identifier and simultaneously acquiring two-stage identifiers.

Step 303: and judging whether a next layer of transaction exists according to the direct sub-transaction table, the transaction identifier and the main transaction identifier corresponding to the transaction of the current layer.

It can be understood that if the transaction record corresponding to the transaction identifier and the main transaction identifier exists in the direct sub-transaction table corresponding to the transaction at the current layer, the next layer transaction exists, otherwise, the next layer transaction does not exist.

In order to timely sense the execution result of the whole link of the master transaction while eliminating the reference of the service consumer redundancy, in an embodiment of the present application, after the executing the transaction at the current layer in step 102, the method further includes:

step 401: marking the state corresponding to the transaction of the current layer as successful; correspondingly, step 104 includes:

step 402: if the last layer transaction is determined to be the main transaction, the state of the main transaction is marked to be successful, and the processing of the target distributed transaction is completed.

Specifically, the direct sub-transaction table may further include a status identifier of a next-layer transaction, and if the status identifier of each next-layer transaction corresponding to the main transaction is successful, the status of the main transaction in the preset main transaction table is marked as successful.

In order to solve the problems of transmission and storage of transaction information between a layered nested sub-transaction and an upper layer and a lower layer in a two-phase distributed transaction model, the application provides an application example of a distributed transaction processing method with an application scenario of a TCC (cross-state transaction center) two-phase distributed transaction model, and the application example comprises the following steps: the RpcContext context, the Filter mechanism and the local database storage based on distributed service invocation are described in detail as follows:

one-stage Try, storage of transaction information:

s11: the initiator and the participants of the transaction need to set corresponding local databases, and the local databases are stored in two tables: a master transaction table and a direct child transaction table.

S12: the main transaction table only writes records at the transaction initiator, and records the execution condition of the whole main transaction. The method mainly comprises the following steps: primary transaction ID and primary transaction status, etc. Wherein the master transaction state comprises an intermediate state.

S13: the direct sub-transaction table writes records on the transaction initiator and the transaction participant, and records the next layer transaction relationship data of the current transaction. The method mainly comprises the following steps: primary transaction ID, sub-transaction ID, current transaction ID, and sub-transaction status. The main transaction ID is kept unchanged in the whole transaction call link, the sub-transaction IDs are different with the change of the participants, the current transaction ID represents the previous layer transaction ID to which the sub-transaction belongs, and may be the main transaction ID or the previous layer sub-transaction ID.

S14: and the sub-transaction IDs are generated on the consumer of the distributed service through the transaction manager and are written into a database where the consumer is located for storage.

S15: the direct sub-transaction table only needs to record the direct sub-transaction of the current transaction and does not record the indirect sub-transaction.

For example, if the main transaction A, there are 3 sub-transactions B, C and D. A sub-transaction D and a main transaction A belong to the same application, the sub-transaction B calls nested sub-transactions E and F, and the sub-transaction D calls nested sub-transaction G, so that a main transaction table in database records of the main transaction A and the sub-transaction D is shown in table 1, CREATE in table 1 shows that the state of the main transaction is a creation state, a direct sub-transaction table in database records of the main transaction A and the sub-transaction D is shown in table 2, namely the direct sub-transaction table corresponding to the main transaction A is shown in table 2, the direct sub-transaction table corresponding to the sub-transaction D is also shown in table 2, and main transaction tables in database records of the sub-transaction B and the sub-transaction C are respectively shown in table 3, namely both are empty tables; the direct sub-transaction table in the database record for sub-transaction B is shown in Table 4; the immediate child table in the database record for child transaction C is shown in Table 5 as an empty table. Wherein, a1 to G1 in tables 1 to 5 sequentially represent IDs of a transaction to G sub-transaction, a CREATE in table 1 represents that a state of the main transaction is a creation state, and a CREATE in tables 2 and 4 represents that a state of a transaction corresponding to the ID column of the sub-transaction is a creation state.

TABLE 1

TABLE 2

TABLE 3

TABLE 4

TABLE 5

Two-stage Confirm/Cancel, transfer and use of transaction information:

s21: the initiator starts executing a two-phase Confirm.

S22: the initiator queries the direct sub-transaction table of the local database according to the primary transaction ID and the current transaction ID (which is equal to the primary transaction ID at this time), and obtains current direct sub-transaction lists B, C and D, where the sub-transaction list may represent a sub-transaction record.

S23: the initiator's loop handles two-phase Confirm calls for each sub-transaction: through the distributed transaction call, each sub-transaction ID, main transaction ID and second-stage flag in the table are put into the GlobalTxId, LocalTxId and MethodType attributes in the Rpcontext context.

S24: and acquiring the main transaction ID, the sub-transaction ID and the two-stage mark in the Rpcontext context through a Filter mechanism at the service providing side, and judging whether the two-stage call is the two-stage call of the TCC model.

S25: and the second-stage mark is used for setting the current transaction ID as the acquired sub-transaction ID, inquiring a direct sub-transaction table of the local database and acquiring current direct sub-transaction lists E and F.

S26: if the obtained sub-transaction list is not empty, the context is continuously set, and the next layer of sub-transaction is called first; and if the acquired sub-transaction list is empty, the sub-transaction is indicated to be a leaf node, and the two-phase logic of the sub-transaction is started to be executed.

S27: after the execution of the two-stage Confirm of the sub-transaction is completed, the distributed service call is ended, the execution result is returned to the consumer, namely the upper-layer sub-transaction, and the upper-layer sub-transaction starts to execute the two-stage Confirm.

S28: and when the execution of the two phases of Confirm of all the sub-transactions is completed, updating the state of the main transaction to be successful, and successfully executing the whole transaction.

As can be seen from the above description, for the two-stage Confirm/Cancel operation, the distributed transaction processing method provided by the present application example does not have a displayed call link between the transaction initiator and the participants, and can implement the transaction information transfer between the upper and lower layers, the storage of the upper and lower layer relationships between the transaction participants, and the transfer of the transaction information and the storage of the upper and lower layer relationships under the condition of no sense of business logic.

Referring to fig. 4, in an example, the distributed transaction processing method includes the following steps:

s31: TASK lock of TASK; the TASK lock is applied.

S32: the confirm of child transaction X1 is called.

S33: the child transactions of the current transaction are queried.

S34: the confirm of child transaction X2 is called.

S35: the confirm of sub-transaction X2 is executed.

S36: the confirm return of child transaction X2.

S37: the status of executing sub-transaction X2 is CONFIRM _ SUCCESS; i.e., the status of sub-transaction X2 is marked as completed SUCCESS.

S38: the confirm of sub-transaction X1 is executed.

S39: the confirm return of child transaction X1.

S40: the status of the update sub-transaction X1 is CONFIRM _ SUCCESS.

S41: the child transaction Y1 interface is invoked.

S42: inquiring the next layer of sub-transactions of the current sub-transaction; namely, the database of the sub-transaction of the current layer is queried to obtain the direct sub-transaction list.

S43: the confirm of sub-transaction Y1 is executed.

S44: the child transaction Y1 interface returns.

S45: the status of the update sub-transaction Y1 is CONFIRM _ SUCCESS.

S46: the status of the update master transaction is CONFIRM _ SUCCESS.

S47: the TASK lock is released and the TASK lock is deleted.

From the software aspect, in order to reduce the single-point storage pressure in the system and further improve the reliability of the distributed transaction processing, the present application provides an embodiment of a distributed transaction processing system for implementing all or part of the contents in the distributed transaction processing method, and referring to fig. 5, the distributed transaction processing system specifically includes the following contents:

the determining device 01 is configured to apply a direct sub-transaction table corresponding to each transaction in the target distributed transaction, and determine a bottom sub-transaction corresponding to a master transaction in the target distributed transaction, where each direct sub-transaction table includes: a correspondence between a transaction and a transaction that is next to the transaction.

An executing device 02, configured to execute a distributed processing operation on the bottom-layer sub-transaction; the distributed processing operations include: and executing the transaction of the current layer and judging whether the transaction of the previous layer is the main transaction.

And the processing device 03 is configured to perform the distributed processing operation on the previous-layer transaction if it is determined that the previous-layer transaction is not the master transaction.

And a master transaction determining device 04, configured to complete processing of the target distributed transaction if it is determined that the previous layer transaction is a master transaction.

In an embodiment of the present application, the determining apparatus includes:

the judging module is used for executing judging operation on the main affair; the judging operation comprises the following steps: acquiring a direct sub-transaction table corresponding to the transaction of the current layer; and judging whether a next layer transaction exists or not based on the direct sub-transaction table corresponding to the transaction of the current layer and the main transaction.

And the next judgment module is used for carrying out the judgment step on the next layer of transaction if the next layer of transaction is determined to exist.

In an embodiment of the present application, the determining module includes:

and the writing unit is used for writing the transaction identifier corresponding to the transaction of the current layer and the main transaction identifier corresponding to the main transaction into the Rpcontext context.

And the acquisition unit is used for acquiring the transaction identifier and the main transaction identifier from the RpcContext context by applying a Filter mechanism.

In an embodiment of the present application, the execution apparatus further includes:

a marking unit, configured to mark a state corresponding to the transaction of the current layer as successful; correspondingly, the device for determining the master transaction includes:

The embodiment of the distributed transaction processing system provided in this specification may be specifically configured to execute the processing flow of the embodiment of the distributed transaction processing method, and its functions are not described herein again, and reference may be made to the detailed description of the embodiment of the distributed transaction processing method.

As can be seen from the above description, the distributed transaction processing method and system provided by the present application can improve the reliability of distributed transaction processing; the transaction information can be implicitly transmitted, the input and the output are not required to be modified by a service interface, and the service is not sensible; by adopting the idea of hierarchical autonomy, the transaction information of all next-layer sub-transactions is stored in a local database of the sub-transactions nested in a hierarchical manner, so that the redundant reference of a service consumer can be eliminated, and the execution result of the whole link of the main transaction can be sensed in time; in particular, the advantages are as follows: 1. the traffic intrusiveness is small. The RpcContext context of the basic distributed service implicitly finishes the transmission of the transaction information, does not need a service interface to modify input and output, and achieves no service sense. 2. The two-stage result is quickly perceived. And storing the transaction information of all the next-layer sub-transactions based on a local database, and quickly sensing the execution result of the whole link of the main transaction.

In terms of hardware, in order to reduce the single-point storage pressure in the system and further improve the reliability of the distributed transaction processing, the present application provides an embodiment of an electronic device for implementing all or part of the contents in the distributed transaction processing method, where the electronic device specifically includes the following contents:

a processor (processor), a memory (memory), a communication Interface (Communications Interface), and a bus; the processor, the memory and the communication interface complete mutual communication through the bus; the communication interface is used for realizing information transmission between the distributed transaction processing system and the related equipment such as the user terminal and the like; the electronic device may be a desktop computer, a tablet computer, a mobile terminal, and the like, but the embodiment is not limited thereto. In this embodiment, the electronic device may be implemented with reference to the embodiment for implementing the distributed transaction processing method and the embodiment for implementing the distributed transaction processing system in the embodiments, and the contents of the embodiments are incorporated herein, and repeated details are not described herein.

Fig. 6 is a schematic block diagram of a system configuration of an electronic device 9600 according to an embodiment of the present application. As shown in fig. 6, the electronic device 9600 can include a central processor 9100 and a memory 9140; the memory 9140 is coupled to the central processor 9100. Notably, this FIG. 6 is exemplary; other types of structures may also be used in addition to or in place of the structure to implement telecommunications or other functions.

In one or more embodiments of the present application, distributed transaction processing functionality can be integrated into the central processor 9100. The central processor 9100 may be configured to control as follows:

As can be seen from the foregoing description, the electronic device provided in the embodiments of the present application can reduce the single-point pressure in the system, thereby improving the reliability of the distributed transaction.

In another embodiment, the distributed transaction system may be configured separately from the central processor 9100, for example, the distributed transaction system may be configured as a chip connected to the central processor 9100, and the distributed transaction function is implemented under the control of the central processor.

As shown in fig. 6, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is noted that the electronic device 9600 also does not necessarily include all of the components shown in fig. 6; further, the electronic device 9600 may further include components not shown in fig. 6, which may be referred to in the art.

As shown in fig. 6, a central processor 9100, sometimes referred to as a controller or operational control, can include a microprocessor or other processor device and/or logic device, which central processor 9100 receives input and controls the operation of the various components of the electronic device 9600.

The memory 9140 can be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, or other suitable device. The information relating to the failure may be stored, and a program for executing the information may be stored. And the central processing unit 9100 can execute the program stored in the memory 9140 to realize information storage or processing, or the like.

The input unit 9120 provides input to the central processor 9100. The input unit 9120 is, for example, a key or a touch input device. Power supply 9170 is used to provide power to electronic device 9600. The display 9160 is used for displaying display objects such as images and characters. The display may be, for example, an LCD display, but is not limited thereto.

The memory 9140 can be a solid state memory, e.g., Read Only Memory (ROM), Random Access Memory (RAM), a SIM card, or the like. There may also be a memory that holds information even when power is off, can be selectively erased, and is provided with more data, an example of which is sometimes called an EPROM or the like. The memory 9140 could also be some other type of device. Memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application/function storage portion 9142, the application/function storage portion 9142 being used for storing application programs and function programs or for executing a flow of operations of the electronic device 9600 by the central processor 9100.

The memory 9140 can also include a data store 9143, the data store 9143 being used to store data, such as contacts, digital data, pictures, sounds, and/or any other data used by an electronic device. The driver storage portion 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and/or for performing other functions of the electronic device (e.g., messaging applications, contact book applications, etc.).

The communication module 9110 is a transmitter/receiver 9110 that transmits and receives signals via an antenna 9111. The communication module (transmitter/receiver) 9110 is coupled to the central processor 9100 to provide input signals and receive output signals, which may be the same as in the case of a conventional mobile communication terminal.

Based on different communication technologies, a plurality of communication modules 9110, such as a cellular network module, a bluetooth module, and/or a wireless local area network module, may be provided in the same electronic device. The communication module (transmitter/receiver) 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby implementing ordinary telecommunications functions. The audio processor 9130 may include any suitable buffers, decoders, amplifiers and so forth. In addition, the audio processor 9130 is also coupled to the central processor 9100, thereby enabling recording locally through the microphone 9132 and enabling locally stored sounds to be played through the speaker 9131.

As can be seen from the above description, the electronic device provided in the embodiments of the present application can reduce the single-point pressure in the system, thereby improving the reliability of the distributed transaction.

Embodiments of the present application further provide a computer-readable storage medium capable of implementing all the steps in the distributed transaction processing method in the foregoing embodiments, where the computer-readable storage medium stores thereon a computer program, and when the computer program is executed by a processor, the computer program implements all the steps in the distributed transaction processing method in the foregoing embodiments, for example, when the processor executes the computer program, the processor implements the following steps:

As can be seen from the foregoing description, the computer-readable storage medium provided in the embodiments of the present application can reduce single-point pressure in a system, thereby improving reliability of distributed transaction processing.

In the present application, each embodiment of the method is described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. Reference is made to the description of the method embodiments.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The principle and the implementation mode of the present application are explained by applying specific embodiments in the present application, and the description of the above embodiments is only used to help understanding the method and the core idea of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims

1. A distributed transaction processing method, comprising:

2. The distributed transaction processing method of claim 1, wherein determining the underlying sub-transaction corresponding to the primary transaction in the target distributed transaction by applying the direct sub-transaction table corresponding to each transaction in the target distributed transaction comprises:

3. The distributed transaction processing method of claim 2, wherein the determining whether a next-layer transaction exists based on the direct sub-transaction table corresponding to the transaction at the current layer and the master transaction comprises:

4. The distributed transaction processing method of claim 1, further comprising, after said executing the transaction at the current level:

5. A distributed transaction processing system, comprising:

6. The distributed transaction system of claim 5, wherein said means for determining comprises:

7. The distributed transaction system of claim 6, wherein said determining module comprises:

8. The distributed transaction processing system of claim 5, wherein the execution means further comprises:

correspondingly, the device for determining the master transaction includes:

9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the distributed transaction processing method of any one of claims 1 to 4 when executing the program.

10. A computer readable storage medium having stored thereon computer instructions, wherein said instructions when executed implement the distributed transaction processing method of any of claims 1 to 4.