Distributed transaction processing method and device, computer storage medium, and electronic device

Abstract

The present disclosure relates to a distributed transaction processing method and apparatus, a computer storage medium, and an electronic device, and relates to the field of computer technology. The method comprises: a second proxy service corresponding to a transaction participant receives a call request sent by a transaction initiator, and the transaction participant calls a corresponding interface according to the call request to obtain an execution result; the transaction initiator receives the execution result sent by the second proxy service, generates an operation decision according to the execution result, and the first proxy service corresponding to the transaction initiator updates the status of the target transaction according to the operation decision; when the second proxy service monitors the updated status of the target transaction, the transaction participant executes the target transaction according to the status of the target transaction. The present disclosure reduces the complexity of distributed transaction processing and shortens the processing flow of distributed transactions.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of computer technology, and in particular, to a distributed transaction processing method, a distributed transaction processing apparatus, a computer-readable storage medium, and an electronic device. Background Art

[0002] A transaction is a sequence of operations consisting of one or more resource management operations. A distributed transaction is a transaction in which the operations in the sequence involve multiple databases. With the popularization of microservice architecture, the application of distributed transactions is also increasing.

[0003] In related technologies, the distributed transaction solutions that can be adopted include Saga (distributed transaction model, used to solve the problem of long transaction execution) and Tcc (Try-Confirm-Cancel, distributed transaction mode). In the Saga solution, each participant in the business process submits a local transaction. When a participant fails, it compensates the previous successful participant. The first-phase forward service and the second-phase compensation service are both implemented by business development; in the Tcc solution, resources need to be tested and locked or reserved. When executing business operations, no checks are performed, and only reserved or locked business resources are used. When any business method fails, a rollback operation is immediately performed to release the reserved business resources.

[0004] However, the Saga solution is highly intrusive to businesses, requiring extensive code modifications for adaptation, and its implementation is tied to the business language used. The Tcc solution requires an additional coordinator to centrally manage transactions, and distributed implementation code must be integrated into the business system to complete distributed transaction processing, resulting in significant business intrusion.

[0005] Therefore, a new distributed transaction processing method needs to be provided.

[0006] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to ordinary technicians in this field. Summary of the Invention

[0007] The purpose of the present invention is to provide a distributed transaction processing method, a distributed transaction processing device, a computer-readable storage medium and an electronic device, thereby overcoming, at least to a certain extent, the problem of large business intrusion in related technologies caused by the limitations and defects of related technologies.

[0008] According to one aspect of the present disclosure, a distributed transaction processing method is provided, comprising:

[0009] The second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, and the transaction participant calls the corresponding interface according to the call request to obtain the execution result;

[0010] The transaction initiator receives the execution result sent by the second proxy service, generates an operation decision according to the execution result, and the first proxy service corresponding to the transaction initiator updates the status of the target transaction according to the operation decision;

[0011] When the second proxy service monitors the updated state of the target transaction, the transaction participant executes the target transaction according to the state of the target transaction.

[0012] In an exemplary embodiment of the present disclosure, before the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, the distributed transaction processing method further includes:

[0013] An execution interface and a cancellation interface corresponding to the transaction participant are defined.

[0014] In an exemplary embodiment of the present disclosure, a second proxy service corresponding to a transaction participant receives a call request sent by a transaction initiator, including:

[0015] The first proxy service receives a transaction request from a target application, generates a unique identifier according to the transaction request, and stores the unique identifier in a distributed memory;

[0016] The first proxy server sends the unique identifier to the transaction initiator. The transaction initiator generates a call request and sends the unique identifier and the call request to the second proxy server, or sends the call request to the second proxy server.

[0017] In an exemplary embodiment of the present disclosure, after the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, the distributed transaction processing method further includes:

[0018] When the second proxy service receives the unique identifier and the call request, the second proxy service stores the call request in a link record in the distributed memory that is identical to the unique identifier received by the second proxy service;

[0019] When the second proxy server receives only the call request, the second proxy server sends the call request to the transaction participant.

[0020] In an exemplary embodiment of the present disclosure, the transaction participant calls the corresponding interface according to the call request to obtain the execution result, including:

[0021] The transaction participant calls the execution interface, executes the transaction corresponding to the call request through the execution interface, and obtains the execution result.

[0022] In an exemplary embodiment of the present disclosure, generating an operation decision according to the execution result, and the first proxy service corresponding to the transaction initiator updating the state of the target transaction according to the operation decision, includes:

[0023] When the execution result is inconsistent with the preset status code, the transaction initiator generates an operation decision according to the execution result, wherein the operation decision is rollback or retry;

[0024] The first proxy service adds a keyword to the request header of the call request of the transaction initiator according to the operation decision, updates the state of the target transaction through the keyword, and stores the state of the target transaction in the distributed memory.

[0025] In an exemplary embodiment of the present disclosure, when the second proxy service monitors the updated state of the target transaction, the transaction participant executes the target transaction according to the state of the target transaction, including:

[0026] The second proxy service monitors the distributed storage;

[0027] When monitoring that the state of the target transaction is updated to rollback, the transaction participant calls the cancel interface according to the state of the target transaction to rollback the target transaction.

[0028] In an exemplary embodiment of the present disclosure, when the second proxy service monitors the updated state of the target transaction, the transaction participant executes the target transaction according to the state of the target transaction, including:

[0029] When monitoring that the status of the target transaction is updated to retry, the first proxy service obtains the original request parameters of the transaction initiator, and initiates a first call request to the initiator using the original request parameters;

[0030] The transaction initiator sends the first call request to the second proxy service, and the second proxy service determines, based on the original request parameters included in the first call request, whether there is a call request including the original request parameters in the distributed memory, and obtains a determination result;

[0031] The second proxy service completes the retry of the target transaction according to the judgment result.

[0032] In an exemplary embodiment of the present disclosure, the second proxy service completes the retry of the target transaction according to the judgment result, including:

[0033] When the judgment result is that the request parameter exists, the second proxy service obtains the historical execution result corresponding to the original request parameter, and sends the historical execution result to the transaction initiator;

[0034] When the judgment result is that the client does not exist, the second proxy service sends the first call request to the transaction participant;

[0035] The transaction participant calls the execution interface to obtain a second execution result, and sends the second execution result to the transaction initiator through the second proxy service.

[0036] According to one aspect of the present disclosure, there is provided a distributed transaction processing apparatus, comprising:

[0037] An execution result acquisition module is configured to receive a call request sent by a transaction initiator via a second proxy service corresponding to a transaction participant, and the transaction participant calls a corresponding interface according to the call request to obtain an execution result;

[0038] a transaction status updating module, configured for the transaction initiator to receive the execution result sent by the second proxy service, generate an operation decision according to the execution result, and the first proxy service corresponding to the transaction initiator to update the status of the target transaction according to the operation decision;

[0039] The target transaction execution module is configured to enable the transaction participant to execute the target transaction according to the target transaction status when the second proxy service monitors the updated target transaction status.

[0040] According to one aspect of the present disclosure, a storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the distributed transaction processing method described above is implemented.

[0041] According to one aspect of the present disclosure, there is provided an electronic device, including:

[0042] processor; and

[0043] a memory for storing executable instructions of the processor;

[0044] The processor is configured to execute any one of the above-mentioned distributed transaction processing methods by executing the executable instructions.

[0045] A distributed transaction processing method provided by an embodiment of the present disclosure introduces a proxy service. On the one hand, after a second proxy service receives a call request sent by a transaction initiator, the transaction initiator calls a corresponding interface according to the call request, executes the corresponding transaction, obtains an execution result, and sends the execution result to the transaction through the second proxy service. The introduced proxy service is used to process distributed transactions, solving the problem of large business intrusion caused by distributed transactions in related technologies. In addition, the proxy service is independent of the business programming language, and transaction consistency is achieved through the proxy service. On the other hand, after a transaction participant receives the execution result, the status of the target transaction is updated according to the execution result, so that the transaction participant executes the target transaction according to the updated state of the target transaction, reducing the complexity of distributed transaction processing and shortening the processing flow of distributed transactions.

[0046] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The accompanying drawings are incorporated into and constitute a part of this specification, illustrate embodiments consistent with the present invention, and together with the description, serve to explain the principles of the present invention. Obviously, the drawings described below are only some embodiments of the present invention, and it is clear that those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0048] Figure 1 The following schematically shows a flow chart of a distributed transaction processing method according to an exemplary embodiment of the present disclosure.

[0049] Figure 2 A block diagram schematically illustrates a distributed transaction processing system according to an exemplary embodiment of the present disclosure.

[0050] Figure 3 A flowchart schematically illustrates a method in which a second proxy service corresponding to a transaction participant receives a call request sent by a transaction initiator according to an exemplary embodiment of the present disclosure.

[0051] Figure 4 The following schematically illustrates a diagram of a proxy service corresponding to a transaction participant receiving a call request according to an exemplary embodiment of the present disclosure.

[0052] Figure 5 A flowchart of a distributed transaction processing method after a second proxy service corresponding to a transaction participant receives a call request sent by a transaction initiator according to an exemplary embodiment of the present disclosure is schematically shown.

[0053] Figure 6A flowchart schematically illustrates a method in which a first proxy service corresponding to a transaction initiator updates a status of a target transaction according to an operation decision according to an exemplary embodiment of the present disclosure.

[0054] Figure 7 A flowchart schematically illustrates a method in which a transaction participant executes a target transaction according to the status of the target transaction when a second proxy service monitors an updated status of the target transaction according to an exemplary embodiment of the present disclosure.

[0055] Figure 8 A schematic diagram schematically illustrates a transaction participant executing a target transaction when the target transaction is in a rollback state according to an exemplary embodiment of the present disclosure.

[0056] Figure 9 A flowchart schematically illustrates a method in which a transaction participant executes a target transaction according to the status of the target transaction when a second proxy service monitors an updated status of the target transaction according to an exemplary embodiment of the present disclosure.

[0057] Figure 10 A flowchart schematically illustrates a method in which a second proxy service completes a retry of a target transaction based on a judgment result according to an exemplary embodiment of the present disclosure.

[0058] Figure 11 A schematic diagram schematically illustrates a transaction participant executing a target transaction when the state of the target transaction is retry according to an exemplary embodiment of the present disclosure.

[0059] Figure 12 A block diagram schematically illustrates a distributed transaction processing apparatus according to an exemplary embodiment of the present disclosure.

[0060] Figure 13 An electronic device for implementing the above-mentioned distributed transaction processing method according to an exemplary embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0061] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that the present invention will be more comprehensive and complete and the concepts of the example embodiments will be fully conveyed to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present invention. However, those skilled in the art will appreciate that the technical solutions of the present invention may be practiced while omitting one or more of the specific details, or that other methods, components, devices, steps, etc. may be employed. In other cases, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of the present invention.

[0062] In addition, the accompanying drawings are merely schematic illustrations of the present invention and are not necessarily drawn to scale. Identical reference numerals in the figures denote identical or similar parts, and thus repetitive descriptions thereof will be omitted. Some of the blocks shown in the accompanying drawings are functional entities that do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0063] A transaction consists of a series of operations. A large business system is typically composed of several subsystems, each with its own independent database. Often, a business process requires the collaborative work of multiple subsystems, and these operations may need to be completed within a single transaction, known as a distributed transaction.

[0064] In related technologies, solutions for distributed transactions include Saga and Tcc. In Saga, a transaction process needs to be written, such as transaction T1 sending an email, C1 withdrawing the email, T2 placing an order for a product, and C2 canceling the order, with a process T1-T2. When transaction T2 fails to place an order for a product, C2 and C1 need to be called to cancel the previous operation. However, the Saga solution is highly invasive to the business, requiring the business to modify a large amount of code for adaptation, and its implementation is tied to the language used by the business. In Tcc, resources are reserved, and when a business execution fails, a rollback operation is immediately executed to release the reserved resources. However, in the Tcc solution, the business system needs to rely on specific components or the distributed implementation code needs to be integrated into the business system to implement distributed transaction processing. When the distributed implementation code is upgraded, the business system also needs to update the business code, which increases the workload of business developers.

[0065] Based on one or more of the above problems, this exemplary embodiment first provides a distributed transaction processing method, which can be run on a server, server cluster, or cloud server, etc. Of course, those skilled in the art can also run the method of the present invention on other platforms as needed, and this exemplary embodiment does not specifically limit this. Figure 1 As shown, the distributed transaction processing method may include the following steps:

[0066] Step S110. The second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, and the transaction participant calls the corresponding interface according to the call request to obtain the execution result;

[0067] Step S120: The transaction initiator receives the execution result sent by the second proxy service, generates an operation decision based on the execution result, and the first proxy service corresponding to the transaction initiator updates the status of the target transaction based on the operation decision;

[0068] Step S130: When the second proxy service monitors the updated state of the target transaction, the transaction participant executes the target transaction according to the state of the target transaction.

[0069] The above-mentioned distributed transaction processing method, on the one hand, introduces a proxy service. When the second proxy service receives a call request sent by the transaction initiator, the transaction initiator calls the corresponding interface according to the call request, executes the corresponding transaction, obtains the execution result, and sends the execution result to the transaction through the second proxy service. The introduced proxy service is used to process distributed transactions, solving the problem of large business intrusion of distributed transactions in related technologies. In addition, the proxy service is independent of the business programming language, and transaction consistency is achieved through the proxy service. On the other hand, after the transaction participants receive the execution result, the status of the target transaction is updated according to the execution result, so that the transaction participants execute the target transaction according to the updated status of the target transaction, reducing the complexity of distributed transaction processing and shortening the processing flow of distributed transactions.

[0070] The following is a detailed explanation and description of each step involved in the distributed transaction processing method of the exemplary embodiment of the present disclosure.

[0071] First, the application scenarios and invention objectives of the exemplary embodiments of the present disclosure are explained and illustrated.

[0072] Specifically, the exemplary embodiments of the present disclosure can be used to implement distributed transactions, mainly to solve the problem that the current distributed transaction implementation is complex and requires a large number of code changes to the business.

[0073] The example embodiments of the present disclosure are based on a transaction request sent by a target application. The first proxy service of the transaction initiator responds to the transaction request, records and stores the transaction request, and sends the transaction request to the transaction initiator. The transaction initiator generates a call request based on the transaction request and sends the call request to the second proxy service of the transaction participant. The transaction participant calls the corresponding interface based on the call request received by the second proxy service, executes the transaction, obtains the execution result, and sends the execution result to the transaction initiator through the second proxy service. The transaction initiator updates the status of the target transaction based on the execution result. The second proxy service monitors the status of the target transaction. When the second proxy service monitors the updated status of the target transaction, it calls the corresponding interface based on the status of the target transaction. The proxy service is introduced, and the proxy service is independent of the business programming language. The proxy service is used to process distributed transactions and achieve consistency in transaction processing.

[0074] Next, the distributed transaction processing system involved in the exemplary embodiment of the present disclosure is explained and illustrated. Figure 2 As shown, the distributed transaction processing system may include: a target application 210, a first proxy service 220, a transaction initiator 230, a second proxy service 240, and a transaction participant 250. The target application may send a transaction request to the first proxy service 220. After receiving the transaction request, the first proxy service 220 generates a unique identifier and sends the unique identifier to the transaction initiator 230. The transaction initiator 230 is configured to receive the transaction request and unique identifier sent by the first proxy service, generate a call request based on the received transaction request, and send the call request to the second proxy service 240. The transaction participant 250 calls the corresponding interface based on the call request received by the second proxy service 240 to complete the transaction. In addition, the transaction initiator 230 is also used to receive the execution result of the transaction participant 250 sent by the second proxy service 240. The transaction initiator 230 updates the status of the target transaction according to the execution result. The first proxy service 220 stores the updated status of the target service in the distributed memory. When the second proxy service 240 monitors that the status of the target transaction included in the distributed memory has changed, the actual participant 250 calls the corresponding interface according to the status of the target transaction monitored by the second proxy service to complete the transaction.

[0075] The following will be combined Figure 2 Steps S110 to S130 are explained and described.

[0076] In step S110, the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, and the transaction participant calls the corresponding interface according to the call request to obtain an execution result.

[0077] Among them, transaction participants can complete the target transaction by calling the corresponding interface and performing a series of operations. The second proxy service is the proxy service corresponding to the transaction participant. When there are multiple transaction participants, for example, transaction participant A and transaction participant B, when transaction participant A needs to call transaction participant B, transaction participant A calls the proxy service corresponding to transaction participant B, and the proxy service corresponding to transaction participant B records the distributed transaction status of transaction participant B.

[0078] In this example embodiment, before the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, the distributed transaction processing method further includes:

[0079] An execution interface and a cancellation interface corresponding to the transaction participant are defined.

[0080] Specifically, before a distributed participant calls an interface based on a call request, it must first define the transaction participant's interface. This primarily defines the execution interface for executing the target transaction and the cancellation interface for canceling the target transaction. The transaction participant's interface names must also be agreed upon. For example, if the execution interface is named XXXX, the cancellation interface can be named unXXXX. Furthermore, a preset status code for the transaction initiator can be defined. This preset status code is the status code generated when the target transaction corresponding to the target application's transaction request successfully executes. In this example embodiment, the preset status code is not specifically defined.

[0081] In this example embodiment, reference Figure 3 As shown, the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, which may include steps S310 and S320:

[0082] Step S310: The first proxy service receives a transaction request from a target application, generates a unique identifier according to the transaction request, and stores the unique identifier in a distributed memory;

[0083] Step S320: The first proxy server sends the unique identifier to the transaction initiator. The transaction initiator generates a call request and sends the unique identifier and the call request to the second proxy server, or sends the call request to the second proxy server.

[0084] Steps S310 and S320 will be further explained and illustrated below. Specifically, first, the target application sends a transaction request to the first proxy service corresponding to the transaction initiator. The first proxy service responds to the transaction request sent by the target application, generates a unique identifier based on the transaction request, stores the generated unique identifier in a distributed memory, and sends the unique identifier and the transaction request to the corresponding transaction initiator. The transaction initiator generates a call request based on the transaction request. When it is necessary to save the call request sent to the second proxy service and the execution result of the transaction participant in the distributed memory, the call request and the unique identifier can be sent to the second proxy service corresponding to the transaction participant. When it is not necessary to store the call request and the execution result in the distributed memory, the call request can be sent only to the second proxy service without sending the unique identifier.

[0085] For example, refer to Figure 4 As shown, in Figure 4 The example includes distributed storage, a target application, a first proxy service, a transaction initiator, a second proxy service, transaction participant A, a third proxy service, transaction participant B, a fourth proxy service, and transaction participant C. The transaction initiator calls transaction participants A and B, which then calls transaction participant C. If transaction participant B is a logging service, the transaction initiator's request to call transaction participant B and the execution result of transaction participant B do not need to be stored in the distributed storage. The transaction initiator only needs to send the call request to the third proxy service corresponding to transaction participant B, without passing the unique identifier. In this example embodiment, by passing only the call request, storage resources of the distributed storage are conserved.

[0086] After the transaction initiator sends the call request, the proxy service corresponding to the transaction participant responds to the call request. In this example embodiment, after the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, Figure 5 As shown, the distributed transaction processing method may further include step S510 and step S520:

[0087] Step S510. When the second proxy service receives the unique identifier and the call request, the second proxy service stores the call request in the link record in the distributed memory that is identical to the unique identifier received by the second proxy service;

[0088] Step S520: When the second proxy server receives only the call request, the second proxy server sends the call request to the transaction participant.

[0089] Steps S510 and S520 are further explained and illustrated below. Specifically, when the second proxy service receives the unique identifier and call request sent by the transaction initiator, the second proxy service stores the call request in a link record included in the distributed memory. The unique identifier recorded in the link record is the same as the unique identifier received by the second proxy service. If the second proxy service only receives the call request, it forwards the call request to the transaction participant corresponding to the second proxy service.

[0090] In this example embodiment, after the transaction participant receives the call request sent by the second proxy service, the transaction participant calls the corresponding interface according to the call request. The transaction participant calls the corresponding interface according to the call request and obtains the execution result, which may include:

[0091] The transaction participant calls the execution interface, executes the transaction corresponding to the call request through the execution interface, and obtains the execution result;

[0092] Specifically, after the transaction participant receives the call request sent by the second proxy service, the transaction participant calls the corresponding execution interface according to the call request, completes the corresponding transaction through the execution interface, and obtains the execution result; for the execution result, the proxy service corresponding to the transaction participant can store the execution result in the distributed memory.

[0093] In step S120, the transaction initiator receives the execution result sent by the second proxy service, generates an operation decision according to the execution result, and the first proxy service corresponding to the transaction initiator updates the status of the target transaction according to the operation decision.

[0094] In this example embodiment, reference Figure 6 As shown, generating an operation decision according to the execution result, and the first proxy service corresponding to the transaction initiator updating the state of the target transaction according to the operation decision may include steps S610 and S620:

[0095] Step S610. When the execution result is inconsistent with the preset status code, the transaction initiator generates an operation decision based on the execution result, wherein the operation decision is rollback or retry;

[0096] Step S620: The first proxy service adds a keyword to the request header of the call request of the transaction initiator according to the operation decision, updates the status of the target transaction through the keyword, and stores the status of the target transaction in the distributed memory.

[0097] Steps S610 and S620 are further explained and illustrated below. Specifically, first, after the service participant obtains the execution result through the execution interface, the second proxy service corresponding to the service participant sends the execution result to the transaction initiator. The transaction initiator then determines the received execution result. If the status code in the received execution result is inconsistent with the preset status code, the transaction initiator generates an operation decision based on the received execution result and sends the operation decision to the first proxy service. The first proxy service adds the keyword 'decision' to the request header of the transaction initiator's call request and determines the value of the keyword 'decision' based on the operation decision. If the operation decision is to retry, the value of the keyword 'decision' is empty or commit. If the operation decision is to rollback, the value of the keyword 'decision' is rollback. In this example embodiment, the keyword and its value are not specifically limited. When the first proxy service adds the keyword to the call request, the target transaction status is updated using the keyword and the target transaction status can be stored in the distributed memory. The operation decision may be to retry the target transaction or to roll back the target transaction; the preset status code may be a status code indicating successful execution of the target transaction, and its value may be 200. In this example embodiment, the preset status code is not specifically limited.

[0098] In step S130 , when the second proxy service monitors the updated state of the target transaction, the transaction participant executes the target transaction according to the state of the target transaction.

[0099] In this example embodiment, reference Figure 7 As shown, when the second proxy service monitors the updated state of the target transaction, the transaction participant executes the target transaction according to the state of the target transaction, including step S710 and step S720:

[0100] Step S710: The second proxy service monitors the distributed storage;

[0101] Step S720: When monitoring that the status of the target transaction is updated to rollback, the transaction participant calls the cancel interface according to the status of the target transaction to rollback the target transaction.

[0102] Steps S710 and S720 are further explained and illustrated below. Specifically, the second proxy service monitors the distributed memory. When the second proxy service monitors that the status of the target transaction in the distributed memory is updated to rollback, it sends the updated status of the target transaction to the transaction participant corresponding to the second proxy service. The transaction participant rolls back the target transaction based on the received updated status of the target transaction and calls the cancel interface in the transaction participant to roll back the target transaction.

[0103] For example, refer to Figure 8 As shown, in Figure 8 In this example, transaction participant B's proxy service does not error when returning the execution result to transaction participant A. However, when transaction participant A's proxy service returns the execution result to the transaction initiator, an error occurs. That is, the status code in the execution result sent by transaction participant A, received by the transaction initiator, is inconsistent with the preset status code. The transaction initiator generates a rollback action. Based on the action decision, the transaction initiator's proxy service modifies the target transaction's status to rollback and stores the rollback status in distributed storage. Both transaction participant A and transaction participant B's proxy services monitor the distributed storage. Upon detecting that the target transaction's status has been updated to rollback, transaction participant A's proxy service sends the updated status to transaction participant A. Transaction participant A responds to the target transaction's status and calls the cancel interface. Transaction participant B's proxy service then sends the updated status to transaction participant B. Transaction participant B responds to the target transaction's status and calls the cancel interface. After transaction participant A and transaction participant B execute the cancel interface, their proxy services store the updated status after executing the cancel interface in distributed storage.

[0104] In addition, when a transaction participant's proxy service fails to send a request to a transaction participant, the proxy service continues to retry until it succeeds.

[0105] In this example embodiment, reference Figure 9 As shown, when the second proxy service monitors the updated state of the target transaction, the transaction participant executes the target transaction according to the state of the target transaction, which may include steps S910 and S920:

[0106] Step S910. When monitoring that the state of the target transaction is updated to retry, the first proxy service obtains the original request parameters of the transaction initiator and sends a first call request to the transaction initiator using the original request parameters;

[0107] Step S920: The transaction initiator sends the first call request to the second proxy service. The second proxy service determines, based on the original request parameters included in the first call request, whether there is a call request including the original request parameters in the distributed memory, and obtains a determination result.

[0108] Step S930: The second proxy service completes the retry of the target transaction according to the judgment result.

[0109] Below, steps S910 to S930 will be further explained and illustrated. Specifically, when the proxy service of the transaction participant monitors that the status of the target transaction is updated to retry, the first proxy service corresponding to the transaction initiator obtains the original request parameters of the transaction initiator from the distributed storage. That is, the first proxy service obtains the original request parameters in the call request sent by the target application stored by the first proxy service from the distributed storage server, and sends the obtained original request parameters to the transaction initiator again. The transaction initiator generates a first call request based on the original request parameters and sends the first call request to the second proxy service. After the second proxy service receives the first call request sent by the service initiator, it queries the distributed storage based on the original request parameters included in the first call request to determine whether there is a call request including the original request parameters, and obtains a judgment result.

[0110] In this example embodiment, reference Figure 10 As shown, the second proxy service completes the retry of the target transaction according to the judgment result, which may include steps S1010 to S1030:

[0111] Step S1010. When the judgment result is yes, the second proxy service obtains the historical execution result corresponding to the original request parameter and sends the historical execution result to the transaction initiator;

[0112] Step S1020. When the judgment result is that the entity does not exist, the second proxy service sends the first call request to the transaction participant;

[0113] Step S1030: The transaction participant calls the execution interface to obtain a second execution result, and sends the second execution result to the transaction initiator through the second proxy service.

[0114] Below, steps S1010 to S1030 will be further explained and illustrated. Specifically, first, when a call request including the original request parameters exists in the distributed memory, that is, when the judgment result is that it exists, the second proxy service obtains the historical execution result corresponding to the original request parameters, wherein the historical execution result can be stored in the second proxy service or cached in the distributed memory, and this example embodiment does not specifically limit this; after obtaining the historical execution result, the historical execution result is sent to the transaction initiator. When the judgment result is that it does not exist, the second proxy service sends the first call request to the transaction participant, and the transaction participant calls the corresponding execution interface according to the first call request to obtain the second execution result, and sends the second execution result to the transaction initiator through the second proxy service corresponding to the transaction participant.

[0115] For example, refer to Figure 11 As shown, after receiving the call request, transaction participant A calls the proxy service of transaction participant B. When the request header keyword of the call request stored in the distributed memory is commit or empty, the proxy service corresponding to the transaction initiator obtains the original request parameters from the distributed memory and sends the original request parameters to the transaction initiator. The transaction initiator generates the call request again according to the original request parameters, includes the keyword value in the request header of the call request, and sends the regenerated call request to the proxy service of transaction participant A. At the same time, the proxy service corresponding to transaction participant A and the proxy service corresponding to transaction participant B monitor the status of the target transaction. The proxy service corresponding to transaction participant A and the proxy service corresponding to transaction participant B determine whether there is a call request including the original request parameters in the distributed memory. When there is no call request including the original request parameters and stored by the proxy service corresponding to transaction participant A in the distributed memory, the proxy service sends the received call request to the transaction participant. When there is a call request including the original request parameters and stored by the proxy service corresponding to transaction participant B in the distributed memory, the proxy service corresponding to transaction participant B obtains the historical execution result and sends the historical execution result to transaction participant A who called the proxy service corresponding to transaction participant B.

[0116] In this example embodiment, when the target transaction is in the retry state, the transaction initiator is required to regenerate a call request and initiate the call from the beginning. During the call process, if a call request including the original request parameters exists in the distributed memory and is stored by the proxy service associated with transaction participant B, then if the newly generated call request is sent to transaction participant B again, and transaction participant B again calls the corresponding interface to obtain the execution result, an idempotence problem may arise. Therefore, in this example embodiment, when a call request including the original request parameters exists in the distributed memory and is stored by the proxy service associated with transaction participant B, the proxy service associated with transaction participant B directly obtains the historical execution result and sends it to transaction participant A that calls the proxy service associated with transaction participant B. This resolves the idempotence problem and accelerates the target transaction retry process.

[0117] The distributed transaction processing method and distributed transaction processing system provided by the exemplary embodiments of the present disclosure have at least the following advantages: on the one hand, the distributed transaction processing is realized through the introduced proxy service, which solves the problem of large business intrusion of distributed transactions in related technologies, and the proxy service is independent of the business programming language, and the consistency of transactions is achieved through the proxy service; on the other hand, this solution shortens the transaction process to one stage, reducing and shortening the complexity and processing process of distributed transactions.

[0118] The exemplary embodiment of the present disclosure provides a distributed transaction processing device, referring to Figure 12 As shown, the distributed transaction processing apparatus may include: an execution result acquisition module 1210, a transaction status update module 1220, and a target transaction execution module 1230. Among them:

[0119] The execution result acquisition module 1210 is configured to receive a call request from a transaction initiator by a second proxy service corresponding to a transaction participant, and the transaction participant calls a corresponding interface according to the call request to obtain an execution result;

[0120] The transaction status update module 1220 is configured for the transaction initiator to receive the execution result sent by the second proxy service, generate an operation decision based on the execution result, and the first proxy service corresponding to the transaction initiator to update the status of the target transaction based on the operation decision;

[0121] The target transaction execution module 1230 is configured to enable the transaction participant to execute the target transaction according to the target transaction status when the second proxy service monitors the updated target transaction status.

[0122] In an exemplary embodiment of the present disclosure, before the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, the distributed transaction processing method further includes:

[0123] An execution interface and a cancellation interface corresponding to the transaction participant are defined.

[0124] In an exemplary embodiment of the present disclosure, a second proxy service corresponding to a transaction participant receives a call request sent by a transaction initiator, including:

[0125] The first proxy service receives a transaction request from a target application, generates a unique identifier according to the transaction request, and stores the unique identifier in a distributed memory;

[0126] The first proxy server sends the unique identifier to the transaction initiator. The transaction initiator generates a call request and sends the unique identifier and the call request to the second proxy server, or sends the call request to the second proxy server.

[0127] In an exemplary embodiment of the present disclosure, after the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, the distributed transaction processing method further includes:

[0128] When the second proxy service receives the unique identifier and the call request, the second proxy service stores the call request in a link record in the distributed memory that is identical to the unique identifier received by the second proxy service;

[0129] When the second proxy server receives only the call request, the second proxy server sends the call request to the transaction participant.

[0130] In an exemplary embodiment of the present disclosure, the transaction participant calls the corresponding interface according to the call request to obtain the execution result, including:

[0131] The transaction participant calls the execution interface, executes the transaction corresponding to the call request through the execution interface, and obtains the execution result.

[0132] In an exemplary embodiment of the present disclosure, generating an operation decision according to the execution result, and the first proxy service corresponding to the transaction initiator updating the state of the target transaction according to the operation decision, includes:

[0133] When the execution result is inconsistent with the preset status code, the transaction initiator generates an operation decision according to the execution result, wherein the operation decision is rollback or retry;

[0134] The first proxy service adds a keyword to the request header of the call request of the transaction initiator according to the operation decision, updates the state of the target transaction through the keyword, and stores the state of the target transaction in the distributed memory.

[0135] In an exemplary embodiment of the present disclosure, when the second proxy service monitors the updated state of the target transaction, the transaction participant executes the target transaction according to the state of the target transaction, including:

[0136] The second proxy service monitors the distributed storage;

[0137] When monitoring that the state of the target transaction is updated to rollback, the transaction participant calls the cancel interface according to the state of the target transaction to rollback the target transaction.

[0138] In an exemplary embodiment of the present disclosure, when the second proxy service monitors the updated state of the target transaction, the transaction participant executes the target transaction according to the state of the target transaction, including:

[0139] When monitoring that the status of the target transaction is updated to retry, the first proxy service obtains the original request parameters of the transaction initiator, and initiates a first call request to the initiator using the original request parameters;

[0140] The transaction initiator sends the first call request to the second proxy service, and the second proxy service determines, based on the original request parameters included in the first call request, whether there is a call request including the original request parameters in the distributed memory, and obtains a determination result;

[0141] The second proxy service completes the retry of the target transaction according to the judgment result.

[0142] In an exemplary embodiment of the present disclosure, the second proxy service completes the retry of the target transaction according to the judgment result, including:

[0143] When the judgment result is that the request parameter exists, the second proxy service obtains the historical execution result corresponding to the original request parameter, and sends the historical execution result to the transaction initiator;

[0144] When the judgment result is that the client does not exist, the second proxy service sends the first call request to the transaction participant;

[0145] The transaction participant calls the execution interface to obtain a second execution result, and sends the second execution result to the transaction initiator through the second proxy service.

[0146] The specific details of each module in the above-mentioned distributed transaction processing device have been described in detail in the corresponding distributed transaction processing method, so they will not be repeated here.

[0147] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to an embodiment of the present invention, the features and functions of two or more modules or units described above can be concretized in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0148] Furthermore, although the steps of the method of the present invention are described in a particular order in the accompanying drawings, this does not require or imply that the steps must be performed in this particular order, or that all steps must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0149] In an exemplary embodiment of the present invention, an electronic device capable of implementing the above data conversion method is also provided.

[0150] Those skilled in the art will appreciate that various aspects of the present invention may be implemented as systems, methods, or program products. Therefore, various aspects of the present invention may be implemented in the following forms: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, which may be collectively referred to herein as "circuits," "modules," or "systems."

[0151] Reference below Figure 13 An electronic device 1300 according to this embodiment of the present invention will be described. Figure 13 The electronic device 1300 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present invention.

[0152] like Figure 13 As shown, the electronic device is implemented as a general-purpose computing device. Components of the electronic device may include, but are not limited to, the at least one processing unit 1310, the at least one storage unit 1320, a bus 1330 connecting different system components (including the storage unit 1320 and the processing unit 1310), and a display unit 1340.

[0153] The storage unit stores program codes, which can be executed by the processing unit 1310, so that the processing unit 1310 performs the steps according to various exemplary embodiments of the present invention described in the above “Exemplary Method” section of this specification. For example, the processing unit 1310 can perform the following steps: Figure 1 Step S110 shown in: the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, and the transaction participant calls the corresponding interface according to the call request to obtain an execution result; step S120: the transaction initiator receives the execution result sent by the second proxy service, generates an operation decision according to the execution result, and the first proxy service corresponding to the transaction initiator updates the status of the target transaction according to the operation decision; step S130: when the second proxy service monitors the updated status of the target transaction, the transaction participant executes the target transaction according to the status of the target transaction.

[0154] The storage unit 1320 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 13201 and / or a cache memory unit 13202 , and may further include a read-only memory unit (ROM) 13203 .

[0155] The storage unit 1320 may also include a program / utility 13204 having a set (at least one) of program modules 13205, such program modules 13205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0156] Bus 1330 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0157] The electronic device 1300 can also communicate with one or more external devices 1400 (e.g., a keyboard, a pointing device, a Bluetooth device, etc.), one or more devices that enable a user to interact with the electronic device 1300, and / or any device that enables the electronic device 1300 to communicate with one or more other computing devices (e.g., a router, a modem, etc.). Such communication can occur via an input / output (I / O) interface 1350. Furthermore, the electronic device 1300 can also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network such as the Internet) via a network adapter 1360. As shown, the network adapter 1360 communicates with other modules of the electronic device 1300 via a bus 1330. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device 1300, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0158] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present invention.

[0159] In exemplary embodiments of the present invention, a computer-readable storage medium is also provided, storing a program product capable of implementing the methods described above. In some possible implementations, various aspects of the present invention may also be implemented in the form of a program product comprising program code. When the program product is executed on a terminal device, the program code is configured to cause the terminal device to perform the steps according to various exemplary embodiments of the present invention described in the "Exemplary Methods" section above.

[0160] According to an embodiment of the present invention, a program product for implementing the above-mentioned method can be a portable compact disc read-only memory (CD-ROM) and include program code, and can be run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, a readable storage medium can be any tangible medium containing or storing a program, and the program can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0161] The program product may be implemented in any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0162] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0163] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0164] The program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, and the like, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a stand-alone software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device may be connected to the user computing device via any type 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., via the Internet using an Internet service provider).

[0165] Furthermore, the above-described figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention and are not intended to be limiting. It is readily understood that the processes illustrated in the above-described figures do not indicate or limit the temporal order of these processes. Furthermore, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0166] Other embodiments of the present invention will readily occur to those skilled in the art after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow from the general principles of the invention and include common knowledge or customary techniques in the art not invented herein. The specification and examples are to be considered as exemplary only, with the true scope and spirit of the invention being indicated by the claims.

Claims

1. A distributed transaction processing method, characterized in that: include: The second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, and the transaction participant calls the corresponding interface according to the call request to obtain the execution result; The transaction initiator receives the execution result sent by the second proxy service. When the execution result is inconsistent with a preset status code, the transaction initiator generates an operation decision based on the execution result, wherein the operation decision is rollback or retry. The first proxy service adds a keyword to the request header of the call request of the transaction initiator based on the operation decision, updates the status of the target transaction using the keyword, and stores the status of the target transaction in the distributed memory. The second proxy service monitors the distributed memory; when it is monitored that the status of the target transaction is updated to rollback, the transaction participant calls a cancel interface based on the status of the target transaction to rollback the target transaction; when it is monitored that the status of the target transaction is updated to retry, the first proxy service obtains the original request parameters of the transaction initiator and initiates a first call request to the transaction initiator using the original request parameters; the transaction initiator sends the first call request to the second proxy service, and the second proxy service determines whether there is a call request including the original request parameters in the distributed memory based on the original request parameters included in the first call request, and obtains a determination result; the second proxy service completes the retry of the target transaction based on the determination result.

2. The distributed transaction processing method according to claim 1, wherein: Before the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, the distributed transaction processing method further includes: An execution interface and a cancellation interface corresponding to the transaction participant are defined.

3. The distributed transaction processing method according to claim 2, wherein: The second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, including: The first proxy service receives a transaction request from a target application, generates a unique identifier according to the transaction request, and stores the unique identifier in a distributed memory; The first proxy server sends the unique identifier to the transaction initiator. The transaction initiator generates a call request and sends the unique identifier and the call request to the second proxy server, or sends the call request to the second proxy server.

4. The distributed transaction processing method according to claim 3, wherein: After the second proxy service corresponding to the transaction participant receives the call request sent by the transaction initiator, the distributed transaction processing method further includes: When the second proxy service receives the unique identifier and the call request, the second proxy service stores the call request in a link record in the distributed memory that is identical to the unique identifier received by the second proxy service; When the second proxy server receives only the call request, the second proxy server sends the call request to the transaction participant.

5. The distributed transaction processing method according to claim 4, characterized in that: The transaction participant calls the corresponding interface according to the call request to obtain the execution result, including: The transaction participant calls the execution interface, executes the transaction corresponding to the call request through the execution interface, and obtains the execution result.

6. The distributed transaction processing method according to claim 1, wherein: The second proxy service completes the retry of the target transaction according to the judgment result, including: When the judgment result is that the request parameter exists, the second proxy service obtains the historical execution result corresponding to the original request parameter, and sends the historical execution result to the transaction initiator; When the judgment result is that the client does not exist, the second proxy service sends the first call request to the transaction participant; The transaction participant calls the execution interface to obtain a second execution result, and sends the second execution result to the transaction initiator through the second proxy service.

7. A distributed transaction processing device, characterized in that: include: An execution result acquisition module is configured to receive a call request sent by a transaction initiator via a second proxy service corresponding to a transaction participant, and the transaction participant calls a corresponding interface according to the call request to obtain an execution result; a transaction status update module, configured to cause the transaction initiator to receive the execution result sent by the second proxy service; when the execution result is inconsistent with a preset status code, the transaction initiator to generate an operation decision based on the execution result, wherein the operation decision is rollback or retry; and the first proxy service to add a keyword to the request header of the transaction initiator's call request based on the operation decision, update the status of the target transaction using the keyword, and store the status of the target transaction in the distributed memory; a target transaction execution module, configured for the second proxy service to monitor the distributed memory; when monitoring that the target transaction status is updated to rollback, the transaction participant calls a cancel interface based on the target transaction status to rollback the target transaction; when monitoring that the target transaction status is updated to retry, the first proxy service obtains the original request parameters of the transaction initiator and initiates a first call request to the transaction initiator using the original request parameters; the transaction initiator sends the first call request to the second proxy service, and the second proxy service determines whether there is a call request including the original request parameters in the distributed memory based on the original request parameters included in the first call request, and obtains a determination result; and the second proxy service completes the retry of the target transaction based on the determination result.

8. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the distributed transaction processing method according to any one of claims 1 to 6 is implemented.

9. An electronic device, characterized in that: include: processor; as well as a memory for storing executable instructions of the processor; The processor is configured to execute the distributed transaction processing method according to any one of claims 1 to 6 by executing the executable instructions.

Images