Distributed transaction processing methods and systems, computer storage media

Abstract

This application discloses a distributed transaction processing method and system, and a computer storage medium. The distributed transaction processing method includes: a distributed transaction comprising committing a local transaction and an external request; a transaction initiator initiates the commit of a local transaction, the committing information including transaction start information, which at least includes a business identifier; the transaction initiator reports the transaction start information to a distributed transaction accelerator via a remote procedure call; if the transaction start information is not reported within a preset time, the transaction initiator records the transaction start information to a local log; the local log collects proxy records and includes them in a transaction message queue; the distributed transaction accelerator listens to and records the transaction message queue. This approach improves the reliability and efficiency of distributed transaction processing.

Description

Technical Field

[0001] This application relates to the field of transaction processing technology, and in particular to a distributed transaction processing method and system, and a computer storage medium. Background Technology

[0002] Existing open-source distributed transaction managers, i.e. servers, cannot guarantee the reliable completion of distributed transactions under various circumstances. For example, when the server itself temporarily crashes or the network connection between the application and the server is temporarily slowed down, the execution of business logic will be blocked, and the reliability of data cannot be guaranteed. Summary of the Invention

[0003] The main technical problem addressed by this application is to provide a distributed transaction processing method and system, and a computer storage medium, in order to improve the reliability and efficiency of distributed transaction processing.

[0004] To address the aforementioned technical problems, this application adopts the following technical solution: providing a distributed transaction processing method. This distributed transaction processing method includes: a distributed transaction comprising committing a local transaction and an external request; the transaction initiator initiates the commit of the local transaction, the information of which includes transaction start information, which at least includes a business identifier; the transaction initiator reports the transaction start information to the distributed transaction accelerator via a remote procedure call; if the transaction start information is not reported within a preset time, the transaction initiator records the transaction start information to a local log; the local log collects proxy records and includes them in a transaction message queue; the distributed transaction accelerator listens to and records the transaction message queue.

[0005] To address the aforementioned technical problems, this application adopts the following technical solution: providing a distributed transaction processing system. This distributed transaction processing system includes at least: a transaction initiator, a distributed transaction facilitator, and a destination server. Distributed transactions include committing local transactions and external requests. The transaction initiator initiates the commit of a local transaction, and the information submitted includes transaction start information, which at least includes a business identifier. The transaction initiator reports the transaction start information to the distributed transaction facilitator via a remote procedure call. If the transaction start information is not reported within a preset time, the transaction initiator records the transaction start information in a local log. The local log collects proxy records and includes them in a transaction message queue. The distributed transaction facilitator listens to and records the transaction message queue. When executing an external request, the transaction initiator stores the transaction start information on the destination server.

[0006] To address the aforementioned technical problems, one technical solution adopted in this application is to provide a computer storage medium. This computer storage medium stores program data, which can be executed to implement any of the aforementioned distributed transaction processing methods.

[0007] The beneficial effects of this application's embodiments are as follows: The transaction initiator first reports transaction start information to the distributed transaction accelerator through a remote procedure call system. If the transaction start information is not reported within a preset time, it is recorded in a local log. Then, this local log is collected by a local log agent and added to the transaction message queue. The distributed transaction accelerator listens to and records the transaction message queue. In this way, the transaction initiator can ensure the reliability of the transaction start information reported to the distributed transaction accelerator through both the remote procedure call system and asynchronous log collection, without needing to receive information reporting feedback from the distributed transaction accelerator. This achieves asynchronous and decoupled communication between the transaction initiator and the distributed transaction accelerator. Furthermore, by using a transaction message queue to cache local logs, this application can improve the reliability and efficiency of distributed transaction processing. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a flowchart illustrating an embodiment of the distributed transaction processing method of this application;

[0010] Figure 2 yes Figure 1 A detailed flowchart of step S11 in the embodiment;

[0011] Figure 3 This is a flowchart illustrating an embodiment of the distributed transaction processing method of this application;

[0012] Figure 4 This is a schematic diagram of the structure of an embodiment of the distributed transaction processing system of this application;

[0013] Figure 5 This is a flowchart illustrating an embodiment of the distributed transaction processing method of this application;

[0014] Figure 6 This is a flowchart illustrating an embodiment of the distributed transaction processing method of this application;

[0015] Figure 7 This is a schematic diagram of the structure of an embodiment of the computer storage medium of this application. Detailed Implementation

[0016] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the application. Similarly, the following embodiments are only some, not all, embodiments of the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0017] In the description of the embodiments of this application, it should be noted that, unless otherwise explicitly specified and limited, the terms "connected" and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in the embodiments of this application based on the specific circumstances.

[0018] In the embodiments of this application, unless otherwise expressly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "on top of," and "over" the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0019] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0020] Existing open-source distributed transaction managers, i.e. servers, cannot guarantee the reliable completion or full rollback of distributed transactions in various situations. For example: 1) When the server itself temporarily crashes or the network connection between the application and the server is temporarily slowed down, the execution of business logic will be blocked, and the reliability of data cannot be guaranteed; 2) If the execution time of a single participating node is too long, rather than an abnormal termination, it will also trigger a full rollback of the transaction; 3) If a participating instance restarts during a full rollback, the rollback cannot continue to be executed on other instances with the same function; 4) When a node takes too long to execute and triggers a rollback, the rollback logic may be completed before the normal logic.

[0021] Based on the above reasons, this application proposes a distributed transaction processing method and system, and a computer storage medium, which can ensure that information is transmitted from one node to another remote node, so that the server and the application are not tightly coupled. Even when the network connection between the application and the server is not smooth, it can ensure reliable delayed transmission of transaction management information. It can accurately determine whether the local transaction executed on a certain node is interrupted due to program crash, avoiding incorrect timeout rollback or timeout retries. After the participating node restarts, the business logic that needs to continue to be executed can be resumed. When executing external calls, synchronous or asynchronous calls can be selected according to actual needs, and retries are supported after external call failures in both scenarios. An alarm notification is issued after the retry limit is reached.

[0022] First, this application proposes a distributed transaction processing method, such as... Figure 1 As shown, Figure 1 This is a flowchart illustrating an embodiment of the distributed transaction processing method of this application. The distributed transaction processing method of this embodiment specifically includes the following steps:

[0023] Step S11: Distributed transactions include committing local transactions and external requests. The transaction initiator initiates the commit of local transactions. The information for committing local transactions includes transaction start information, which includes at least a business identifier. The transaction initiator reports the transaction start information to the distributed transaction accelerator through the remote procedure call system.

[0024] Committing a local transaction and making an external request are two steps in a distributed transaction. When committing an ontology transaction, the transaction initiator executes the transaction corresponding to the transaction start information locally and stores the transaction start information in the transaction initiator's local database. On the other hand, when making an external request, the transaction initiator stores the transaction start information to the destination server, thereby realizing the distributed management of transactions.

[0025] After the transaction initiator detects a transaction request, the application needs to report the transaction start information to the distributed transaction accelerator before saving the data to the local database (committing the local transaction). The transaction start information also includes key information such as the transaction code (UUID) and the business module.

[0026] The transaction initiator detects the transaction request and reports the transaction start information to the distributed transaction accelerator via Remote Procedure Call (RPC). The RPC framework essentially provides a mechanism for communication between applications, adhering to a server / client model. When using it, the client calls the interface provided by the server as if it were calling a local function.

[0027] This embodiment uses Google RPC, or gRPC, a high-performance, general-purpose, open-source RPC framework released by Google that can run in any environment. It can efficiently connect services within and across data centers, supporting pluggable load balancing, tracing, health checks, and authentication. It is also suitable for last-mile connectivity in distributed computing, mobile applications, and browser backend services. gRPC provides a simple way to precisely define services using Protocol Buffers, automatically generating highly reliable client libraries for iOS, Android, and backend support services. Designed based on the HTTP / 2 transport layer standard protocol, it can be configured for synchronous or asynchronous communication. gRPC provides methods for configuring and managing network devices that support multiple programming languages. Both communicating parties can perform secondary development based on this software framework.

[0028] To ensure the reliability of the reported transaction management information (including the aforementioned transaction start information), the transaction initiator and the distributed transaction accelerator communicate using gRPC and establish an HTTP / 2 long connection.

[0029] Step S12: If the transaction start information is not reported within the preset time, the transaction initiator will record the transaction start information in the local log.

[0030] The preset time can be 1 second, etc. If the transaction start information reporting process takes more than 1 second, the transaction initiator will record the transaction start information in the local log.

[0031] The transaction initiator can generate a completion flag after sending the transaction start information. If the completion flag is not generated within a preset time, the transaction initiator determines that the transaction start information has not been reported within the preset time; if the completion flag is generated within the preset time, the transaction start information has been reported within the preset time.

[0032] Local logs identify transaction initiation information based on business identifiers.

[0033] Step S13: The local log collects agent records through the local log and adds them to the transaction message queue. The distributed transaction accelerator listens to and records the transaction message queue.

[0034] The transaction initiator obtains the transaction start information from the local log through the local log collection agent and adds the transaction start information to the transaction message queue. The distributed transaction accelerator obtains the transaction start information and transaction progress information from the transaction message queue.

[0035] The transaction initiator asynchronously collects and reports transaction start information through a log collection program.

[0036] After reporting the transaction start information (or recording the transaction start information to the local log), the transaction initiator executes the local transaction and the remote transaction (remote request).

[0037] Unlike existing technologies, in this embodiment, the transaction initiator first reports transaction start information to the distributed transaction accelerator via a remote procedure call system. If the transaction start information is not reported within a preset time, it is recorded in a local log. This local log is then recorded by a local log collection proxy and added to a transaction message queue. The distributed transaction accelerator listens to and records the transaction message queue. In this way, the transaction initiator can ensure the reliability of the transaction start information reported to the distributed transaction accelerator through both a remote procedure call system and asynchronous log collection, without needing to receive feedback information from the distributed transaction accelerator. This achieves asynchronous and decoupled communication between the transaction initiator and the distributed transaction accelerator. Furthermore, by using a transaction message queue to cache local logs, this application improves the reliability and efficiency of distributed transaction processing.

[0038] Optionally, this embodiment can be achieved through, as follows: Figure 2 The method shown implements step S11. The method of this embodiment includes steps S21 to S23.

[0039] Step S21: The transaction initiator reports the transaction start information via a remote procedure call.

[0040] Step S22: The distributed transaction accelerator caches the transaction start information into the transaction message queue.

[0041] Step S23: The transaction message queue pushes the transaction start information cached in the message queue to the local database of the distributed transaction accelerator.

[0042] Steps S21 to S23 are described together:

[0043] As a gPRC service provider, the distributed transaction accelerator does not directly store the transaction start information received from gPRC in the local database. Instead, it uses a transaction message queue to buffer the reported transaction start information before storing it in the local database. The local database uses a MySQL cluster and is sharded by "transaction code" using sharding-jdbc.

[0044] This embodiment can ensure that transaction start information is not lost under various abnormal conditions through a transaction message queue, and the use of a transaction message queue can ensure that the distributed transaction accelerator is not congested, thus ensuring its working efficiency.

[0045] Of course, the transaction initiator uses a transaction message queue throughout the entire transaction execution process to ensure data reliability and processing efficiency.

[0046] This application further proposes another embodiment of a distributed transaction processing method, such as... Figure 3 As shown, Figure 3 This is a flowchart illustrating an embodiment of the distributed transaction processing method of this application. The distributed transaction processing method of this embodiment specifically includes the following steps:

[0047] Step S31: Distributed transactions include committing local transactions and external requests. The transaction initiator initiates the commit of local transactions. The information for committing local transactions includes transaction start information, which includes at least a business identifier. The transaction initiator reports the transaction start information to the distributed transaction accelerator through the remote procedure call system.

[0048] Step S32: If the transaction start information is not reported within the preset time, the transaction initiator will record the transaction start information in the local log.

[0049] Step S33: The local log collects agent records through the local log and adds them to the transaction message queue. The distributed transaction accelerator listens to and records the transaction message queue.

[0050] Steps S31 to S33 are similar to steps S11 to S13 above, and will not be repeated here.

[0051] Steps S31 to S33 are used to implement transaction preparation, which corresponds to the transaction preparation phase.

[0052] Step S34: After the transaction start information is reported within the preset time, the transaction initiator executes the transaction corresponding to the transaction start information, and at the same time continuously reports the first heartbeat message to the distributed transaction accelerator.

[0053] After reporting the transaction start information, the transaction initiator executes the transaction corresponding to the transaction start information. That is, the transaction initiator executes the transaction locally and continuously reports the first heartbeat message to the distributed transaction accelerator during the execution of the transaction.

[0054] A heartbeat message is a message sent by a source to a receiver that allows the receiver to determine whether and when the source has failed or terminated.

[0055] Step S35: During the transaction execution process, in response to the distributed transaction accelerator not detecting the first heartbeat message, a dead letter alarm is issued.

[0056] During the execution of the transaction by the transaction initiator locally, the distributed transaction accelerator monitors the first heartbeat information reported by the transaction initiator. If the first heartbeat information is not detected within a certain heartbeat cycle, it is determined that the transaction execution of the transaction initiator has timed out, and the distributed transaction accelerator issues a dead letter alarm.

[0057] Furthermore, when the distributed transaction accelerator detects that a transaction has neither reported its execution result nor sent its first heartbeat message for an extended period of time, it issues a dead letter alarm, notifying operations and maintenance personnel to intervene manually.

[0058] Step S36: In response to the transaction being rolled back at the transaction initiator, the transaction execution process ends, and the distributed transaction facilitator revokes its management of the distributed transaction.

[0059] If a rollback occurs during the execution of a transaction locally by the transaction initiator, the transaction execution is deemed abnormal. The transaction initiator terminates the transaction execution process and sends rollback information to the distributed transaction facilitator. The distributed transaction facilitator then revokes its management of the distributed transaction based on this rollback information.

[0060] Step S37: In response to the completion of the transaction, the transaction initiator reports the information that the transaction has been completed locally to the distributed transaction accelerator.

[0061] If a transaction is completed locally, the transaction initiator reports the completion information to the distributed transaction facilitator so that the distributed transaction facilitator knows that the transaction has been completed locally and can then proceed to the external request phase.

[0062] Step S38: The transaction initiator determines whether to execute the external request of the transaction asynchronously based on the configuration item for asynchronous execution.

[0063] If not, proceed to step S41; if yes, proceed to steps S42 and S43.

[0064] The transaction initiator executes external requests to store transaction start information and other data on the destination server, thereby achieving distributed management of transactions.

[0065] Step S41: The transaction initiator continues to execute the external request in the current thread that is executing the local transaction.

[0066] The current thread may receive multiple external requests simultaneously, and these requests can be queued and executed sequentially on the current thread.

[0067] Step S42: The distributed transaction accelerator sends the business identifier back to the transaction initiator.

[0068] If the first external request needs to be executed asynchronously, the distributed transaction accelerator will send the business identifier of the transaction request back to the transaction initiator, who can then obtain other transaction information from the local database based on the business identifier.

[0069] Step S43: The transaction initiator selects an idle thread from the callback thread pool and uses the idle thread to execute the external request based on the business identifier.

[0070] The initial execution of an external request can be configured to be synchronous or asynchronous, depending on user needs. However, in subsequent processes, when the transaction initiator re-executes the external request based on the retry notification from the distributed transaction accelerator, the external request is executed asynchronously.

[0071] In this embodiment, the transaction initiator and the distributed transaction facilitator communicate directly, which avoids the impact of downtime and interruption.

[0072] The actions of the transaction initiator in a distributed transaction can be divided into two steps: "commit local processing" (commit local transaction) and "remote call" (external request). After successfully committing local processing and storing the data, a remote call must be made to successfully send the data to the destination node or server, thus completing the distributed transaction. The distributed transaction accelerator is responsible for recording whether the "commit local processing" and "remote call" steps are successful. As long as the "commit local processing" step is completed, even if the transaction initiator crashes during the "remote call" step, the distributed transaction accelerator will notify the transaction initiator to re-initiate the "remote call" using the locally stored data after the transaction initiator recovers and restarts.

[0073] Optionally, this embodiment may further include steps S39 and S391.

[0074] Step S39: During the execution of the external request, the transaction initiator reports the second heartbeat message to the distributed transaction accelerator.

[0075] During the execution of external requests, the transaction initiator continuously reports a second heartbeat message to the distributed transaction accelerator, so that the distributed transaction accelerator can determine whether and when the transaction initiator has failed or terminated.

[0076] Step S391: If the distributed transaction accelerator does not detect a second heartbeat message during the execution of the external request, it issues a retry notification for the external request.

[0077] If the distributed transaction accelerator does not detect a second heartbeat message during the execution of an external request, it will issue a retry notification for the external request to notify the transaction initiator to re-execute the external request.

[0078] Step S392: The transaction initiator asynchronously executes the external request again based on the retry notification.

[0079] The transaction initiator asynchronously executes the external request again based on the retry notification.

[0080] Step S393: In response to the number of retries being greater than or equal to the preset number, the distributed transaction accelerator issues a dead letter alarm.

[0081] During the execution of an external request by the transaction initiator, the distributed transaction accelerator monitors the second heartbeat information reported by the transaction initiator. If the second heartbeat information is not detected within a certain heartbeat cycle, it is determined that the execution of the external request by the transaction initiator has timed out. A retry notification is then sent to notify the transaction initiator to execute the external request asynchronously again. If the number of retries exceeds the preset number (the upper limit of the number of retries), the distributed transaction accelerator issues a dead letter alarm.

[0082] As the number of retries increases, the time interval between delays also increases.

[0083] Furthermore, when the distributed transaction accelerator detects that an external request has not reported the execution result or sent a second heartbeat message for an extended period of time, it issues a dead letter alarm to notify the operations and maintenance personnel to intervene manually.

[0084] During the execution of the "external request" logic, a second heartbeat message will be continuously sent to prevent the distributed transaction accelerator from incorrectly judging that the application has crashed and initiating a retry.

[0085] During the execution of "commit local processing" and external requests, the transaction initiator maintains heartbeat communication with the distributed transaction accelerator. As long as the heartbeat is still present, even if the execution process takes a long time, the distributed transaction accelerator will not mistakenly assume that the transaction initiator has crashed and thus fail to retry or issue an alarm.

[0086] Furthermore, in response to a system crash during the execution of an external request by the transaction initiator, the distributed transaction accelerator sends a retry notification to other servers with the same application identifier as the transaction initiator, so that the other servers can execute the external request.

[0087] In response to the distributed transaction accelerator failing to detect a second heartbeat message during the asynchronous execution of an external request by the transaction initiator, the transaction's business identifier is sent back to another active server with the same application name as the transaction initiator.

[0088] If the "local transaction" is successfully committed and configured to execute the "external request" asynchronously, the distributed transaction accelerator will use the gRPC server callback function to send the "business module" + "document code" (business identifier) ​​from the transaction management record back to the transaction initiator, so that it can execute the "external request" logic bound to the specific "business module". The request content can be obtained by querying the local database based on the "document code".

[0089] Furthermore, if the transaction initiator is not alive (i.e., has no heartbeat), the distributed transaction accelerator will send the "business module" + "document code" (business identifier) ​​back to a surviving application instance (another server with the same application name as the transaction initiator), so that it can execute the "external request" logic bound to the specific "business module". The request content can be obtained by querying the local database based on the "document code".

[0090] If an exception is thrown when the transaction initiator executes an external request, it reports the execution failure information to the distributed transaction accelerator; if the transaction initiator successfully executes the external request, it reports the execution success information to the distributed transaction accelerator, thus completing the distributed transaction.

[0091] This application further proposes a distributed transaction processing system, such as Figure 4 As shown, Figure 4 This is a schematic diagram of an embodiment of the distributed transaction processing system of this application. The distributed transaction processing system of this embodiment (not shown) includes at least: a transaction initiator 51, a distributed transaction facilitator 52 communicatively connected to the transaction initiator 51, and a destination server 53. The distributed transaction includes submitting a local transaction and an external request. The transaction initiator 51 initiates the submission of a local transaction, and the information submitted includes transaction start information, which at least includes a business identifier. The transaction initiator 51 reports the transaction start information to the distributed transaction facilitator 52 via a remote procedure call. If the transaction start information is not reported within a preset time, the transaction initiator 51 records the transaction start information to a local log. The local log collects proxy records and includes them in a transaction message queue. The distributed transaction facilitator 52 listens to and records the transaction message queue. When the transaction initiator executes an external request, it stores the transaction start information in the destination server 53.

[0092] In this way, the transaction initiator 51 in this embodiment can ensure the reliability of the transaction start information reported to the distributed transaction accelerator 52 through both remote procedure call system and asynchronous log collection, and does not need to receive information reporting feedback from the distributed transaction accelerator 52, thus achieving asynchronous and non-strong coupling between the transaction initiator 51 and the distributed transaction accelerator 52; by using a transaction message queue to cache local logs in this embodiment, the reliability and efficiency of distributed transaction processing can be improved.

[0093] In an application scenario, such as Figure 5 As shown, the local transaction preparation of the transaction initiator 51 begins, assigning a transaction code and providing a business identifier, and uploading the transaction start information (transaction code, business identifier, maximum number of retransmissions for external requests, and whether the first external request is executed asynchronously) to the distributed transaction promoter 52 via gRPC. If the transaction start information upload is completed within a preset time, the distributed transaction promoter 52 caches the transaction start information and transaction progress information in the transaction message queue. If the transaction start information upload is not completed within the preset time (gRPC timeout or exception), the transaction initiator 51 records the local log, and the local transaction preparation is complete. The transaction initiator 51 can cache the transaction start information in the transaction message queue through asynchronous log collection. The transaction message queue pushes the transaction start information to the distributed transaction promoter 52. The distributed transaction promoter 52 performs transaction information subscription service and records transaction start information. The transaction monitoring initialization is completed, that is, the transaction preparation phase is completed.

[0094] In an application scenario, such as Figure 6As shown, transaction initiator 51 starts executing the transaction locally. During the execution of the transaction, transaction initiator 51 continuously sends the first heartbeat message to distributed transaction facilitator 52. If distributed transaction facilitator 52 does not detect the first heartbeat message, it determines that the local transaction execution has failed, the process terminates, and a dead letter alarm is generated. If the transaction rolls back locally during the execution of the transaction, the transaction ends, and distributed transaction facilitator 52 revokes its management of the distributed transaction. If the transaction does not roll back locally, transaction initiator 51 prepares to execute the external request and sends information that the transaction has been completed locally to distributed transaction facilitator 52, so that distributed transaction facilitator 52 marks the transaction as entering the external request phase. During the execution of the external request, if the first external request is executed synchronously, the transaction... Transaction initiator 51 executes an external request in its current thread. If the first external request is executed asynchronously, the distributed transaction accelerator 52 sends the business identifier to the transaction initiator 51 via gRPC callback. Transaction initiator 51 executes the external request in the callback thread. During the execution of the external request, transaction initiator 51 sends a second heartbeat message to the distributed transaction accelerator 52. If the distributed transaction accelerator 52 does not detect the second heartbeat message within the heartbeat cycle, it performs a callback retry until the number of retries exceeds the maximum number of retries, generating a dead letter alarm. When executing the external request, transaction initiator 51 stores transaction start information, etc., on the destination server 53. After the external request of transaction initiator 51 is completed, it returns completion information to the distributed transaction accelerator 52, and the entire distributed transaction request is completed.

[0095] In the financial sector, taking a bank transfer notification scenario as an example: After receiving a transfer request, the payment module (transaction initiator) first generates a transfer transaction number and then saves the transfer record locally (status: unexecuted). At this point, the payment module can notify the requester that the transfer request has been successfully received. Next, the payment module asynchronously initiates an "external request" through a distributed transaction accelerator, requesting the bank to perform the transfer. If the request to the bank fails due to timeout or network line interruption, the local transfer record will remain in the "unexecuted" state. After an appropriate delay, the distributed transaction accelerator will send the transfer transaction number back to the payment module, allowing it to re-request the transfer from the bank. The bank, based on the requested transaction number, determines whether it is a completed transfer request; if not, it performs the transfer.

[0096] The distributed transaction facilitator in this application is only responsible for propelling the transaction initiator application to make remote calls. The responder (destination server) does not need to know about the existence of the distributed transaction facilitator. The responder can be various types of applications such as Redis, MQ, HttpServer, and Dubbo Server. The distributed transaction facilitator is not tightly coupled with the transaction initiator application, and can ensure that transaction management information is reliably and delayedly transmitted from the transaction initiator to the distributed transaction facilitator even if the network connection between the transaction initiator and the distributed transaction facilitator is poor. After the transaction initiator application restarts, the distributed business logic that needs to continue to be executed can be resumed. When the transaction initiator application executes external calls (external requests), it allows synchronous or asynchronous calls to be selected according to actual needs, and supports retries after external call failures in both scenarios, and sends an alarm notification after the retry limit is reached. A heartbeat mechanism is used to accurately determine whether the remote call process is interrupted due to the crash of one party's program, avoiding erroneous timeout rollbacks, timeout retries, and failure alarms.

[0097] The distributed transaction booster in this application does not place its functionality into the terminal, but rather because a distributed transaction booster can communicate with multiple terminals. This change in architectural pattern avoids the need for each terminal to have this function, saving costs. Furthermore, the distributed transaction booster can match the communication needs of various types of terminals and has strong versatility.

[0098] In addition to being used for remote idempotent update service invocation, this application can also be used to ensure the reliable execution of various remote calls: ensuring buffer updates and ensuring message delivery; this application defines an interaction between two distributed nodes as a distributed transaction, and by concatenating such simple distributed transactions, it can also ensure the distributed consistency of complex multi-node participation.

[0099] The working principle of the distributed transaction processing system in this embodiment can be applied to the above method embodiments, and will not be repeated here.

[0100] This application further proposes a computer-readable storage medium, such as Figure 7 As shown, the computer-readable storage medium 160 in this embodiment is used to store the program data 161 of the above embodiments. The program data 161 can be executed to implement the above distributed business processing method. The program data 161 has been described in detail in the above method embodiments, and will not be repeated here.

[0101] In this embodiment, the computer-readable storage medium 160 may be, but is not limited to, a USB flash drive, SD card, PD optical drive, portable hard drive, large-capacity floppy drive, flash memory, multimedia memory card, server, etc.

[0102] Unlike existing technologies, the transaction initiator in this application first reports transaction start information to the distributed transaction accelerator via a remote procedure call system. If the reporting of transaction start information is not completed within a preset time, the transaction start information is recorded in a local log. Then, this local log is recorded by a local log collection proxy and added to the transaction message queue. The distributed transaction accelerator listens to and records the transaction message queue. In this way, the transaction initiator in this application can ensure the reliability of the transaction start information reported to the distributed transaction accelerator through both remote procedure call system and asynchronous log collection, and does not need to receive information reporting feedback from the distributed transaction accelerator, thus achieving asynchronous and decoupled communication between the transaction initiator and the distributed transaction accelerator. By caching the local log through the transaction message queue, this application can improve the reliability and efficiency of distributed transaction processing.

[0103] Furthermore, if the aforementioned functions are implemented as software functions and sold or used as independent products, they can be stored in a mobile terminal-readable storage medium. That is, this application also provides a storage device storing program data, which can be executed to implement the methods of the above embodiments. This storage device can be, for example, a USB flash drive, an optical disc, or a server. In other words, this application can be embodied in the form of a software product, which includes several instructions to cause a smart terminal to execute all or part of the steps of the methods described in the various embodiments.

[0104] In the description of this application, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0105] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0106] Any process or method description in the flowchart or otherwise herein can be understood as representing an apparatus, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order according to the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0107] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (which may be a personal computer, server, network device, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0108] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A distributed transaction processing method, characterized in that, include: Distributed transactions include committing local transactions and external requests. The transaction initiator initiates the commit of the local transaction, and the information of the commit of the local transaction includes transaction start information. The transaction start information includes at least a business identifier. The transaction initiator reports the transaction start information to the distributed transaction accelerator through a remote procedure call. If the transaction start information is not reported within a preset time, the transaction initiator will record the transaction start information in the local log. The local log collects proxy records through the local log and includes them in the transaction message queue; the distributed transaction accelerator listens to and records the transaction message queue. The distributed transaction processing method further includes: In response to the transaction being rolled back at the transaction initiator, ending the transaction execution process, the distributed transaction accelerator revoks its management of the distributed transaction; In response to the completion of the transaction, the transaction initiator reports the information that the transaction was completed locally to the distributed transaction accelerator; The transaction initiator executes the external request of the transaction synchronously or asynchronously, depending on the configuration option for asynchronous execution.

2. The distributed transaction processing method according to claim 1, characterized in that, Further includes: After the transaction start information is reported within a preset time, the transaction initiator executes the transaction corresponding to the transaction start information and continuously reports the first heartbeat message to the distributed transaction accelerator. During the execution of the transaction, in response to the distributed transaction accelerator not detecting the first heartbeat message, a dead letter alarm is issued.

3. The distributed transaction processing method according to claim 2, characterized in that, The external request for synchronously executing the transaction includes: The transaction initiator continues to execute the external request in the current thread that is executing the local transaction.

4. The distributed transaction processing method according to claim 2, characterized in that, The external request for asynchronously executing the transaction includes: The distributed transaction accelerator will send the business identifier back to the transaction initiator. The transaction initiator selects an idle thread from the callback thread pool and uses the idle thread to execute the external request based on the business identifier.

5. The distributed transaction processing method according to claim 4, characterized in that, Further includes: During the execution of the external request, the transaction initiator reports a second heartbeat message to the distributed transaction accelerator. If the distributed transaction accelerator does not detect the second heartbeat message during the execution of the external request, it will issue a retry notification for the external request. The transaction initiator asynchronously executes the external request again based on the retry notification; In response to a retries count greater than or equal to a preset number, the distributed transaction accelerator issues a dead letter alarm.

6. The distributed transaction processing method according to claim 5, characterized in that, Further includes: In response to a system crash occurring during the execution of the external request by the transaction initiator, the distributed transaction accelerator sends a retry notification to other servers with the same application identifier as the transaction initiator, so that the other servers can execute the external request.

7. The distributed transaction processing method according to claim 1, characterized in that, The transaction initiator reports the transaction start information to the distributed transaction accelerator via remote call information, including: The transaction initiator reports the transaction start information via a remote procedure call; The distributed transaction accelerator caches the transaction start information into the transaction message queue; The transaction message queue pushes the cached transaction start information to the local database of the distributed transaction accelerator.

8. A distributed transaction processing system, characterized in that, include: The transaction initiator, distributed transaction accelerator, and destination server are defined. The distributed transaction includes committing a local transaction and making an external request. The transaction initiator initiates the committing of the local transaction. The information of the committing of the local transaction includes transaction start information, which includes at least a business identifier. The transaction initiator reports the transaction start information to the distributed transaction accelerator through a remote procedure call. If the transaction start information is not reported within a preset time, the transaction initiator records the transaction start information to the local log; the local log collects proxy records and includes them in the transaction message queue; the distributed transaction accelerator listens to and records the transaction message queue. When the transaction initiator executes the external request, it stores the transaction start information in the destination server. In response to the transaction being rolled back at the transaction initiator, ending the transaction execution process, the distributed transaction accelerator revokes its management of the distributed transaction; In response to the completion of the transaction, the transaction initiator reports the information that the transaction was completed locally to the distributed transaction accelerator; The transaction initiator executes the external request of the transaction synchronously or asynchronously, depending on the configuration option for asynchronous execution.

9. A computer storage medium, characterized in that, It stores program data that can be executed to implement the distributed transaction processing method according to any one of claims 1-7.

Images