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

Abstract

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

Description

Technical Field

[0001] The present disclosure relates to the field of distributed transaction technology, and in particular to a transaction management method, apparatus, device, medium and program product based on a same-library mode. Background Art

[0002] A transaction is an operation sequence consisting of one or more resource management operations. A distributed transaction is a transaction in which the operations in the operation sequence involve multiple databases (DB).

[0003] Currently, in the same database mode of distributed transactions, transaction data is usually stored in the database on the business application side, which can reduce network transmission links and improve work performance. However, when the service node cluster is upgraded, the new and old service nodes may share transaction data in the same database, which will cause some retry operations to fail, such as the retry of the TCC (Try-Confirm-Cancel) phase. Summary of the invention

[0004] In view of the above problems, the present disclosure provides a transaction management method, apparatus, device, medium and program product based on the same-library mode.

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

[0006] Determine the service version of the current service node according to the preset version configuration information;

[0007] Scanning a main transaction from a business database according to the retry request and the service version, wherein the main transaction includes version identification information corresponding to the service version;

[0008] Extracting at least one branch transaction corresponding to the main transaction from the business database;

[0009] The at least one branch transaction is called according to a calling rule corresponding to the retry request to perform a retry operation.

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

[0011] The calling of the at least one branch transaction according to the calling rule corresponding to the retry request to perform a retry operation includes:

[0012] Each of the extracted business sub-transactions is called in sequence to retry the business service.

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

[0014] The calling of the at least one branch transaction according to the calling rule corresponding to the retry request to perform a retry operation includes:

[0015] When the main business transaction is successfully called, the message sending transaction is called to retry the message service.

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

[0017] Obtaining at least one transaction and determining a transaction record of the at least one transaction;

[0018] Determine the service version of the current service node according to the version configuration information, and obtain version identification information corresponding to the service version;

[0019] The main transaction is generated according to the transaction record and the version identification information, and is written into the business database.

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

[0021] Acquire an exception scanning task lock corresponding to the current service node from at least one exception scanning task lock;

[0022] After the exception scanning task lock corresponding to the current service node is acquired, the step of scanning the main transaction from the business database according to the retry request and the service version is performed.

[0023] According to an embodiment of the present disclosure, there are multiple service nodes, and among the multiple service nodes, at least two service nodes have different service versions. There are multiple exception scanning task locks, and one service version corresponds to at least one exception scanning task lock, and different service versions correspond to different exception scanning task locks.

[0024] According to an embodiment of the present disclosure, there are multiple service nodes, and the multiple service nodes upgrade the service version using at least one of grayscale release, rolling upgrade, and blue-green release.

[0025] A second aspect of the present disclosure provides a distributed transaction management device based on the same database mode, which is applied to at least one service node in a distributed transaction management system, and includes:

[0026] A service version confirmation module is used to determine the service version of the current service node according to the preset version configuration information;

[0027] A first scanning module, configured to scan a main transaction from a business database according to the retry request and the service version, wherein the main transaction includes version identification information corresponding to the service version;

[0028] A second scanning module, configured to scan at least one branch transaction corresponding to the main transaction from the business database;

[0029] The calling module is used to call the at least one branch transaction according to a calling rule corresponding to the retry request to perform a retry operation.

[0030] The third aspect of the present disclosure provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the above-mentioned distributed transaction management method based on the same-library mode.

[0031] The fourth aspect of the present disclosure further provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, causes the processor to execute the above-mentioned distributed transaction management method based on the same-library mode.

[0032] The fifth aspect of the present disclosure also provides a computer program product, including a computer program, which implements the above-mentioned distributed transaction management method based on the same-library mode when executed by a processor.

[0033] One or more of the above embodiments have the following advantages or beneficial effects:

[0034] 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 can be extracted from the business database. In this way, the new and old service nodes can respectively scan the main transactions corresponding to their respective service versions, and then retry the operation. In this way, the problem of the new and old service nodes scanning the same main transaction is avoided, and further, the problem of the retry operation failure caused by this is avoided. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The above contents and other purposes, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0036] Figure 1 The application scenario diagram of the distributed transaction management method, apparatus, device, storage medium and program product based on the same-library mode according to the embodiment of the present disclosure is schematically shown;

[0037] Figure 2 One of the flow charts of the distributed transaction management method based on the same-library mode according to an embodiment of the present disclosure is schematically shown;

[0038] Figure 3 The second flowchart of the distributed transaction management method based on the same database mode according to the embodiment of the present disclosure is schematically shown;

[0039] Figure 4 One of the flow charts of calling a branch transaction according to an embodiment of the present disclosure is schematically shown;

[0040] Figure 5 The second flowchart of calling a branch transaction according to an embodiment of the present disclosure is schematically shown;

[0041] Figure 6 The third flowchart of the distributed transaction management method based on the same database mode according to the embodiment of the present disclosure is schematically shown;

[0042] Figure 7 The structure block diagram of the distributed transaction management device based on the same database mode according to the embodiment of the present disclosure is schematically shown;

[0043] Figure 8 A block diagram of an electronic device suitable for implementing a distributed transaction management method based on the same-library mode according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0044] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0045] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "include", "comprising", etc. used herein indicate the existence of the features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.

[0046] All terms (including technical and scientific terms) used herein have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification, and should not be interpreted in an idealized or overly rigid manner.

[0047] When using expressions such as "at least one of A, B, and C, etc.", they should generally be interpreted according to the meaning of the expression commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0048] The transaction management method and device based on the same-database model disclosed in the present invention can be used in the distributed transaction business in the financial field, and can also be used in any field other than the financial field. The application field of the transaction management method and device based on the same-database model disclosed in the present invention is not limited.

[0049] In the technical solution of the present disclosure, the collection, storage, use, processing, transmission, provision, disclosure and application of user personal information involved comply with the provisions of relevant laws and regulations, take necessary confidentiality measures, and do not violate public order and good morals.

[0050] Currently, TCC technology is usually used to process distributed transactions. The processing process of TCC technology includes two stages, wherein the first stage is the Try stage, and the second stage is the Confirm or Cancel stage.

[0051] Try phase: Complete all business checks and reserve necessary business resources. It is necessary to ensure that Confirm will succeed after the Try phase is completed.

[0052] Confirm phase: The actual business logic is executed without any business checks, and only the business resources reserved in the Try phase are used.

[0053] Cancel phase: releases the business resources reserved in the Try phase.

[0054] When the second phase of Try fails, a retry operation is initiated.

[0055] Exemplarily, some or all of the steps in the above process can be deployed in at least one service node in a service node cluster composed of multiple service nodes. For a transaction, such as a transfer service (hereinafter referred to as the main transaction S), it calls two subtransactions, namely subtransaction A and subtransaction B. In the same database mode, in the first stage, all business checks are completed, necessary business resources are reserved, and business data such as calling methods related to the main transaction S, subtransaction A and subtransaction B are stored in the memory of the service node X and the business database D. When the first stage is successful, the second stage is initiated for the main transaction S. Taking the Confirm stage as an example, at this time, the subtransaction A and subtransaction B corresponding to the main transaction S are first queried from the business database D, and then the subtransaction A and subtransaction B are called in sequence to perform the commit operation. When the commit of subtransaction A or subtransaction B fails, a retry operation will be performed in the retry stage. At this time, the business database D will be scanned to obtain all unclosed main transactions and initiate a retry, where the unclosed loop can refer to the failure of the commit operation of at least one subtransaction corresponding to the main transaction.

[0056] Since the same database mode is adopted, when the service node cluster is updated, there may be a situation where the new and old service nodes (the updated service nodes and the service nodes before the update) share the transaction data in a business database.

[0057] For example, for a service node that has not been updated (hereinafter referred to as service node X1), the main transaction S calls subtransaction A and subtransaction B respectively; for a service node that has been updated (hereinafter referred to as service node X2), the main transaction S calls subtransaction A, subtransaction B, and subtransaction C respectively. When performing a retry operation in the retry phase, service node X2 can perform a normal retry operation, while for service node X1, when it scans the business database D, it will scan the main transaction S generated by service node X2, and then obtain the transaction data including the main transaction S calling subtransaction A, subtransaction B, and subtransaction C. Since the memory of service node X1 only records the business data related to the main transaction S calling subtransaction A and subtransaction B respectively, and there is no business data related to subtransaction C, at this time, a retry failure will occur.

[0058] In view of this, an embodiment of the present disclosure provides a distributed transaction management method based on the same database mode, 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 the preset version configuration information. Scanning a main transaction from a business database according to a retry request and a service version, the main transaction includes version identification information corresponding to the service version. Extracting at least one branch transaction corresponding to the main transaction from the business database. Calling at least one branch transaction according to a calling rule corresponding to the retry request to perform a retry operation.

[0059] By adopting the distributed transaction management method based on the same-library mode of the embodiment of the present 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 can be extracted from the business database. In this way, the new and old service nodes can respectively scan the main transactions corresponding to their respective service versions, and then retry the operation. In this way, the problem of the new and old service nodes scanning the same main transaction is avoided, and further, the problem of the failure of the retry operation caused by this is avoided.

[0060] Figure 1 The application scenario diagram of the distributed transaction management method, apparatus, device, storage medium and program product based on the same-library mode according to an embodiment of the present disclosure is schematically shown.

[0061] like Figure 1 As shown, the network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0062] Users can use terminal devices 101, 102, 103 to interact with server 105 through network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only examples).

[0063] The terminal devices 101 , 102 , and 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0064] The server 105 may be a server that provides various services, such as a background management server (only an example) that provides support for websites browsed by users using the terminal devices 101, 102, and 103. The background management server may analyze and process the received data such as user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal device.

[0065] It should be noted that the distributed transaction management method based on the same database mode provided in the embodiment of the present disclosure can generally be executed by the server 105. Accordingly, the distributed transaction management device based on the same database mode provided in the embodiment of the present disclosure can generally be set in the server 105. The distributed transaction management method based on the same database mode provided in the embodiment of the present disclosure can also be executed by a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105. Accordingly, the distributed transaction management device based on the same database mode provided in the embodiment of the present disclosure can also be set in a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105.

[0066] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to the implementation requirements.

[0067] The following will be based on Figure 1 The scene described by Figure 2 to Figure 6 The distributed transaction management method based on the same-library mode of the disclosed embodiment is described in detail.

[0068] An embodiment of the present disclosure provides a distributed transaction management method based on the same-library mode, which is applied to at least one service node in a distributed transaction management system.

[0069] Exemplarily, the distributed transaction management system may include multiple service node clusters, each service node cluster may correspond to a service, such as a transfer service, etc., and the above-mentioned service node may be one of the service nodes in a service node cluster.

[0070] Figure 2 The following schematically shows one of the flow charts of the distributed transaction management method based on the same database mode according to an embodiment of the present disclosure. Figure 2 As shown, the distributed transaction management method of this embodiment includes steps S210 to S240. It should be noted that although Figure 2The steps in the figure are shown in sequence as indicated by the arrows, but the steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of the steps, and they can be executed in other orders. Moreover, at least some of the steps in the figure may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a part of the sub-steps or stages of other steps.

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

[0072] In the embodiment of the present disclosure, the version configuration information can be configured according to actual needs, for example, the version configuration information may include a version number, whether it is a grayscale version, etc. Optionally, after determining the service version, the service version may be stored in a memory, so that in subsequent processes, it is only necessary to retrieve the service version from the memory, thereby eliminating the need to perform step S210 multiple times to obtain the service version.

[0073] In step S220, according to the retry request and the service version, the main transaction is scanned from the business database, and the main transaction includes version identification information corresponding to the service version. For example, a service node cluster may include multiple service nodes, and the multiple service nodes include multiple service versions. Each service version corresponds to at least one version identification information, and different service versions correspond to different version identification information. For example, the service version and the version identification information correspond one to one.

[0074] In step S230, at least one branch transaction corresponding to the main transaction is extracted from the business database.

[0075] In the embodiments of the present disclosure, a branch transaction may refer to a transaction that is subordinate to a main transaction. For example, if the main transaction is "transfer", then there are at least two branch transactions corresponding to the main transaction, one of which is payment and the other 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, one of which is a business transaction, that is, a "transfer" transaction, and the other is a "message sending transaction". Of course, the main transaction and the branch transaction are not limited to the above two examples, and can be determined according to actual needs. The embodiments of the present disclosure will not list them one by one.

[0076] In step S240, at least one branch transaction is called according to a calling rule corresponding to the retry request to perform a retry operation.

[0077] By adopting the distributed transaction management method based on the same-library mode of the embodiment of the present 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 can be extracted from the business database. In this way, the new and old service nodes can respectively scan the main transactions corresponding to their respective service versions, and then retry the operation. In this way, the problem of the new and old service nodes scanning the same main transaction is avoided, and further, the problem of the failure of the retry operation caused by this is avoided.

[0078] In the disclosed embodiment, the retry request may include, when a transaction fails, a retry request initiated according to an exception handling mechanism, through which the branch transaction is called again according to corresponding calling rules to prevent transaction failure due to incidental reasons.

[0079] In some specific embodiments, the retry request includes a first retry request generated in a business service retry phase. Optionally, the business service retry phase may include a phase of retrying the TCC phase 2 after the TCC phase 2 fails. The first retry request is also a request to retry the TCC phase 2. The main transaction includes the main business transaction, and a branch transaction includes a sub-business transaction of a participant participating in the business transaction.

[0080] Figure 3 The second flowchart of the distributed transaction management method based on the same database mode according to the embodiment of the present disclosure is schematically shown. Figure 3 As shown, in some specific embodiments, the transaction management method further includes steps S310 to S330.

[0081] In step S310, at least one transaction is obtained, and a transaction record of the at least one transaction is determined.

[0082] 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 acquired.

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

[0084] In the disclosed embodiment, a version configuration item versionInfo may be added. When the initiator initiates a transaction, the version identification information corresponding to the service version of the current service node is assigned to the transaction record of each transaction through the version configuration item, and then written into the business database as the main transaction of this transaction. In this way, the main transactions generated by service nodes with different service versions can be isolated from each other. When scanning the main transaction from the business database according to the retry request and service version, each service node will only scan the main transaction corresponding to its service version.

[0085] In some specific embodiments, there are multiple service nodes, and the multiple service nodes use at least one of grayscale release, rolling upgrade, and blue-green release to upgrade the service version. That is, when upgrading a service node cluster, some of the service nodes can be upgraded first, so as to achieve a smooth transition.

[0086] Figure 4 A flowchart of calling a branch transaction according to an embodiment of the present disclosure is schematically shown. Figure 4 As shown, step S240 includes step S241.

[0087] In step S241, each extracted business sub-transaction is called in sequence to perform a business service retry.

[0088] Taking the e-commerce transaction as the main business transaction as an example, in a service node group, there are both new and old service nodes, wherein the old service node is referred to as service node Y1 below, and the new service node is referred to as 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 is order transaction J1, the sub-business transaction of participant M2 is inventory transaction J2, the sub-business transaction of participant M3 is account balance transaction J3, and the sub-business transaction of participant M4 is point transaction J3.

[0089] The service node Y1 is first described below.

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

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

[0092] When the first stage of TCC is successful, the second stage is initiated for the transfer transaction L1. Taking the Confirm stage as an example, at this time, the order transaction J1, inventory transaction J2 and account balance transaction J3 related to the e-commerce transaction L1 are first queried from the business database E. After that, the order transaction J1, inventory transaction J2 and account balance transaction J3 are called in sequence to perform submission operations. For example, the order transaction J1 is called to record the order information, the inventory transaction J2 is called to add "-1" to the inventory record, and the account balance transaction J3 is called to deduct money, etc. When the second stage is successful, it means that the e-commerce transaction L1 is executed successfully. When any of the order transaction J1, inventory transaction J2 and account balance transaction J3 fails to submit, the second stage is considered to have failed. After that, a retry operation will be performed in the business service retry stage.

[0093] In the business service retry phase, the business database E is scanned according to the first retry request and the service version Y11 of the current service node Y1 to obtain all unclosed main transactions corresponding to the service version Y11 of the service node Y1 and initiate a retry. In other words, the main business transaction including the version identification information Y12 is obtained, that is, the e-commerce transaction L1 mentioned above. After that, each business sub-transaction is called in sequence. Specifically, the order transaction J1, inventory transaction J2 and account balance transaction J3 are called again to perform a commit operation. For example, the order transaction J1 is called to record the order information, the inventory transaction J2 is called to add "-1" to the inventory record, and the account balance transaction J3 is called to deduct money, etc., so as to complete the retry operation. Among them, an unclosed main transaction may refer to the failure of at least one branch transaction corresponding to the main transaction.

[0094] The service node Y2 is described below.

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

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

[0097] When the first stage of TCC is successful, the second stage is initiated for the transfer transaction L2. Taking the Confirm stage as an example, at this time, the order transaction J1, inventory transaction J2, account balance transaction J3 and point transaction J4 related to the e-commerce transaction L2 are first queried from the business database E. After that, the order transaction J1, inventory transaction J2, account balance transaction J3 and point transaction J4 are called in sequence to perform submission operations. For example, the order transaction J1 is called to record the order information, the inventory transaction J2 is called to add "-1" to the inventory record, the account balance transaction J3 is called to deduct money, and the point transaction J4 is called to add points. When the second stage is successful, it means that the e-commerce transaction L2 is executed successfully. When any of the order transaction J1, inventory transaction J2, account balance transaction J3 and point transaction J4 fails to submit, it is considered that the second stage has failed. After that, a retry operation will be performed in the business service retry stage.

[0098] In the business service retry phase, the business 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 unclosed main transactions corresponding to the service version Y21 of the service node Y2 and initiate a retry. In other words, the main business transaction including the version identification information Y22 is obtained, that is, the e-commerce transaction L2 mentioned above. After that, each business sub-transaction is called in sequence, specifically, the order transaction J1, inventory transaction J2, account balance transaction J3 and points transaction J4 are called again to perform a submission operation, for example, the order transaction J1 is called to record the order information, the inventory transaction J2 is called to "-1" in the inventory record, the account balance transaction J3 is called to deduct money, the points transaction J4 is called to add points, etc., so as to complete the retry operation.

[0099] It can be seen from this that when the service node group is upgraded by the grayscale release method described above, the new and old service nodes will not share a copy of the transaction data in the business database E. Specifically, for service node Y1 and service node Y2, during the business retry phase, both can scan the e-commerce transactions corresponding to each other from the business database E to perform the retry operation, and there will be no situation where service node Y1 scans the e-commerce transaction L2 or service node Y2 scans the e-commerce transaction L1, thereby avoiding the problem of retry failure caused by this, and further achieving a smoother upgrade process.

[0100] In some specific embodiments, the retry request includes a second retry request generated in the message service retry phase. Optionally, the message service retry phase may include: a phase of retrying the message sending after the message sending fails, and the second retry request is also a request to retry the message sending. The main transaction includes a message service transaction, and the number of branch transactions is multiple, and the multiple branch transactions include: at least one main business transaction corresponding to the message service transaction, and a message sending transaction corresponding to at least one main business transaction.

[0101] Figure 5 The second flowchart of calling a branch transaction according to an embodiment of the present disclosure is schematically shown. Figure 5 As shown, step S240 includes step S242.

[0102] In step S242, it is determined whether the main business transaction is successfully called. If so, the message sending transaction is called to retry the message service; if not, the message service is not retried.

[0103] The following still takes the service node group mentioned above as an example. The difference is that in this example, the main transaction is a message service transaction, and the branch transactions include the main business transaction (such as the e-commerce transaction mentioned above) and the message sending transaction. The message service transaction of service node Y1 is referred to as message service transaction Q1, and the message service transaction of service node Y2 is referred to as message service transaction Q2. The branch transactions corresponding to the message service transaction Q1 include: e-commerce transaction L1 and message sending transaction P1. The branch transactions corresponding to the message service transaction Q2 include: e-commerce transaction L2, message sending transaction P1 and message sending transaction P2. Among them, the e-commerce transaction and its related contents are as described above and will not be repeated here.

[0104] The service node Y1 is first described below.

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

[0106] In the message service call phase, the e-commerce transaction L1 and the message sending transaction P1 related to the message service transaction Q1 can be queried from the business database E. Optionally, the message service transaction Q1 can be written into the business database E together with the version identification information Y12 corresponding to the service version Y11.

[0107] Afterwards, when the e-commerce transaction L1 is successfully executed, the message sending transaction P1 is called to send information. For example, the message service P1 can be called to send a message to the user to inform the user that "the order has been placed". When the message service call P1 fails and fails to successfully send a message to the user, a retry can be performed in the message service retry phase.

[0108] During the message service retry phase, the business database E is scanned according to the second retry request and the service version Y11 of the current service node Y1 to obtain all unclosed main transactions corresponding to the service version Y11 of the service node Y1 and initiate a retry. In other words, the message service transaction including the version identification information Y12 is obtained, that is, the message service transaction Q1 mentioned above.

[0109] Afterwards, it is determined whether the e-commerce transaction L1 is executed successfully. 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, the message sending transaction P1 is not called.

[0110] The service node Y2 is described below.

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

[0112] In the message service call phase, the e-commerce transaction L1, message sending transaction P1 and message sending transaction P2 related to the message service transaction Q2 can be queried from the business database E. Optionally, the message service transaction Q2 can be written into the business database E together with the version identification information Y22 corresponding to the service version Y21.

[0113] Afterwards, when the e-commerce transaction L2 is successfully executed, the message sending transaction P1 and the message sending transaction P2 are called to send information. For example, the message service P1 can be called to send a message to the user to inform the user that "the order has been placed", and the message service P2 can be called to send a message to the user to inform the user that "the points have been obtained". When either the message service call P1 or the message call service P2 fails to send a message to the user, a retry can be performed in the message service retry phase.

[0114] During the message service retry phase, the business database E is scanned according to the second retry request and the service version Y21 of the current service node Y2 to obtain all unclosed main transactions corresponding to the service version Y21 of the service node Y2 and initiate a retry. In other words, the message service transaction including the version identification information Y22 is obtained, that is, the message service transaction Q2 mentioned above.

[0115] Afterwards, determine whether the e-commerce transaction L2 is executed successfully. When the e-commerce transaction L2 is executed successfully, call the message sending transaction P1 and the message sending transaction P2 again to retry the message service; when the e-commerce transaction L2 fails to execute, do not call the message sending transaction P1 and the message sending transaction P2.

[0116] It can be seen from this that when the service node group is upgraded by the grayscale release method described above, the new and old service nodes will not share a copy of the transaction data in the business database E. Specifically, for service node Y1 and service node Y2, in the message service retry phase, both can scan the message service transactions corresponding to each other from the business database E to perform the retry operation, and the service node Y1 will not scan the message service transaction Q2 or the service node Y2 will not scan the message service transaction Q1, thereby avoiding the problem of retry failure caused by this, and then achieving a smoother upgrade process.

[0117] Figure 6 The third flowchart of the distributed transaction management method based on the same database mode according to the embodiment of the present disclosure is schematically shown. Figure 6 As shown, in some specific embodiments, the transaction management method further includes step S410 and step S420.

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

[0119] In step S420, after the exception scanning task lock corresponding to the current service node is acquired, step S220 is executed, that is, the step of scanning the main transaction from the business database according to the retry request and the service version.

[0120] In the disclosed embodiment, the exception scanning task lock may include an exclusive lock, that is, only the service node that obtains the exception scanning task lock is allowed to execute step S220, to prevent problems such as conflicts caused by multiple service nodes scanning the business database E at the same time.

[0121] Optionally, in the embodiment of the present disclosure, the method of abnormal scanning task lock can be determined according to actual needs. For example, a competition mechanism can be used to enable multiple service nodes to preempt the abnormal scanning task lock, so that the service node that preempts the abnormal scanning task lock executes step S220.

[0122] In some specific embodiments, there are multiple service nodes, among which at least two service nodes have different service versions, there are multiple exception scanning task locks, one service version corresponds to at least one exception scanning task lock, and different service versions correspond to different exception scanning task locks.

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

[0124] According to the above-mentioned distributed transaction management method based on the same database mode, the present disclosure also provides a distributed transaction management device based on the same database mode, which is applied to at least one service node in the distributed transaction management system. Figure 8 The device is described in detail.

[0125] Figure 7 The structure block diagram of the distributed transaction management device based on the same database mode according to the embodiment of the present disclosure is schematically shown. Figure 7 As shown, the distributed transaction management device 700 based on the same-library 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 .

[0126] The service version confirmation module 710 is used to determine the service version of the current service node according to the preset version configuration information. In one embodiment, the service version confirmation module 710 can be used to execute the step S210 described above, which will not be repeated here.

[0127] The first scanning module 720 is used to scan the main transaction from the business database according to the retry request and the service version, and the main transaction includes version identification information corresponding to the service version. In one embodiment, the first scanning module 720 can be used to execute the step S220 described above, which will not be repeated here.

[0128] The second scanning module 730 is used to extract at least one branch transaction corresponding to the main transaction from the business database. In one embodiment, the second scanning module 730 can be used to execute the step S230 described above, which will not be described in detail here.

[0129] The calling module 740 is used to call at least one branch transaction according to the calling rule corresponding to the retry request to perform a retry operation. In one embodiment, the calling module 740 can be used to execute the step S240 described above, which will not be described in detail here.

[0130] The distributed transaction management device based on the same-library mode of the embodiment of the present disclosure can first determine the service version of the current service node when receiving a retry request, and then extract the main transaction including the version identification information corresponding to the service version from the business database. In this way, the new and old service nodes can respectively scan the main transactions corresponding to their respective service versions, and then retry the operation. In this way, the problem of the new and old service nodes scanning the same main transaction is avoided, and further, the problem of the failure of the retry operation caused by this is avoided.

[0131] According to an embodiment of the present disclosure, any multiple modules of the service version confirmation module 710, the first scanning module 720, the second scanning module 730 and the calling module 740 can be combined in one module for implementation, or any one of the modules can be split into multiple modules. Alternatively, at least part of the functions of one or more of these modules can be combined with at least part of the functions of 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 can be at least partially implemented 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 can be implemented by hardware or firmware such as any other reasonable way of integrating or packaging the circuit, or by any one of the three implementation methods of software, hardware and firmware or by a 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, and when the computer program module is executed, a corresponding function may be performed.

[0132] When the service node group is upgraded by the grayscale release method described above, the new and old service nodes will not share a copy of the transaction data in the business database E. This avoids the problem of retry failures caused by this, and thus achieves a smoother upgrade process.

[0133] Figure 8 The block diagram of an electronic device suitable for implementing a distributed transaction management method based on the same-library mode according to an embodiment of the present disclosure is schematically shown. Figure 8 As shown, the electronic device 800 according to an embodiment of the present disclosure includes a processor 801, which can 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 part 808 to a random access memory (RAM) 803. The processor 801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 801 may also include an 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 flow according to an embodiment of the present disclosure.

[0134] In RAM 803, various programs and data required for the operation of electronic device 800 are stored. Processor 801, ROM 802 and RAM 803 are connected to each other via bus 804. Processor 801 performs various operations of the method flow according to the embodiment of the present disclosure by executing the program in ROM 802 and / or RAM 803. It should be noted that the program can also be stored in one or more memories other than ROM 802 and RAM 803. Processor 801 can also perform various steps of the method flow according to the embodiment of the present disclosure by executing the program stored in the one or more memories.

[0135] According to an embodiment of the present disclosure, the electronic device 800 may further include an input / output (I / O) interface 805, which is also connected to the bus 804. The electronic device 800 may further include one or more of the following components connected to the I / O interface 805: an input portion 806 including a keyboard, a mouse, etc.; an output portion 807 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage portion 808 including a hard disk, etc.; and a communication portion 809 including a network interface card such as a LAN card, a modem, etc. The communication portion 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. A removable medium 811, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 810 as needed, so that a computer program read therefrom is installed into the storage portion 808 as needed.

[0136] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiment; or may exist independently without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the distributed transaction management method based on the same library mode according to the embodiment of the present disclosure is implemented.

[0137] According to an embodiment of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, may include but is not limited to: a portable computer disk, 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 disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, an apparatus or a device. For example, according to an embodiment 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 ROM 802 and RAM 803.

[0138] The embodiment of the present disclosure also includes a computer program product, which includes a computer program, and the computer program includes a program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the distributed transaction management method based on the same library mode provided by the embodiment of the present disclosure.

[0139] The above functions defined in the system / device of the embodiment of the present disclosure are executed when the computer program is executed by the processor 801. According to the embodiment of the present disclosure, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0140] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices, magnetic storage devices, etc. In another embodiment, the computer program may also be transmitted and distributed in the form of signals on a network medium, and downloaded and installed through the communication part 809, and / or installed from a removable medium 811. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0141] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 809, and / or installed from the removable medium 811. When the computer program is executed by the processor 801, the above functions defined in the system of the embodiment of the present disclosure are performed. According to the embodiment of the present disclosure, the system, device, means, module, unit, etc. described above can be implemented by a computer program module.

[0142] According to an embodiment of the present disclosure, the program code for executing the computer program provided by the embodiment of the present disclosure can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level process and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, Java, C++, python, "C" language or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on the remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect through the Internet).

[0143] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0144] It will be appreciated by those skilled in the art that the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways, even if such combinations and / or combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways without departing from the spirit and teachings of the present disclosure. All of these combinations and / or combinations fall within the scope of the present disclosure.

[0145] The embodiments of the present disclosure are described above. However, these embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the various embodiments cannot be used in combination to advantage. The scope of the present disclosure is defined by the attached claims and their equivalents. Without departing from the scope of the present disclosure, those skilled in the art may make a variety of substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A distributed transaction management method based on the same database mode, applied to at least one service node in a distributed transaction management system, characterized in that: The transaction management method comprises: Determine the service version of the current service node according to the preset version configuration information; Scanning a main transaction from a business database according to the retry request and the service version, wherein the main transaction includes version identification information corresponding to the service version, and the retry request includes a first retry request generated during a business service retry phase; Extracting at least one branch transaction corresponding to the main transaction from the business database, wherein the main transaction includes a main business transaction, and the at least one branch transaction includes a sub-business transaction of a participant participating in the main business transaction; calling the at least one branch transaction according to a calling rule corresponding to the retry request to perform a retry operation, The calling of the at least one branch transaction according to the calling rule corresponding to the retry request to perform the retry operation includes: Each of the extracted branch transactions is called in sequence to retry the business service.

2. The transaction management method according to claim 1, characterized in that: The retry request includes a second retry request generated in the message service retry phase, the main transaction includes a message service transaction, the number of the branch transactions is multiple, and the multiple branch transactions include: at least one main business transaction corresponding to the message service transaction, and a message sending transaction corresponding to the at least one main business transaction; The calling of the at least one branch transaction according to the calling rule corresponding to the retry request to perform a retry operation includes: When the main business transaction is successfully called, the message sending transaction is called to retry the message service.

3. The transaction management method according to claim 1, characterized in that: The transaction management method further includes: Obtaining at least one transaction and determining a transaction record of the at least one transaction; Determine the service version of the current service node according to the version configuration information, and obtain version identification information corresponding to the service version; The main transaction is generated according to the transaction record and the version identification information, and is written into the business database.

4. The transaction management method according to claim 1, characterized in that: The transaction management method further includes: Acquire an exception scanning task lock corresponding to the current service node from at least one exception scanning task lock; After the exception scanning task lock corresponding to the current service node is acquired, the step of scanning the main transaction from the business database according to the retry request and the service version is performed.

5. The transaction management method according to claim 4, characterized in that: There are multiple service nodes, among which at least two service nodes have different service versions. There are multiple exception scanning task locks, one service version corresponds to at least one exception scanning task lock, and different service versions correspond to different exception scanning task locks.

6. The transaction management method according to claim 1, characterized in that: There are multiple service nodes, and the multiple service nodes upgrade the service version using at least one of grayscale release, rolling upgrade, and blue-green release.

7. A distributed transaction management device based on the same database mode, applied to at least one service node in a distributed transaction management system, characterized in that: The distributed transaction management device comprises: A service version confirmation module is used to determine the service version of the current service node according to the preset version configuration information; A first scanning module, configured to scan a main transaction from a business database according to a retry request and the service version, wherein the main transaction includes version identification information corresponding to the service version, and the retry request includes a first retry request generated during a business service retry phase; A second scanning module is used to scan at least one branch transaction corresponding to the main transaction from the business database, wherein the main transaction includes a main business transaction, and the at least one branch transaction includes a sub-business transaction of a participant participating in the main business transaction; a calling module, configured to call the at least one branch transaction according to a calling rule corresponding to the retry request to perform a retry operation, The calling module is further used to call each of the extracted branch transactions in sequence to perform a business service retry.

8. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors execute the distributed transaction management method according to any one of claims 1 to 6.

9. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, causes the processor to execute the distributed transaction management method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the distributed transaction management method according to any one of claims 1 to 6 is implemented.

Images