CN114327794A

CN114327794A - Transaction management method, apparatus, device, medium, and program product

Info

Publication number: CN114327794A
Application number: CN202111597811.0A
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: 2021-12-24
Filing date: 2021-12-24
Publication date: 2022-04-12

Abstract

The disclosure provides a distributed transaction management method based on a library-sharing mode, which can be applied to the financial field or other fields. The distributed transaction management method comprises the following steps: determining the service version of the current service node according to preset version configuration information; scanning a main transaction from a service database according to the retry request and the service version, wherein the main transaction comprises version identification information corresponding to the service version; extracting at least one branch transaction corresponding to the main transaction from the service database; and calling at least one branch transaction according to a calling rule corresponding to the retry request so as to perform retry operation. The present disclosure also provides a peer-to-peer mode based distributed transaction management apparatus, device, medium, and program product.

Description

Transaction management method, apparatus, device, medium, and program product

Technical Field

The present disclosure relates to the field of distributed transaction technologies, and in particular, to a transaction management method, apparatus, device, medium, and program product based on a same library mode.

Background

A transaction (transaction) refers to a sequence of operations consisting of one or more resource management operations. A distributed transaction refers to a transaction in which operations in a sequence of operations involve multiple Databases (DBs).

At present, in a library-sharing mode of distributed transactions, transaction data is usually stored in a database at a service application side, so that network transmission links can be reduced, and the working performance is improved. However, when the service node cluster is version-upgraded, a situation that the new service node and the old service node share the transaction data in one database may occur, which may result in failure of some retry operations, such as retry of two stages of TCC (Try-Confirm-Cancel), and the like.

Disclosure of Invention

In view of the foregoing, the present disclosure provides a transaction management method, apparatus, device, medium, and program product based on a same library schema.

According to a first aspect of the present disclosure, a distributed transaction management method based on a peer-to-peer mode is provided, which is applied to at least one service node in a distributed transaction management system, wherein the transaction management method includes:

determining the service version of the current service node according to preset version configuration information;

scanning a main transaction from a service database according to the retry request and the service version, wherein the main transaction comprises version identification information corresponding to the service version;

extracting at least one branch transaction corresponding to the main transaction from the service database;

and calling the at least one branch transaction according to a calling rule corresponding to the retry request so as to perform retry operation.

According to an embodiment of the present disclosure, the retry request comprises a first retry request generated in a business service retry phase, the main transaction comprises a main business transaction, and one of the branch transactions comprises a sub business transaction of one participant participating in the business transaction;

the invoking the at least one branch transaction according to the invoking rule corresponding to the retry request to perform the retry operation includes:

and calling each extracted business sub-transaction in turn to retry the business service.

According to an embodiment of the present disclosure, the retry request includes a second retry request generated in a message service retry phase, the primary transaction includes a message service transaction, the number of branch transactions is plural, and the plural branch transactions include: at least one main transaction corresponding to the message service transaction, and a message sending transaction corresponding to the at least one main transaction;

and when the main service transaction is successfully called, calling the message sending transaction to retry the message service.

According to an embodiment of the present disclosure, the transaction management method further includes:

acquiring at least one transaction and determining a transaction record of the at least one transaction;

determining the service version of the current service node according to the version configuration information, and acquiring version identification information corresponding to the service version;

and generating the main transaction according to the transaction record and the version identification information, and writing the main transaction into the service database.

acquiring an abnormal scanning task lock corresponding to the current service node from at least one abnormal scanning task lock;

and after the abnormal scanning task lock corresponding to the current service node is obtained, executing the step of scanning the main transaction from the service database according to the retry request and the service version.

According to an embodiment of the present disclosure, the number of the service nodes is multiple, the service versions of at least two service nodes in the multiple service nodes are different, the number of the exception scanning task locks is multiple, one service version corresponds to at least one exception scanning task lock, and the exception scanning task locks corresponding to different service versions are different.

According to the embodiment of the disclosure, the number of the service nodes is multiple, and the plurality of service nodes upgrade the service version by adopting at least one mode of gray release, rolling upgrade and blue-green release.

A second aspect of the present disclosure provides a distributed transaction management apparatus based on a peer-to-peer mode, applied to at least one service node in a distributed transaction management system, where the apparatus includes:

the service version confirmation module is used for determining the service version of the current service node according to preset version configuration information;

a first scanning module, configured to scan a main transaction from a service database according to a retry request and the service version, where the main transaction includes version identification information corresponding to the service version;

the second scanning module is used for scanning at least one branch transaction corresponding to the main transaction from the service database;

and the calling module is used for calling the at least one branch transaction according to a calling rule corresponding to the retry request so as to perform retry operation.

A third aspect of the present disclosure provides an electronic device, comprising: one or more processors; a memory for storing one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the above-described peer-based mode distributed transaction management method.

A fourth aspect of the present disclosure also provides a computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the above-described peer-based mode distributed transaction management method.

A fifth aspect of the present disclosure also provides a computer program product comprising a computer program that, when executed by a processor, implements the above-described peer-to-peer schema-based distributed transaction management method.

One or more of the embodiments described above have the following advantages or benefits:

when a retry request is received, the service version of the current service node can be determined first, then the master transaction including the version identification information corresponding to the service version is extracted from the service database, in this way, the new and old service nodes can respectively scan the master transaction corresponding to the respective service versions, and then retry operation is performed, so that the problem that the new and old service nodes scan the same master transaction is avoided, and further, the problem that the retry operation fails due to the scanning is avoided.

Drawings

The foregoing and other objects, features and advantages of the disclosure will be apparent from the following description of embodiments of the disclosure, which proceeds with reference to the accompanying drawings, in which:

FIG. 1 schematically illustrates an application scenario diagram of a method, apparatus, device, storage medium, and program product for peer-to-peer mode based distributed transaction management according to an embodiment of the present disclosure;

FIG. 2 schematically shows one of the flow diagrams of a method for peer-to-peer mode based distributed transaction management according to an embodiment of the disclosure;

FIG. 3 schematically illustrates a second flowchart of a method for peer-based mode-based distributed transaction management according to an embodiment of the present disclosure;

FIG. 4 schematically shows one of the flow diagrams of a call branch transaction according to an embodiment of the disclosure;

FIG. 5 schematically illustrates a second flow diagram for invoking a branch transaction according to an embodiment of the present disclosure;

FIG. 6 schematically shows a third flowchart of a distributed transaction management method based on the peer-to-peer mode according to an embodiment of the present disclosure;

FIG. 7 is a block diagram that schematically illustrates a distributed transaction management apparatus based on a peer-to-peer mode, in accordance with an embodiment of the present disclosure;

FIG. 8 schematically shows a block diagram of an electronic device adapted to implement a peer-based schema distributed transaction management method according to an embodiment of the present disclosure.

Detailed Description

Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that the description is illustrative only and is not intended to limit the scope of the present disclosure. In the following detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the disclosure. It may be evident, however, that one or more embodiments may be practiced without these specific details. Moreover, in the following description, descriptions of well-known structures and techniques are omitted so as to not unnecessarily obscure the concepts of the present disclosure.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The terms "comprises," "comprising," and the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.

All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It is noted that the terms used herein should be interpreted as having a meaning that is consistent with the context of this specification and should not be interpreted in an idealized or overly formal sense.

Where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B, C together, etc.).

The transaction management method and device based on the same library mode can be used in the financial field in distributed transaction service, and can also be used in any field except the financial field.

In the technical scheme of the disclosure, the collection, storage, use, processing, transmission, provision, disclosure, application and other processing of the personal information of the related user are all in accordance with the regulations of related laws and regulations, necessary confidentiality measures are taken, and the customs of the public order is not violated.

At present, distributed transactions are generally processed by adopting TCC technology, and the processing procedure of TCC technology comprises two phases, wherein one phase is a Try phase, and the two phases are Confirm or Cancel phases.

And (5) Try stage: and finishing all service checks, reserving necessary service resources, and ensuring that the Confirm can be successfully completed after the Try is finished.

A Confirm stage: the actually executed service logic does not make any service check, and only uses the service resources reserved in the Try stage.

A Cancel stage: and releasing the reserved service resources in the Try stage.

When two phases of Try fail, a retry operation is initiated.

For example, some or all of the steps in the above process may be deployed in at least one service node in a service node cluster composed of a plurality of service nodes. For a transaction, such as a transfer service (hereinafter referred to as the Main transaction S), it invokes two sub-transactions, sub-transaction A and sub-transaction B, respectively. In the library-based mode, at one stage, all service checks are completed, necessary service resources are reserved, and service data, such as calling methods, related to the main transaction S, the sub-transaction a, and the sub-transaction B are stored into the memory of the service node X and the service database D. When the first phase is successful, two phases are initiated for the main transaction S, taking the Confirm phase as an example, at this time, a sub-transaction a and a sub-transaction B corresponding to the main transaction S are firstly inquired from the service database D, and then the sub-transaction a and the sub-transaction B are sequentially called to perform a commit operation. When the commit of the sub-transaction a or the sub-transaction B fails, a retry operation is performed in a retry stage, and at this time, the service database D is scanned to obtain all unclosed loop main transactions and initiate a retry, where the unclosed loop may refer to that the commit operation of at least one sub-transaction corresponding to the main transaction fails.

Due to the adoption of the library-sharing mode, when the service node cluster performs version updating, a situation that a new service node and an old service node (a service node after updating and a service node before updating) share transaction data in one service database may exist.

For example, for a service node (hereinafter referred to as service node X1) that has not undergone a version update, master transaction S invokes sub-transaction a and sub-transaction B, respectively; for the service node that has made the version update (hereinafter referred to as service node X2), the master transaction S invokes sub-transaction a, sub-transaction B, and sub-transaction C, respectively. When the retry operation is performed in the retry stage, the service node X2 can perform a normal retry operation, and when the service node X1 scans the traffic database D, it scans the main transaction S generated by the service node X2, and obtains the transaction data including the main transaction S calling the sub-transaction a, the sub-transaction B, and the sub-transaction C. Since the service node X1 only has business data associated with the main transaction S invoking sub-transaction a and sub-transaction B, respectively, recorded in memory, and no business data associated with sub-transaction C, a retry failure will occur.

In view of this, an embodiment of the present disclosure provides a distributed transaction management method based on a peer-to-peer mode, which is applied to at least one service node in a distributed transaction management system, where the transaction management method includes: and determining the service version of the current service node according to preset version configuration information. And scanning a main transaction from a service database according to the retry request and the service version, wherein the main transaction comprises version identification information corresponding to the service version. At least one branch transaction corresponding to the main transaction is extracted from the transaction database. And calling at least one branch transaction according to a calling rule corresponding to the retry request so as to perform retry operation.

By adopting the distributed transaction management method based on the same-base mode of the embodiment of the disclosure, when a retry request is received, the service version of the current service node can be determined first, and then the main transaction including the version identification information corresponding to the service version is extracted from the service database.

FIG. 1 schematically illustrates an application scenario diagram of a method, apparatus, device, storage medium, and program product for peer-to-peer mode based distributed transaction management according to embodiments of the present disclosure.

As shown in fig. 1, network 104 is the medium used to provide communication links between

terminal devices

101, 102, 103 and server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

The user may use the

terminal devices

101, 102, 103 to interact with the server 105 via the network 104 to receive or send messages or the like. The

terminal devices

101, 102, 103 may have installed thereon various communication client applications, such as shopping-like applications, web browser applications, search-like applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only).

The

terminal devices

101, 102, 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 105 may be a server providing various services, such as a background management server (for example only) providing support for websites browsed by users using the

terminal devices

101, 102, 103. The background management server may analyze and perform other processing on the received data such as the user request, and feed back a processing result (e.g., a webpage, information, or data obtained or generated according to the user request) to the terminal device.

It should be noted that the distributed transaction management method based on the peer-to-peer mode provided by the embodiment of the present disclosure may be generally executed by the server 105. Accordingly, the distributed transaction management device based on the peer-to-peer mode provided by the embodiments of the present disclosure may be generally disposed in the server 105. The distributed transaction management method based on the peer-to-peer mode provided by the embodiment of the present disclosure may also be executed by a server or a server cluster different from the server 105 and capable of communicating with the

terminal devices

101, 102, 103 and/or the server 105. Accordingly, the distributed transaction management apparatus based on the peer-to-peer mode provided by the embodiment of the present disclosure may also be disposed in a server or a server cluster different from the server 105 and capable of communicating with the

terminal devices

101, 102, 103 and/or the server 105.

It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

The distributed transaction management method based on the peer-to-peer mode of the disclosed embodiment will be described in detail below with fig. 2 to 6 based on the scenario described in fig. 1.

The embodiment of the disclosure provides a distributed transaction management method based on a peer-to-peer mode, which is applied to at least one service node in a distributed transaction management system.

For example, the distributed transaction management system may include a plurality of service node clusters, each service node cluster may correspond to a service, such as a transfer service, and the like, and the service node may be one of the service nodes in one service node cluster.

Fig. 2 schematically shows one of the flowcharts of the distributed transaction management method based on the peer-to-peer mode according to the embodiment of the disclosure, and as shown in fig. 2, the distributed transaction management method of this embodiment includes steps S210 to S240, it should be noted that, although the steps in fig. 2 are shown in sequence as indicated by the arrow, the steps are not necessarily executed in sequence as indicated by the arrow. The steps are not performed in the exact order shown and may be performed in other orders unless explicitly stated herein. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, in different orders, and may be performed in turn or in alternation with other steps or at least some of the sub-steps or stages of other steps.

In step S210, a service version of the current service node is determined according to the preset version configuration information.

In the embodiment of the present disclosure, the version configuration information may be configured according to actual needs, for example, the version configuration information may include a version number, whether the version is a grayscale version, and the like. Optionally, after determining the service version, the service version may be stored in the memory, so that in the subsequent process, only the service version needs to be called from the memory, and thus step S210 does not need to be executed for multiple times to obtain the service version.

In step S220, a primary transaction is scanned from the service database according to the retry request and the service version, and the primary transaction includes version identification information corresponding to the service version. For example, one service node cluster may include a plurality of service nodes, where the plurality of service nodes include a plurality of service versions, each service version corresponds to at least one version identification information, and the version identification information corresponding to different service versions is different, for example, the service versions and the version identification information correspond to each other one by one.

At step S230, at least one branch transaction corresponding to the main transaction is extracted from the transaction database.

In the embodiment of the present disclosure, a branch transaction may refer to a transaction having an affiliation with a main transaction, for example, the main transaction is "transfer", and then at least two branch transactions corresponding to the main transaction are provided, wherein one branch transaction is payment and the other branch transaction is collection. For another example, if the main transaction is "send transfer message", then there are at least two branch transactions corresponding to the main transaction, where one branch transaction is a business transaction, i.e., "transfer" transaction, and the other branch transaction is "message send transaction". Of course, the main transaction and the branch transaction are not limited to the two examples, and may be determined according to actual needs, and embodiments of the present disclosure are not listed.

At step S240, at least one branch transaction is called according to the calling rule corresponding to the retry request to perform the retry operation.

In the embodiment of the present disclosure, the retry request may include, when the transaction fails, according to the retry request initiated by the exception handling mechanism, re-invoking the branch transaction according to the corresponding invocation rule through the retry request, so as to prevent the transaction failure due to an occasional reason.

In some embodiments, the retry request includes a first retry request generated in the traffic service retry phase, and optionally, the traffic service retry phase may include a phase of retrying the TCC two phases after the TCC two-phase failure, where the first retry request is a request of retrying the TCC two phases. The main transaction includes a main business transaction and a branch transaction includes a sub business transaction of a participant participating in the business transaction.

Fig. 3 schematically shows a second flowchart of a distributed transaction management method based on the peer-to-peer mode according to an embodiment of the present disclosure, and as shown in fig. 3, in some specific embodiments, the transaction management method further includes step S310 to step S330.

At step S310, at least one transaction is obtained, and a transaction record of the at least one transaction is determined.

In step S320, the service version of the current service node is determined according to the version configuration information, and version identification information corresponding to the service version is obtained.

In step S330, the main transaction is generated according to the transaction record and the version identification information, and is written into the service database.

In the embodiment of the present disclosure, a version configuration item versioning info may be added, when an initiator initiates a transaction, version identification information corresponding to a service version of a current service node is allocated to a transaction record of each transaction through the version configuration item, and then the version identification information is written into a service database as a main transaction of the transaction. In this way, primary transactions generated by service nodes having different service versions can be isolated from each other. When the master transaction is scanned from the service database according to the retry request and the service version, each service node only scans the master transaction corresponding to the service version.

In some embodiments, the number of the service nodes is multiple, and the multiple service nodes upgrade the service version by at least one of gray-scale distribution, rolling upgrade and blue-green distribution. That is, when a service node cluster is upgraded, some of the service nodes may be upgraded first, so as to implement smooth transition.

Fig. 4 schematically shows one of the flowcharts for invoking a branch transaction according to the embodiment of the present disclosure, and as shown in fig. 4, step S240 includes step S241.

In step S241, each extracted business sub-transaction is sequentially called to perform business service retry.

Taking the main business transaction as an e-commerce transaction as an example, a new service node and an old service node coexist in a service node group, wherein the old service node is referred to as a service node Y1, and the new service node is referred to as a service node Y2. For service node Y1, the participants participating in the e-commerce transaction (hereinafter the e-commerce transaction of service node Y1 is referred to as e-commerce transaction L1) may include participant M1, participant M2 and participant M3, the sub-business transaction of participant M1 is order transaction J1, the sub-business transaction of participant M2 is inventory transaction J2, and the sub-business transaction of participant M3 is account balance transaction J3. For service node Y2, the participants participating in the e-commerce transaction (hereinafter the e-commerce transaction of service node Y2 is referred to as e-commerce transaction L2) may include participant M1, participant M2, participant M3, and participant M4, the sub-business transaction of participant M1 being order transaction J1, the sub-business transaction of participant M2 being inventory transaction J2, the sub-business transaction of participant M3 being account balance transaction J3, and the sub-business transaction of participant M4 being loyalty transaction J3.

The service node Y1 will be explained first.

When a transaction is initiated, the service version Y11 of the current service node Y1 is determined according to the preset version configuration information.

In the TCC phase, all service checks are completed, necessary service resources are reserved, and service data such as calling methods related to E-commerce transaction L1, order transaction J1, inventory transaction J2 and account balance transaction J3 are stored in the memory of the current service node Y1 and the service database E. Optionally, before or during this step, the E-commerce transaction L1 may be written into the business database E together with the version identification information Y12 corresponding to the service version Y11.

When the TCC phase is successful, two phases are initiated for the transfer transaction L1, taking the Confirm phase as an example, at which point the order transaction J1, inventory transaction J2 and account balance transaction J3 associated with E-commerce transaction L1 are first queried from the business database E. Thereafter, order transaction J1, inventory transaction J2, and account balance transaction J3 are invoked in sequence for commit operations, e.g., order transaction J1 is invoked to record order information, inventory transaction J2 is invoked to "1" in an inventory record, account balance transaction J3 is invoked to make a deduction, etc. When the two phases succeed, i.e., the e-commerce transaction L1 executes successfully. When any one of the order transaction J1, inventory transaction J2, and account balance transaction J3 fails to commit, i.e., two phases are considered to fail, then a retry operation will be performed during the business service retry phase.

In the retry phase of the service, the service database E is scanned according to the first retry request and the service version Y11 of the current service node Y1 to obtain all the master transactions of the non-closed loop corresponding to the service version Y11 of the service node Y1 and initiate a retry, in other words, obtain the master service transaction including the version identification information Y12, that is, the E-commerce transaction L1 described above. Thereafter, each business sub-transaction is invoked in turn, specifically, order transaction J1, inventory transaction J2, and account balance transaction J3 are again invoked to perform a commit operation, e.g., order transaction J1 is invoked to record order information, inventory transaction J2 is invoked to "1" in an inventory record, account balance transaction J3 is invoked to make a debit, etc., to complete a retry operation. The master transaction that is not closed loop may refer to that at least one branch transaction corresponding to the master transaction fails.

The service node Y2 is explained below.

When a transaction is initiated, the service version Y21 of the current service node Y2 is determined according to the preset version configuration information.

In the TCC phase, all service checks are completed, necessary service resources are reserved, and service data such as calling methods related to E-commerce transaction L2, order transaction J1, inventory transaction J2, account balance transaction J3 and point transaction J4 are stored in the memory of current service node Y2 and in the service database E. Optionally, before or during this step, the E-commerce transaction L2 may be written into the business database E together with the version identification information Y22 corresponding to the service version Y21.

When the TCC phase is successful, two phases are initiated for the transfer transaction L2, taking the Confirm phase as an example, at which point the order transaction J1, inventory transaction J2, account balance transaction J3 and points transaction J4 associated with E-commerce transaction L2 are first queried from the transaction database E. Thereafter, order transaction J1, inventory transaction J2, account balance transaction J3, and points transaction J4 are invoked in sequence for commit operations, e.g., order transaction J1 is invoked to record order information, inventory transaction J2 is invoked to "1" in inventory records, account balance transaction J3 is invoked to make a debit, points transaction J4 is invoked to add points, etc. When the two phases succeed, i.e., the e-commerce transaction L2 executes successfully. When any one of the order transaction J1, the inventory transaction J2, the account balance transaction J3, and the credit transaction J4 fails to commit, i.e., the two-phase fails, then a retry operation will be performed during the business service retry phase.

In the retry phase of the service, the service database E is scanned according to the first retry request and the service version Y21 of the current service node Y2 to obtain all the master transactions of the non-closed loop corresponding to the service version Y21 of the service node Y2 and initiate a retry, in other words, obtain the master service transaction including the version identification information Y22, that is, the E-commerce transaction L2 described above. Thereafter, each business sub-transaction is invoked in turn, specifically, order transaction J1, inventory transaction J2, account balance transaction J3, and credit transaction J4 are invoked again to perform a commit operation, e.g., order transaction J1 is invoked to record order information, inventory transaction J2 is invoked to "1" in the inventory record, account balance transaction J3 is invoked to make a debit, credit transaction J4 is invoked to add credit, etc., to complete a retry operation.

Therefore, when the service node group is upgraded in a mode such as the gray release, the situation that the new and old service nodes share one transaction data in the service database E can not occur. Specifically, for the service node Y1 and the service node Y2, in the service retry stage, both of them can scan out the E-commerce transaction corresponding to them from the service database E, so as to perform retry operation, and the case that the service node Y1 scans the E-commerce transaction L2 or the service node Y2 scans the E-commerce transaction L1 does not occur, so that the problem of retry failure caused by this is avoided, and further, a smoother upgrade process is realized.

In some embodiments, the retry request comprises a second retry request generated during a message service retry phase. Optionally, the message service retry phase may include: after the message transmission fails, retry the message transmission, and the second retry request is also the request for retry the message transmission. The main transaction comprises a message service transaction, the number of branch transactions is multiple, and the multiple branch transactions comprise: at least one primary business transaction corresponding to the message service transaction, and a message send transaction corresponding to the at least one primary business transaction.

Fig. 5 schematically illustrates a second flowchart of invoking a branch transaction according to an embodiment of the present disclosure, and as shown in fig. 5, step S240 includes step S242.

In step S242, it is determined whether the main service transaction is successfully invoked, and if so, the message sending transaction is invoked to retry the message service; if not, no retry of message service is performed.

Still taking the service node group described above as an example, the difference is that in this example, the main transaction is a message service transaction, and the branch transaction includes a main service transaction (e.g., an e-commerce transaction as described above) and a message sending transaction. Hereinafter, the message service transaction of the service node Y1 is referred to as a message service transaction Q1, and the message service transaction of the service node Y2 is referred to as a message service transaction Q2. The branch transaction corresponding to message service transaction Q1 includes: e-commerce transaction L1 and messaging transaction P1. The branch transaction corresponding to message service transaction Q2 includes: e-commerce transaction L2, messaging transaction P1 and messaging transaction P2. The e-commerce affairs and the related contents thereof are as described above and are not described herein again.

The service node Y1 will be explained first.

In the message service invocation phase, the E-commerce transaction L1 and the messaging transaction P1 related to the message service transaction Q1 may be queried from the traffic database E. Optionally, the message service transaction Q1 may be written into the business database E along with version identification information Y12 corresponding to the service version Y11.

Thereafter, when the e-commerce transaction L1 is successfully executed, the message sending transaction P1 is invoked to send information. For example, the message service P1 may be invoked to send a message to the user that the user has "placed an order". When the message service invocation P1 fails to invoke and fails to successfully send a message to the user, a retry may be made during the message service retry phase.

In the message service retry phase, the traffic database E is scanned according to the second retry request and the service version Y11 of the current service node Y1 to obtain all the master transactions of the non-closed loop corresponding to the service version Y11 of the service node Y1 and initiate a retry, in other words, to obtain the message service transaction including the version identification information Y12, that is, the message service transaction Q1 described above.

Then, whether the E-commerce transaction L1 is executed successfully is judged, and when the E-commerce transaction L1 is executed successfully, the message sending transaction P1 is called again to retry the message service; when the e-commerce transaction L1 fails to execute, then the messaging transaction P1 is not invoked.

The service node Y2 is explained below.

In the message service invocation phase, the E-commerce transaction L1, the messaging transaction P1 and the messaging transaction P2 related to the message service transaction Q2 may be queried from the traffic database E. Optionally, the message service transaction Q2 may be written into the business database E along with version identification information Y22 corresponding to the service version Y21.

After that, after the e-commerce transaction L2 is successfully executed, the messaging transaction P1 and the messaging transaction P2 are invoked to send information. For example, messaging service P1 may be invoked to send a message to the user telling the user "has placed an order," and messaging service P2 may be invoked to send a message to the user telling the user "has earned points. When either of the message service invocation P1 and the message invocation service P2 failed to invoke and fail to successfully send a message to the user, a retry may be made in the message service retry phase.

In the message service retry phase, the traffic database E is scanned according to the second retry request and the service version Y21 of the current service node Y2 to obtain all the master transactions of the non-closed loop corresponding to the service version Y21 of the service node Y2 and initiate a retry, in other words, to obtain the message service transaction including the version identification information Y22, that is, the message service transaction Q2 described above.

Then, whether the E-commerce transaction L2 is executed successfully is judged, and when the E-commerce transaction L2 is executed successfully, the message sending transaction P1 and the message sending transaction P2 are called again to retry the message service; when the e-commerce transaction L2 fails to execute, then the messaging transaction P1 and the messaging transaction P2 are not invoked.

Therefore, when the service node group is upgraded in a mode such as the gray release, the situation that the new and old service nodes share one transaction data in the service database E can not occur. Specifically, for the service node Y1 and the service node Y2, in the message service retry stage, both can scan the message service transaction corresponding to each service node from the service database E, so as to perform retry operation, and the situation that the service node Y1 scans the message service transaction Q2 or the service node Y2 scans the message service transaction Q1 does not occur, so that the problem of retry failure caused by this is avoided, and further, a smoother upgrade process is realized.

Fig. 6 schematically shows a third flowchart of a distributed transaction management method based on the peer-to-peer mode according to an embodiment of the present disclosure, and as shown in fig. 6, in some specific embodiments, the transaction management method further includes step S410 and step S420.

In step S410, an exception scanning task lock corresponding to the current service node is obtained from at least one exception scanning task lock.

In step S420, after the abnormal scanning task lock corresponding to the current service node is acquired, step S220 is executed, that is, the main transaction is scanned from the service database according to the retry request and the service version.

In the embodiment of the present disclosure, the abnormal scanning task lock may include an exclusive lock, that is, only the service node that acquires the abnormal scanning task lock is allowed to execute step S220, so as to prevent problems, such as a conflict, that occur due to the scanning of the service database E by multiple service nodes in the same time.

Optionally, in this embodiment of the present disclosure, a manner of the abnormal scanning task lock may be determined according to actual needs, for example, a contention mechanism may be used to enable a plurality of service nodes to preempt the abnormal scanning task lock, so that the service node that preempts the abnormal scanning task lock executes step S220.

In some specific embodiments, the number of the service nodes is multiple, in the multiple service nodes, the service versions of at least two service nodes are different, the number of the exception scanning task locks is multiple, one service version corresponds to at least one exception scanning task lock, and the exception scanning task locks corresponding to different service versions are different.

In the embodiment of the present disclosure, as described above, since the main transactions generated by the service nodes with different service versions are isolated from each other, the exception scanning task lock may be configured to enable a plurality of service nodes with different service versions to perform scanning simultaneously. For example, for the service node Y1 and the service node Y2, when scanning the master transaction from the service database according to the retry request and the service version, both will only scan the master transaction corresponding to the service version, and there is no conflict between the two when scanning the service database, so two exception scanning task locks can be configured to make the service node Y1 and the service node Y2 scan simultaneously, so as to improve the processing efficiency.

According to the distributed transaction management method based on the same-library mode, the disclosure also provides a distributed transaction management device based on the same-library mode, which is applied to at least one service node in the distributed transaction management system. The apparatus will be described in detail below with reference to fig. 8.

Fig. 7 schematically shows a block diagram of a distributed transaction management device based on the peer-to-peer mode according to an embodiment of the present disclosure, and as shown in fig. 7, a distributed transaction management device 700 based on the peer-to-peer mode of this embodiment includes a service version confirmation module 710, a first scanning module 720, a second scanning module 730, and a calling module 740.

The service version confirmation module 710 is configured to determine a service version of the current service node according to preset version configuration information. In an embodiment, the service version confirmation module 710 may be configured to perform the step S210 described above, which is not described herein again.

The first scanning module 720 is configured to scan a primary transaction from the service database according to the retry request and the service version, where the primary transaction includes version identification information corresponding to the service version. In an embodiment, the first scanning module 720 may be configured to perform the step S220 described above, which is not described herein again.

The second scanning module 730 is configured to extract at least one branch transaction corresponding to the main transaction from the transaction database. In an embodiment, the second scanning module 730 can be configured to perform the step S230 described above, which is not described herein again.

The invoking module 740 is configured to invoke at least one branch transaction according to an invoking rule corresponding to the retry request to perform a retry operation. In an embodiment, the invoking module 740 may be configured to perform the step S240 described above, which is not described herein again.

By adopting the distributed transaction management device based on the same-base mode of the embodiment of the disclosure, when a retry request is received, the service version of the current service node can be determined first, and then the main transaction including the version identification information corresponding to the service version is extracted from the service database.

According to an embodiment of the present disclosure, any plurality of the service version confirmation module 710, the first scanning module 720, the second scanning module 730, and the calling module 740 may be combined and implemented in one module, or any one of them may be split into a plurality of modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of the other modules and implemented in one module. According to an embodiment of the present disclosure, at least one of the service version confirmation module 710, the first scanning module 720, the second scanning module 730, and the calling module 740 may be implemented at least partially as a hardware circuit, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a system on a chip, a system on a substrate, a system on a package, an Application Specific Integrated Circuit (ASIC), or may be implemented in hardware or firmware in any other reasonable manner of integrating or packaging a circuit, or in any one of three implementations of software, hardware, and firmware, or in any suitable combination of any of them. Alternatively, at least one of the service version confirmation module 710, the first scanning module 720, the second scanning module 730, and the calling module 740 may be at least partially implemented as a computer program module that, when executed, may perform a corresponding function.

When the service node group is upgraded in a manner such as the gray release, a new service node and an old service node do not share one transaction data in the service database E. Thereby avoiding the problem of retry failure caused thereby and further realizing a smoother upgrade process.

Fig. 8 schematically shows a block diagram of an electronic device adapted to implement a peer-based mode distributed transaction management method according to an embodiment of the disclosure, and as shown in fig. 8, an electronic device 800 according to an embodiment of the disclosure includes a processor 801 which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)802 or a program loaded from a storage portion 808 into a Random Access Memory (RAM) 803. The processor 801 may include, for example, a general purpose microprocessor (e.g., CPU), an instruction set processor and/or associated chipset, and/or a special purpose microprocessor (e.g., Application Specific Integrated Circuit (ASIC)), among others. The processor 801 may also include onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flows according to embodiments of the present disclosure.

In the RAM 803, various programs and data necessary for the operation of the electronic apparatus 800 are stored. The processor 801, the ROM 802, and the RAM 803 are connected to each other by a bus 804. The processor 801 performs various operations of the method flows according to the embodiments of the present disclosure by executing programs in the ROM 802 and/or RAM 803. Note that the programs may also be stored in one or more memories other than the ROM 802 and RAM 803. The processor 801 may also perform various steps of the method flows according to embodiments of the present disclosure by executing programs stored in the one or more memories.

Electronic device 800 may also include input/output (I/O) interface 805, input/output (I/O) interface 805 also connected to bus 804, according to an embodiment of the present disclosure. Electronic device 800 may also include one or more of the following components connected to I/O interface 805: an input portion 806 including a keyboard, a mouse, and the like; an output section 807 including a signal such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 808 including a hard disk and the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. A drive 810 is also connected to the I/O interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as necessary, so that a computer program read out therefrom is mounted on the storage section 808 as necessary.

The present disclosure also provides a computer-readable storage medium, which may be contained in the apparatus/device/system described in the above embodiments; or may exist separately and not be assembled into the device/apparatus/system. The computer readable storage medium carries one or more programs which, when executed, implement a peer-to-peer schema-based distributed transaction management method according to an embodiment of the disclosure.

According to embodiments of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example but is not limited to: 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), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. For example, according to embodiments of the present disclosure, a computer-readable storage medium may include the ROM 802 and/or RAM 803 described above and/or one or more memories other than the ROM 802 and RAM 803.

Embodiments of the present disclosure also include a computer program product comprising a computer program containing program code for performing the method illustrated in the flow chart. When the computer program product runs in a computer system, the program code is used for causing the computer system to realize the distributed transaction management method based on the same-library mode provided by the embodiment of the disclosure.

The computer program performs the above-described functions defined in the system/apparatus of the embodiments of the present disclosure when executed by the processor 801. The systems, apparatuses, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the present disclosure.

In one embodiment, the computer program may be hosted on a tangible storage medium such as an optical storage device, a magnetic storage device, or the like. In another embodiment, the computer program may also be transmitted in the form of a signal on a network medium, distributed, downloaded and installed via communication section 809, and/or installed from removable media 811. The computer program containing program code may be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 809 and/or installed from the removable medium 811. The computer program, when executed by the processor 801, performs the above-described functions defined in the system of the embodiments of the present disclosure. The systems, devices, apparatuses, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the present disclosure.

In accordance with embodiments of the present disclosure, program code for executing computer programs provided by embodiments of the present disclosure may be written in any combination of one or more programming languages, and in particular, these computer programs may be implemented using high level procedural and/or object oriented programming languages, and/or assembly/machine languages. The programming language includes, but is not limited to, programming languages such as Java, C + +, python, the "C" language, or the like. The program code may execute entirely on the user computing device, partly on the user device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Those skilled in the art will appreciate that various combinations and/or combinations of features recited in the various embodiments and/or claims of the present disclosure can be made, even if such combinations or combinations are not expressly recited in the present disclosure. In particular, various combinations and/or combinations of the features recited in the various embodiments and/or claims of the present disclosure may be made without departing from the spirit or teaching of the present disclosure. All such combinations and/or associations are within the scope of the present disclosure.

The embodiments of the present disclosure have been described above. However, these examples are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Although the embodiments are described separately above, this does not mean that the measures in the embodiments cannot be used in advantageous combination. The scope of the disclosure is defined by the appended claims and equivalents thereof. Various alternatives and modifications can be devised by those skilled in the art without departing from the scope of the present disclosure, and such alternatives and modifications are intended to be within the scope of the present disclosure.

Claims

1. A distributed transaction management method based on a library-sharing mode is applied to at least one service node in a distributed transaction management system, and is characterized in that the transaction management method comprises the following steps:

2. The transaction management method of claim 1, wherein the retry request comprises a first retry request generated during a retry phase of a business service, the main transaction comprises a main business transaction, and one of the branch transactions comprises a sub business transaction of a participant participating in the business transaction;

3. The transaction management method of claim 1, wherein the retry request comprises a second retry request generated during a message service retry phase, wherein the primary transaction comprises a message service transaction, wherein the number of branch transactions is multiple, and wherein the multiple branch transactions comprise: at least one main transaction corresponding to the message service transaction, and a message sending transaction corresponding to the at least one main transaction;

4. The transaction management method of claim 1, further comprising:

5. The transaction management method of claim 1, further comprising:

6. The transaction management method according to claim 5, wherein the number of the service nodes is multiple, the service versions of at least two service nodes in the multiple service nodes are different, the number of the exception scanning task locks is multiple, one service version corresponds to at least one exception scanning task lock, and the exception scanning task locks corresponding to different service versions are different.

7. The transaction management method of claim 1, wherein the number of the service nodes is multiple, and the multiple service nodes perform the upgrade of the service version by at least one of gray scale distribution, rolling upgrade and blue-green distribution.

8. A distributed transaction management device based on a peer-to-peer mode is applied to at least one service node in a distributed transaction management system, and is characterized in that the distributed transaction management device comprises:

9. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the distributed transaction management method of any of claims 1-7.

10. A computer readable storage medium having stored thereon executable instructions which, when executed by a processor, cause the processor to perform a distributed transaction management method according to any of claims 1 to 7.

11. A computer program product comprising a computer program which, when executed by a processor, implements a distributed transaction management method according to any of claims 1 to 7.