Distributed transaction processing method, storage medium, equipment and program product

Abstract

The embodiment of the invention discloses a distributed transaction processing method, a storage medium, equipment and a program product. A to-be-processed distributed transaction is split into a plurality of sub-transactions; determining a target service node for processing each sub-transaction based on the real-time performance index of each service node in the service node set of each sub-transaction; respectively sending a preparation request message to a target service node of each sub-transaction; in response to the condition that the corresponding target service node has the corresponding sub-transaction execution condition, sending a pre-submission request message to the target service node of each sub-transaction; and in response to successful pre-submission of the target service node, sending a submission request message to the target service node of each sub-transaction, the submission request message being used for instructing each target service node to submit the corresponding sub-transaction. According to the embodiment of the invention, the target service node for processing the sub-transactions is selected based on the real-time performance index of each service node, so that the stability and response speed of the system in a high-concurrency environment can be improved.

Description

Technical Field

[0001] The present disclosure relates to the fields of computer technology and database technology, and in particular to a distributed transaction processing method, storage medium, device and program product. Background Art

[0002] A distributed transaction is one in which the transaction participants, the server supporting the transaction, the resource server, and the transaction management server are located on different nodes of the distributed system. In a distributed system, data between multiple nodes needs to be consistent. If one node updates the data, other nodes must also update the corresponding data to maintain data consistency across the entire system.

[0003] In the related technology, in the process of processing distributed transactions, it is necessary to copy and synchronize data between multiple nodes. Factors such as network delays and node failures can lead to inconsistent data on each node, which is more likely to occur in a high-concurrency transaction environment.

[0004] Therefore, how to ensure data consistency among nodes in a distributed system while handling distributed transactions is a technical issue worthy of attention. Summary of the invention

[0005] In order to solve the above technical problems, the present disclosure is proposed. The embodiments of the present disclosure provide a distributed transaction processing method, storage medium, device and program product.

[0006] According to one aspect of an embodiment of the present disclosure, a method for processing a distributed transaction is provided, including:

[0007] Split the pending distributed transaction into multiple sub-transactions;

[0008] Based on the real-time performance indicators of each service node in the service node set corresponding to each sub-transaction, a target service node for processing each sub-transaction is determined respectively;

[0009] Sending a prepare request message to the target service node of each sub-transaction respectively, wherein the prepare request message carries the execution data of the corresponding sub-transaction;

[0010] In response to receiving a first response message returned by each target service node based on the prepare request message, and each first response message indicates that the corresponding target service node is qualified to execute the corresponding sub-transaction, respectively sending a pre-commit request message to the target service node of each sub-transaction;

[0011] In response to receiving the second response message returned by each target service node based on the pre-submission request message, and each second response message indicates that the pre-submission of the target service node is successful, a submission request message is sent to the target service node of each sub-transaction respectively, and the submission request message is used to instruct each target service node to submit the corresponding sub-transaction.

[0012] In some other embodiments of the present disclosure, before determining the target service node for processing each sub-transaction based on the real-time performance indicator of each service node in the service node set corresponding to each sub-transaction, the method further includes:

[0013] Using a performance detection algorithm, obtaining a first performance parameter of each service node, wherein the first performance parameter includes at least one of the following: historical transaction response time, historical transaction processing result; and

[0014] Using the heartbeat signal, obtaining a second performance parameter of each service node, where the second performance parameter includes load information;

[0015] Based on the first performance parameter and the second performance parameter, a real-time performance indicator of each service node is determined.

[0016] In still other embodiments of the present disclosure, obtaining the first performance parameter of each service node includes:

[0017] Obtain the number of historical transactions processed by each service node within the historical time period, the response time of each historical transaction, and the processing result of each historical transaction;

[0018] Based on the number of historical transactions and the response time of each historical transaction, respectively determine the average response time of each service node processing the historical transaction within the historical time period, where the average response time is the historical transaction response time;

[0019] Based on the number of historical transactions and the processing results of each historical transaction, the statistical processing results of the historical transactions processed by each service node within the historical time period are determined respectively, and the statistical processing results are the historical transaction processing results.

[0020] In some other embodiments of the present disclosure, after sending the rollback request message to the target service node of each sub-transaction respectively, the method further includes:

[0021] Determine the rollback status of each target service node;

[0022] In response to the rollback status of each target service node indicating that the rollback is successful, performing consistency check on the service data in each target service node;

[0023] In response to the result of the consistency check being inconsistent, an exception handling operation is performed, and the exception handling operation includes at least one of the following: undoing the data change operation before the consistency check, synchronizing the data operation, and triggering an alarm operation.

[0024] In some other embodiments of the present disclosure, after determining the rollback status of each target service node, the method further includes:

[0025] In response to a target service node that fails to roll back, an alarm prompt message is generated. The target service node that fails to roll back includes a service node that fails to roll back successfully after the rollback times exceed a set number, and a service node that fails to roll back successfully after the rollback time exceeds a set time.

[0026] In some other embodiments of the present disclosure, after each sub-transaction is processed by each target service node, the process further includes:

[0027] Based on the data change information after each target service node processes each sub-transaction, the business data in each target service node is checked for consistency;

[0028] In response to the result of the consistency check being inconsistent, an exception handling operation is performed, and the exception handling operation includes at least one of the following: undoing the data change operation before the consistency check, synchronizing the data operation, and triggering an alarm operation.

[0029] According to another aspect of an embodiment of the present disclosure, a distributed transaction processing device is provided, including:

[0030] A splitting module is used to split a pending distributed transaction into multiple sub-transactions;

[0031] A node determination module, which determines a target service node for processing each sub-transaction based on the real-time performance indicators of each service node in the service node set corresponding to each sub-transaction;

[0032] A preparation module, used to send a preparation request message to a target service node of each sub-transaction respectively, wherein the preparation request message carries execution information of the corresponding sub-transaction;

[0033] a pre-commit module, configured to, in response to receiving a first response message returned by each target service node based on the prepare request message, wherein each first response message indicates that the corresponding target service node is qualified to execute the corresponding sub-transaction, send a pre-commit request message to the target service node of each sub-transaction respectively;

[0034] A submission module is used to send submission request messages to the target service nodes of each sub-transaction in response to receiving a second response message returned by each target service node based on the pre-submission request message, and each second response message indicates that the pre-submission of the target service node is successful, wherein the submission request message is used to instruct each target service node to submit the corresponding sub-transaction.

[0035] In some embodiments of the present disclosure, the device further comprises:

[0036] A first acquisition module is used to acquire a first performance parameter of each service node, wherein the first performance parameter includes at least one of the following: historical transaction response time, historical transaction processing result; and

[0037] A second acquisition module, used to acquire a second performance parameter of each service node by using a heartbeat signal, wherein the second performance parameter includes load information;

[0038] The performance determination module is used to determine the real-time performance index of each service node based on the first performance parameter and the second performance parameter.

[0039] In some other embodiments of the present disclosure, the first acquisition module is used to: obtain the number of historical transactions processed by each service node within the historical time period, the response time of each historical transaction, and the processing result of each historical transaction; based on the number of historical transactions and the response time of each historical transaction, determine the average response time of each service node processing the historical transactions within the historical time period, and the average response time is the historical transaction response time; based on the number of historical transactions and the processing result of each historical transaction, determine the statistical processing result of each service node processing the historical transactions within the historical time period, and the statistical processing result is the historical transaction processing result.

[0040] In some further embodiments of the present disclosure, the device comprises:

[0041] an abort processing module, configured to, in response to not receiving a first response message returned by each target service node based on the prepare request message, or the presence of a first response message indicating that the target service node does not have a condition for executing a corresponding sub-transaction, execute an abort operation of aborting the processing of the pending distributed transaction;

[0042] The rollback module is used to send a rollback request message to the target service node of each sub-transaction in response to not receiving a second response message returned by each target service node based on the pre-commit request message, or there is a second response message indicating that the pre-commit of the target service node fails.

[0043] In some further embodiments of the present disclosure, the device comprises:

[0044] A status determination module, used to determine the rollback status of each target service node;

[0045] A first verification module, configured to perform consistency verification on the service data in each target service node in response to the rollback status of each target service node indicating that the rollback is successful;

[0046] The first exception handling module is used to perform an exception handling operation in response to the result of the consistency check being inconsistent, and the exception handling operation includes at least one of the following: undoing the data change operation before the consistency check, synchronizing the data operation, and triggering an alarm operation.

[0047] In some further embodiments of the present disclosure, the device comprises:

[0048] The alarm module is used to generate an alarm prompt message in response to a target service node that fails to roll back, wherein the target service node that fails to roll back includes a service node that fails to roll back successfully after the rollback times exceed the set times, and a service node that fails to roll back successfully after the rollback time exceeds the set time.

[0049] In some further embodiments of the present disclosure, the device further comprises:

[0050] A second verification module is used to perform consistency verification on the business data in each target service node based on the data change information after each target service node processes each sub-transaction;

[0051] The second exception handling module is used to perform an exception handling operation in response to the result of the consistency check being inconsistent, and the exception handling operation includes at least one of the following: undoing the data change operation before the consistency check, synchronizing the data operation, and triggering an alarm operation.

[0052] According to another aspect of the present disclosure, a computer-readable storage medium is provided, wherein the storage medium stores computer program instructions, and when the computer program instructions are executed, the above-mentioned distributed transaction processing method is implemented.

[0053] According to another aspect of the present disclosure, an electronic device is provided, the electronic device comprising:

[0054] A memory for storing a computer program product;

[0055] The processor is used to execute the computer program product stored in the memory, and when the computer program product is executed, the above-mentioned distributed transaction processing method is implemented.

[0056] According to another aspect of the present disclosure, a computer program product is provided, including computer program instructions, and when the computer program instructions are executed by a processor, the above-mentioned distributed transaction processing method is implemented.

[0057] Based on the above-mentioned embodiments of the present disclosure, when it is necessary to process a distributed transaction, the distributed transaction to be processed is split into multiple sub-transactions; based on the real-time performance indicators of each service node in the service node set of each sub-transaction, the target service node for processing each sub-transaction is determined; a prepare request message is sent to the target service node of each sub-transaction respectively, and the prepare request message carries the execution data of the corresponding sub-transaction; in response to receiving a first response message returned by each target service node based on the prepare request message, and each first response message indicates that the corresponding target service node has the conditions to execute the corresponding sub-transaction, a pre-commit request message is sent to the target service node of each sub-transaction respectively; in response to receiving a second response message returned by each target service node based on the pre-commit request message, and each second response message indicates that the pre-commit of the target service node is successful, a commit request message is sent to the target service node of each sub-transaction respectively, and the commit request message is used to instruct each target service node to commit the corresponding sub-transaction. Therefore, the technical solution disclosed in the present invention selects the target service node for processing sub-transactions based on the real-time performance indicators of each service node, which can improve the stability and response speed of the system in a high-concurrency environment, thereby ensuring the consistency of data in each service node, and processing each sub-transaction through a three-phase commit algorithm helps to avoid transaction blocking, thereby improving transaction processing efficiency.

[0058] The technical solution of the present disclosure is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] The above and other purposes, features and advantages of the present disclosure will become more apparent by describing the embodiments of the present disclosure in more detail in conjunction with the accompanying drawings. The accompanying drawings are used to provide a further understanding of the embodiments of the present disclosure and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the present disclosure and do not constitute a limitation of the present disclosure. In the drawings, the same reference numerals generally represent the same components or steps.

[0060] The present disclosure may be more clearly understood from the following detailed description with reference to the accompanying drawings, in which:

[0061] Figure 1 A distributed system framework diagram provided for an exemplary embodiment of the present disclosure;

[0062] Figure 2 A flowchart of a method for processing distributed transactions provided by an exemplary embodiment of the present disclosure;

[0063] Figure 3 A schematic diagram of a process for processing transactions based on a three-phase commit algorithm provided by an exemplary embodiment of the present disclosure;

[0064] Figure 4A schematic diagram of a process for determining a real-time performance indicator of a service node provided by an exemplary embodiment of the present disclosure;

[0065] Figure 5 A flowchart of a method for processing distributed transactions provided by another exemplary embodiment of the present disclosure;

[0066] Figure 6 A schematic diagram of the structure of an embodiment of a distributed transaction processing device disclosed in the present invention;

[0067] Figure 7 A structural diagram of another embodiment of the distributed transaction processing device disclosed in the present invention;

[0068] Figure 8 A structural diagram of an electronic device provided for an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0069] Below, the exemplary embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all the embodiments of the present disclosure, and it should be understood that the present disclosure is not limited to the exemplary embodiments described here.

[0070] It should be noted that the relative arrangement of components and steps, the numerical expressions and numerical values ​​set forth in these embodiments do not limit the scope of the present disclosure unless specifically stated otherwise.

[0071] Those skilled in the art can understand that the terms "first" and "second" in the embodiments of the present disclosure are only used to distinguish different steps, devices or modules, etc., and neither represent any specific technical meaning nor indicate the necessary logical order between them.

[0072] It should also be understood that in the embodiments of the present disclosure, “plurality” may refer to two or more than two, and “at least one” may refer to one, two, or more than two.

[0073] It should also be understood that any component, data or structure mentioned in the embodiments of the present disclosure can generally be understood as one or more, unless explicitly limited or otherwise indicated in the context.

[0074] In addition, the term "and / or" in the present disclosure is only a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in the present disclosure generally indicates that the associated objects before and after are in an "or" relationship.

[0075] It should also be understood that the description of the various embodiments in the present disclosure focuses on the differences between the various embodiments, and the same or similar aspects thereof can be referenced to each other, and for the sake of brevity, they will not be described one by one.

[0076] At the same time, it should be understood that for the convenience of description, the sizes of the various parts shown in the drawings are not drawn according to the actual proportional relationship.

[0077] The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the present disclosure, its application, or uses.

[0078] Technologies, methods, and equipment known to ordinary technicians in the relevant art may not be discussed in detail, but where appropriate, the technologies, methods, and equipment should be considered as part of the specification.

[0079] It should be noted that like reference numerals and letters refer to similar items in the following figures, and therefore, once an item is defined in one figure, it need not be further discussed in subsequent figures.

[0080] The disclosed embodiments can be applied to electronic devices such as terminal devices, computer systems, servers, etc., which can operate with many other general or special computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, servers, etc. include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network personal computers, small computer systems, large computer systems, and distributed cloud computing technology environments including any of the above systems, etc.

[0081] Electronic devices such as terminal devices, computer systems, servers, etc. can be described in the general context of computer system executable instructions (such as program modules) executed by computer systems. Generally, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in a distributed cloud computing environment, where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can be located on local or remote computing system storage media including storage devices.

[0082] SUMMARY OF THE DISCLOSURE

[0083] The technical solution provided by the embodiments of the present disclosure is used to solve the problem of distributed transaction processing and can be applied to various business fields, such as e-commerce, payment, housing transactions, etc. In the related art, it is necessary to copy and synchronize data between multiple nodes, and factors such as network delays and node failures can lead to inconsistent data on each node, which is more likely to lead to inconsistent data on each node in a high-concurrency transaction environment.

[0084] Through the technical solution disclosed in the present invention, by determining the target service node for processing sub-transactions based on the real-time performance indicators of each service node, it is helpful to improve the stability and response speed of the system in a high-concurrency environment, thereby ensuring the consistency of data in each service node, and processing each sub-transaction through a three-phase commit algorithm helps to avoid transaction blocking, thereby improving transaction processing efficiency.

[0085] In the present disclosure, the data involved in distributed transaction processing may include inventory quantity, balance, transaction identification information, etc., among which each data is data collected and reported to meet the user privacy agreement and with the user's consent, and the collection, use and processing of relevant data comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse or revoke authorization.

[0086] Exemplary Systems

[0087] Figure 1 A distributed system framework diagram provided by an exemplary embodiment of the present disclosure. Figure 1 As shown, the distributed system architecture includes a client 101, a distributed transaction manager 102, a service node 103, a database 104, and a service gateway 105.

[0088] The client 101 may include a personal computer (PC), various applications or platforms (LIFE), applets, etc. The client 101 may send a transaction request to the distributed transaction manager 102 through the service gateway 105, such as a transaction to create an order, a transaction to generate a purchase order, etc.

[0089] The distributed transaction manager 102 is the coordinator in distributed transaction processing. After receiving the transaction request sent by the client 101, it can decide whether to process the transaction request based on its own load information and availability. After deciding to process the transaction request, the distributed transaction manager 102 splits the transaction into multiple sub-transactions and sends the multiple sub-transactions to the corresponding service nodes 103 for processing.

[0090] The distributed transaction manager 102 adopts a three-phase commit algorithm, that is, a three-phase commit protocol, including three phases: a preparation phase, a pre-commit phase, and a commit phase, so as to implement sub-transaction processing by each service node 103 .

[0091] In addition to the functions of disassembling transactions and implementing transaction processing through the three-phase commit protocol, the distributed transaction manager 102 also has the functions of recovering the results of sub-transactions processed by each service node 103, load balancing, intelligent routing, data consistency verification, abnormality alarm, data recovery, etc. Among them, by recovering the results of sub-transactions processed by each service node 103, data consistency verification can be performed, and abnormality alarm and data recovery operations can be performed when there are abnormal results; while load balancing and intelligent routing represent that the distributed transaction manager 102 can automatically select the target service node for processing each sub-transaction according to the load information of each service node, and realize automatic adjustment of the service node of the sub-transaction according to the actual status of the service node, thereby improving the performance and reliability of the system.

[0092] There are multiple distributed transaction managers 102 . Different distributed transaction managers 102 can be used to process different transactions and are responsible for interacting with different service nodes 103 .

[0093] The service node 103 is a server for processing each sub-transaction, such as an inventory server for processing a reserved inventory sub-transaction, an order server for processing an order sub-transaction, a purchase server for processing a purchase sub-transaction, etc. Each service node can be connected to a different distributed transaction manager 102 .

[0094] The database 104 is used to store business data. The database can be a relational database, a document-oriented database, a key-value storage database, or other types of databases. Each service node can update the business data in the database from time to time after processing a sub-transaction.

[0095] The service gateway 105 is used to provide services such as routing and load balancing, and can receive transaction requests from the client 101 and forward them to the corresponding distributed transaction manager 102 .

[0096] Exemplary Methods

[0097] Figure 2 A flow chart of a distributed transaction processing method provided by an exemplary embodiment of the present disclosure; the distributed transaction processing method can be applied to electronic devices (such as computer systems, servers), such as Figure 1 On the distributed transaction manager 102 in the embodiment, the distributed transaction processing method includes the following steps:

[0098] In step 201, a distributed transaction to be processed is split into multiple sub-transactions.

[0099] The pending distributed transaction is the transaction requested to be processed in the transaction request sent by the client. The transaction request carries the transaction type, transaction identification information, and transaction data of the pending distributed transaction. The transaction type may include creating an order, updating inventory, generating a purchase order, generating an outbound order, and other different types; the transaction identification information is used to uniquely identify a transaction; the transaction data includes specific operation data, such as the delivery party identification information, product code, logistics method, and other data.

[0100] In this embodiment, based on various pre-configured transaction types and corresponding sub-transaction processes, the transaction to be processed can be decomposed into multiple sub-transactions and executed in sequence.

[0101] Exemplarily, the transaction type of the pending distributed transaction is creating an order. Based on the pre-configured sub-transaction process of creating an order, the pending distributed transaction can be split into multiple sub-transactions such as receiving order requirements, supplementing basic information, splitting orders, reserving inventory, deducting balance, sending notifications, etc.

[0102] In this embodiment, when a distributed transaction to be processed is split into multiple sub-transactions, execution data of each sub-transaction can be generated accordingly, including: the operation corresponding to the sub-transaction, sub-transaction identification information, sub-transaction type, business parameters, data version number and timeout threshold.

[0103] Among them, the operation corresponding to the subtransaction is used to indicate the operation that each subtransaction needs to perform, for example, the operation corresponding to the pre-occupied inventory subtransaction is the operation of checking inventory; the business parameter is used to indicate the business data required to execute the subtransaction, for example, the business parameter of the "pre-occupied inventory" subtransaction is "SKU = 'ABC123', quantity = 10, warehouse ID = BJ-001"; the data version number is used to indicate the version number of the data facing the subtransaction, for example, the data version number is v1.2; the timeout threshold is used to indicate the response time threshold set for the service node. If the target service node does not return a response message when the timeout threshold is reached, it can be confirmed that it has timed out and the corresponding timeout processing flow is executed.

[0104] In step 202, a target service node for processing each sub-transaction is determined based on the real-time performance indicators of each service node in the service node set of each sub-transaction.

[0105] Among them, the service node set is a cluster of multiple service nodes used to process each sub-transaction. For example, the service node set for the pre-order inventory sub-transaction includes service node 1, service node 2, and service node 3, and the service node set for the balance deduction sub-transaction includes service node 4, service node 5, and service node 6.

[0106] Among them, the real-time performance index of the service node is an evaluation standard for measuring the real-time performance of the service node, which may include the response time, throughput, concurrent energy, network bandwidth, resource utilization, etc. of the service node. The real-time performance index of the service node can be obtained based on the current load information of the service node (such as the number of sub-transactions to be processed), the resource occupancy information of the service node, and various data statistics such as the historical transaction response time and the historical transaction processing results.

[0107] In this embodiment, for each sub-transaction, a service node with the highest real-time performance index may be selected from the corresponding service node set as a target service node for processing the sub-transaction.

[0108] In step 203, a prepare request message is sent to the target service node of each sub-transaction respectively, and the prepare request message carries the execution data of the corresponding sub-transaction.

[0109] The prepare request message includes transaction identification information and execution data of the corresponding subtransaction. The execution data of the subtransaction includes the operation corresponding to the subtransaction, subtransaction identification information, subtransaction type, business parameters, data version number and timeout threshold.

[0110] For example, creating an order is divided into sub-transactions such as receiving order requirements, supplementing basic information, splitting orders, reserving inventory, deducting balance, sending notifications, etc. Among them, the operation corresponding to the "reserving inventory" sub-transaction is "inventory check", the sub-transaction identification information is UTOPIA-001-STOCK, the sub-transaction type is reserving inventory, the business parameters are "SKU = 'ABC123', quantity = 10, warehouse ID = BJ-001", the data version number is v1.2, and the timeout threshold is 30 seconds.

[0111] In this embodiment, the preparation request message is used to inquire whether each target service node has the conditions to execute the corresponding sub-transaction. Each target service node can determine whether it has the conditions to execute the corresponding sub-transaction based on the execution data. For example, the target service node checks whether the data version number of the locally stored data is consistent with the data version number carried in the preparation request message. If it is inconsistent, it means that the target service node does not have the conditions to execute the sub-transaction; or, for the inventory pre-occupancy sub-service, if the target service node checks the inventory and finds that the inventory is 0, it does not have the conditions to pre-occupy the inventory, and therefore does not have the conditions to execute the inventory pre-occupancy sub-service; or, if the current performance index of the target service node is low, and the conditions for responding to any sub-transaction exceed 30 seconds, it can also be determined that it does not have the conditions to execute the inventory pre-occupancy sub-service; or, the target service node attempts to access the database to determine whether it can correctly access the database. If the database cannot be accessed, it can also be determined that it does not have the conditions to execute the inventory pre-occupancy sub-service.

[0112] In step 204, in response to receiving the first response message returned by each target service node based on the prepare request message, and each first response message indicates that the target service node is qualified to execute the corresponding sub-transaction, a pre-commit request message is sent to the target service node of each sub-transaction respectively.

[0113] The first response message may carry indication information on whether the target service node is capable of executing the corresponding sub-transaction.

[0114] In this embodiment, after receiving the first response message returned by each target service node based on the prepare request message, the distributed transaction manager determines whether each target service node has the conditions to execute the corresponding sub-transaction based on the indication information therein, and sends a pre-commit request message to the target service node of each sub-transaction respectively when all target service nodes have the conditions to execute the corresponding sub-transaction. If the distributed transaction manager does not receive the first response message sent by all target service nodes, or determines that a target service node does not have the conditions to execute the corresponding sub-transaction based on the indication information therein, the abort operation of aborting the processing of the pending distributed transaction can be executed.

[0115] In some implementations, the pre-commit request message includes transaction identification information and execution data of the corresponding sub-transaction. The execution data of the sub-transaction includes the operation corresponding to the sub-transaction, sub-transaction identification information, sub-transaction type, business parameters, data version number, and timeout threshold. The data included in the pre-commit request message is the same as the message carried by the prepare request message.

[0116] In some implementations, the pre-commit request message includes transaction identification information and sub-transaction identification information of the corresponding sub-transaction, but does not include the operation, sub-transaction type, business parameters, data version number, and timeout threshold corresponding to the sub-transaction. The corresponding target service node can read the operation, sub-transaction type, business parameters, data version number, and timeout threshold corresponding to the sub-transaction from the cache based on the transaction identification information and the sub-transaction identification information of the corresponding sub-transaction.

[0117] In some implementations, when determining whether a first response message returned by each target service node based on a prepare request message is received, it can be determined whether the first response message is received within a timeout threshold. If the first response message is still not received when the timeout threshold is exceeded, it can be determined that the first response message has not been received.

[0118] In step 205, in response to receiving the second response message returned by each target service node based on the pre-commit request message, and each second response message indicates that the target service node pre-commit is successful, a commit request message is sent to the target service node of each sub-transaction.

[0119] The second response message may carry indication information of whether the target service node has successfully pre-submitted. The submission request message includes transaction identification information and execution data of the corresponding sub-transaction, and the submission request message is used to instruct each target service node to submit the corresponding sub-transaction.

[0120] In this embodiment, after receiving the second response message returned by each target service node based on the pre-commit request message, the distributed transaction manager determines whether each target service node has successfully pre-committed based on the indication information therein, and when all target service nodes have successfully pre-committed, sends a commit request message to the target service node of each sub-transaction. After receiving the commit request message, the target service node formally commits the transaction and completes the processing of the sub-transaction.

[0121] In the above steps 201 to 205, when it is necessary to process a distributed transaction, the distributed transaction to be processed is split into multiple sub-transactions; based on the real-time performance indicators of each service node in the service node set of each sub-transaction, the target service node for processing each sub-transaction is determined; a prepare request message is sent to the target service node of each sub-transaction respectively, and the prepare request message carries the execution data of the corresponding sub-transaction; in response to receiving a first response message returned by each target service node based on the prepare request message, and each first response message indicates that the corresponding target service node has the conditions to execute the corresponding sub-transaction, a pre-commit request message is sent to the target service node of each sub-transaction respectively; in response to receiving a second response message returned by each target service node based on the pre-commit request message, and each second response message indicates that the target service node has successfully pre-committed, a commit request message is sent to the target service node of each sub-transaction respectively, and the commit request message is used to instruct each target service node to commit the corresponding sub-transaction. Therefore, the technical solution disclosed in the present invention selects the target service node for processing sub-transactions based on the real-time performance indicators of each service node, which can improve the stability and response speed of the system in a high-concurrency environment, thereby ensuring the consistency of data in each service node, and processing each sub-transaction through a three-phase commit algorithm helps to avoid transaction blocking, thereby improving transaction processing efficiency.

[0122] In order to better illustrate the solution for processing distributed transactions disclosed in the present invention, another embodiment is used below for illustration.

[0123] Figure 3 A flowchart of a transaction processing based on a three-phase commit algorithm provided by an exemplary embodiment of the present disclosure; this embodiment uses how to complete transaction processing through a three-phase commit algorithm as an example for exemplary description, such as Figure 3 As shown, the following steps are included:

[0124] In step 301, a prepare request message is sent to a target service node of each sub-transaction respectively, and the prepare request message carries execution data of the corresponding sub-transaction.

[0125] Further, if a first response message from the service node is received after the accurate request message is sent, step 302 is executed; if a first response message from the service node is not received after the accurate request message is sent, step 309 is executed.

[0126] In step 302, in response to receiving the first response message returned by each target service node based on the prepare request message, and each first response message indicates that the target service node is qualified to execute the corresponding sub-transaction, a pre-commit request message is sent to the target service node of each sub-transaction.

[0127] Further, if a second response message from the service node is received after the pre-submission request message is sent, step 303 is executed; if a second response message from the service node is not received after the pre-submission request message is sent, step 304 is executed.

[0128] In step 303, in response to receiving the second response message returned by each target service node based on the pre-commit request message, and each second response message indicates that the target service node pre-commit is successful, a commit request message is sent to the target service node of each sub-transaction.

[0129] The specific implementation of steps 301 to 303 can be found in Figure 2 Steps 203 to 205 of the illustrated embodiment will not be described in detail here.

[0130] Further, if the distributed transaction manager does not receive the second response messages sent by all target service nodes, or determines based on the indication information therein that a target service node fails in pre-commit, step 304 may be executed.

[0131] In step 304, in response to not receiving the second response message returned by each target service node based on the pre-commit request message, or the presence of a second response message indicating that the target service node pre-commit failed, a rollback request message is sent to the target service node of each sub-transaction.

[0132] The rollback request message is used to instruct the target service node to roll back the pre-commit operation and cancel the processing of the corresponding sub-transaction.

[0133] In step 305, the rollback status of each target service node is determined.

[0134] In this embodiment, after the distributed transaction manager sends the rollback request message, the target service node checks the execution status of the sub-transaction and determines the operation that needs to be rolled back, such as canceling inventory reservation, restoring the deducted balance, etc. After completing each rollback operation, a rollback response message is returned to the distributed transaction manager, and the rollback response message carries the rollback status. The distributed transaction manager can determine the rollback status of the target service node based on the rollback response messages returned by each target service node.

[0135] The rollback status is used to indicate the result of the rollback operation performed by the target service node. The rollback status includes rollback success and rollback failure.

[0136] Further, if the rollback status of each target service node indicates that the rollback is successful, step 306 is executed; if the rollback of a target service node fails, step 308 is executed.

[0137] In step 306, in response to the rollback status of each target service node indicating that the rollback is successful, a consistency check is performed on the service data in each target service node.

[0138] The consistency check is used to indicate to check the consistency of the rolled-back data of each target service node to determine whether the data in each target service node is consistent.

[0139] In some implementations, the business data in each target service node, such as inventory quantity, balance, etc., can be obtained, and the consistency check can be performed on the business data. In specific implementation, the business data status in the database at each time point can be obtained through the database snapshot algorithm, and the database snapshots can be compared. If the database snapshots are consistent, it can be determined that the business data of each target service node is rolled back to the state before the subtransaction is executed; if the database snapshots are consistent, it can be determined that the business data of each target service node is not rolled back to the state before the subtransaction is executed.

[0140] Further, if the database snapshot is inconsistent and the consistency check fails, step 307 is executed.

[0141] In step 307, in response to the result of the consistency check being inconsistent, an exception handling operation is performed, and the exception handling operation includes at least one of the following: undoing the data change operation before the consistency check, synchronizing the data operation, and triggering an alarm operation.

[0142] Among them, the operation of canceling the data change before the consistency check is used to instruct to perform the rollback operation again to cancel the data changes made by the current sub-transaction. The operation of synchronizing data is used to instruct to perform data synchronization again according to the database backup to ensure data consistency. The alarm operation is used to instruct to send an alarm prompt information to the operation manager or system manager to prompt that there is a problem that the data consistency check has not passed, so that the manager can intervene and handle it to ensure data consistency.

[0143] In this embodiment, there are various ways to perform exception handling operations so as to ensure data consistency.

[0144] In step 308, in response to the existence of a target service node that fails to roll back, an alarm prompt message is generated.

[0145] The target service nodes that fail to roll back include service nodes that have not been successfully rolled back after the rollback times exceed the set times, and service nodes that have not been successfully rolled back after the rollback time exceeds the set time.

[0146] In this embodiment, if a target service node fails to roll back, a retry process can be triggered, and a rollback request message can be sent to the target service node again until the rollback is successful; if the rollback is repeated multiple times, such as 5 times without success, and the rollback time exceeds the set time, such as 5 minutes, and the rollback is still not successful, an alarm prompt message can be generated to notify the operation management personnel or system management personnel to perform manual intervention.

[0147] In step 309, in response to not receiving the first response message returned by each target service node based on the prepare request message, or the presence of a first response message indicating that the target service node does not have the conditions to execute the corresponding sub-transaction, an abort operation of aborting the processing of the pending distributed transaction is performed.

[0148] The abort operation is used to indicate the cancellation of the operation process of the corresponding sub-transaction currently being executed by each target service node, and is used to abort the current three-phase commit process.

[0149] In this embodiment, if a target service node performs a data change operation after receiving an accurate request message, for example, a target service node that performs inventory pre-booking processing performs an inventory pre-booking operation and modifies the inventory quantity after receiving an accurate request message, then when executing the abort operation, it is necessary to synchronously instruct the corresponding target service node to perform a rollback operation.

[0150] Through the above steps 301 to 309, distributed transactions are executed based on the three-phase commit process, which can effectively improve the stability and response speed of the system in a high-concurrency environment, help avoid transaction blocking, and thus improve transaction processing efficiency; in addition, when data inconsistency is found, exception handling operations are initiated, and the data status is restored through a variety of exception handling methods to ensure data consistency.

[0151] Figure 4 A flowchart of determining a real-time performance indicator of a service node provided by an exemplary embodiment of the present disclosure; this embodiment takes how to determine the real-time performance indicator of a service node as an example for exemplary description, such as Figure 4 As shown, the following steps are included:

[0152] In step 401, a performance detection algorithm is used to obtain a first performance parameter of each service node, the first performance parameter including historical transaction response time and historical transaction processing results; and a heartbeat signal is used to obtain a second performance parameter of each service node, the second performance parameter including load information.

[0153] The performance detection algorithm is used to indicate an algorithm, software, etc. that can collect the first performance parameter of the service node in real time, and the performance detection algorithm can be installed in the distributed transaction manager. The first performance parameter is used to measure the execution effect of the service node in executing historical transactions.

[0154] In the present disclosure, the historical transaction response time is used to indicate the response time of the service node when executing each transaction before the current time point. After each transaction is executed, the corresponding response time can be collected by the performance detection algorithm. Among them, the response time may include the response time of the target service node at each stage in the three-stage submission process, and may include the sum of the response time at each stage.

[0155] In the present disclosure, historical transaction processing results are used to indicate the execution results of the service node when executing each transaction before the current time point, such as the results of successful execution, failed execution, etc. After each transaction is executed, the corresponding execution results can be collected by the performance detection algorithm. Among them, the execution results may include the execution results of the target service node at each stage in the three-stage commit process, such as the results of the preparation stage, the results of the pre-commit stage, the results of the commit stage, the results of the rollback, etc.

[0156] In some optional implementations, the specific method of obtaining the first performance parameter of each service node is as follows: using a performance detection algorithm, obtain the number of historical transactions processed by each service node in the historical time period, the response time of each historical transaction, and the processing result of each historical transaction; based on the number of historical transactions and the response time of each historical transaction, determine the average response time of each service node processing historical transactions in the historical time period, and the average response time is the historical transaction response time; based on the number of historical transactions and the processing result of each historical transaction, determine the statistical processing result of each service node processing historical transactions in the historical time period, and the statistical processing result is the historical transaction processing result.

[0157] The historical time period is a time period before the current time point, for example, 3 hours before the current time point. After each transaction is executed, the response time and processing results corresponding to the transaction are collected through the performance detection algorithm, and the number of transactions processed by each service node in the historical time period is counted. According to the response time of all transactions in the historical time period, the total response time is calculated, and then according to the number of transactions, the average response time for processing historical transactions in the historical time period can be obtained. According to the processing results of all transactions in the historical time period at different stages, the number of transactions with successful processing results and the number of transactions with failed processing results are counted respectively, and the statistical processing results of historical transactions in the historical time period can be obtained.

[0158] The heartbeat signal is a very small data packet sent by the distributed transaction manager to the service node at regular intervals. It is used to determine whether the communication link between the two parties has been disconnected through the reply information of the service node and to obtain the load information and resource occupancy information of the service node.

[0159] In the present disclosure, after the distributed transaction manager sends a heartbeat signal, it can receive a reply signal sent by the service node, and obtain the second performance parameter of the service node by parsing the reply signal.

[0160] The second performance parameter is used to indicate the real-time processing performance of the service node, and may include the load information of the service node. Load information refers to the ability and load level of the service node to process and respond to transaction requests at the current time point, and is an important indicator for measuring the performance and resource utilization of the service node. The load information of the service node is measured by multiple indicators, including CPU utilization, memory utilization, disk I / O load, network bandwidth utilization, etc.

[0161] In step 402, a real-time performance indicator of each service node is determined based on the first performance parameter and the second performance parameter.

[0162] Among them, the first performance parameter is used to measure the execution effect of the service node in executing historical transactions, and the second performance parameter is used to measure the real-time processing performance of the service node. By weighting the first performance parameter and the second performance parameter, the real-time performance index of each service node can be determined.

[0163] Through the above steps 401 to 402, the real-time performance indicators of each service node are determined by using the first performance parameter for measuring the execution effect of historical transactions and the second performance parameter for measuring the real-time processing performance of the service node. This helps to subsequently determine the target service node for processing sub-transactions based on the real-time performance indicators of each service node, thereby improving the efficiency and effectiveness of the service node in processing transactions.

[0164] Figure 5 A flowchart of a method for processing a distributed transaction provided by another exemplary embodiment of the present disclosure is provided; this embodiment takes how to process a distributed transaction as an example for exemplary description. Figure 2 Based on the embodiment shown, after step 205, the following steps are also included:

[0165] In step 501, based on the data change information after each target service node processes each sub-transaction, a consistency check is performed on the business data in each target service node.

[0166] In this embodiment, when each target service node processes a sub-transaction and submits data change information, the distributed transaction manager obtains the business data of each service node, such as inventory quantity and balance, based on the data change information of each target service node, and then compares whether the business data of each service node is consistent, and determines whether each key data satisfies the business logic, such as whether the inventory is not a negative value.

[0167] In this embodiment, when consistency check is performed on the service data in each target service node, in order to reduce the amount of calculation for the check, only the data that has been changed in each target service node may be checked.

[0168] In step 502, in response to the result of the consistency check being inconsistent, an exception handling operation is performed, and the exception handling operation includes at least one of the following: undoing the data change operation before the consistency check, synchronizing the data operation, and triggering an alarm operation.

[0169] Among them, the operation of canceling the data change before the consistency check is used to instruct to perform the rollback operation again to cancel the data changes made by the current sub-transaction. The operation of synchronizing data is used to instruct to perform data synchronization again according to the database backup to ensure data consistency. The alarm operation is used to instruct to send an alarm prompt information to the operation manager or system manager to prompt that there is a problem that the data consistency check has not passed, so that the manager can intervene and handle it to ensure data consistency.

[0170] Through the above steps 501 to 502, a method for consistency checking of data after each service node executes a transaction and an exception handling method when the consistency check fails are disclosed. Through consistency checking and exception handling, the consistency of data in each service node can be further ensured.

[0171] Corresponding to the embodiments of the aforementioned method for processing distributed transactions, the present disclosure also provides corresponding embodiments of the apparatus for processing distributed transactions.

[0172] Exemplary Devices

[0173] Figure 6 FIG. 1 is a schematic diagram of a structure of an embodiment of a distributed transaction processing device disclosed in the present invention. The device is applied to an electronic device (such as a computer system or a server). Figure 6 As shown, the device comprises:

[0174] A splitting module 61 is used to split a to-be-processed distributed transaction into multiple sub-transactions;

[0175] A node determination module 62, which determines a target service node for processing each sub-transaction based on the real-time performance indicators of each service node in the service node set of each sub-transaction;

[0176] A preparation module 63, configured to send a preparation request message to a target service node of each sub-transaction respectively, wherein the preparation request message carries execution information of the corresponding sub-transaction;

[0177] The pre-commit module 64 is used to send a pre-commit request message to the target service node of each sub-transaction in response to receiving a first response message returned by each target service node based on the prepare request message, and each first response message indicates that the corresponding target service node has the conditions for executing the corresponding sub-transaction;

[0178] The submission module 65 is used to send a submission request message to the target service node of each sub-transaction in response to receiving a second response message returned by each target service node based on the pre-submission request message, and each second response message indicates that the pre-submission of the target service node is successful. The submission request message is used to instruct each target service node to submit the corresponding sub-transaction.

[0179] Figure 7 FIG. 1 is a structural diagram of another embodiment of the distributed transaction processing device disclosed in the present invention. Figure 7 As shown, in Figure 6 Based on the illustrated embodiment, in some embodiments of the present disclosure, the device further includes:

[0180] A first acquisition module 66 is used to acquire a first performance parameter of each service node, where the first performance parameter includes at least one of the following: historical transaction response time, historical transaction processing result; and

[0181] A second acquisition module 67 is used to acquire a second performance parameter of each service node using a heartbeat signal, where the second performance parameter includes load information;

[0182] The performance determination module 68 is used to determine the real-time performance index of each service node based on the first performance parameter and the second performance parameter.

[0183] In some other embodiments of the present disclosure, the first acquisition module 66 is used to: use a performance detection algorithm to obtain the number of historical transactions processed by each service node in the historical time period, the response time of each historical transaction, and the processing result of each historical transaction for statistics; based on the number of historical transactions and the response time of each historical transaction, determine the average response time of each service node in processing the historical transactions in the historical time period, and the average response time is the historical transaction response time; based on the number of historical transactions and the processing result of each historical transaction, determine the statistical processing result of each service node in processing the historical transactions in the historical time period, and the statistical processing result is the historical transaction processing result.

[0184] In some further embodiments of the present disclosure, the device comprises:

[0185] The abort processing module 69 is used to execute an abort operation of aborting the processing of the pending distributed transaction in response to not receiving the first response message returned by each target service node based on the prepare request message, or the first response message indicates that the target service node does not have the condition to execute the corresponding sub-transaction;

[0186] The rollback module 70 is used to send a rollback request message to the target service node of each sub-transaction in response to not receiving the second response message returned by each target service node based on the pre-commit request message, or there is a second response message indicating that the pre-commit of the target service node fails.

[0187] In some further embodiments of the present disclosure, the device comprises:

[0188] A state determination module 71, used to determine the rollback state of each target service node;

[0189] A first verification module 72, configured to perform consistency verification on the service data in each target service node in response to the rollback status of each target service node indicating that the rollback is successful;

[0190] The first exception handling module 73 is used to perform an exception handling operation in response to the result of the consistency check being inconsistent, and the exception handling operation includes at least one of the following: canceling the data change operation before the consistency check, synchronizing the data operation, and triggering an alarm operation.

[0191] In some further embodiments of the present disclosure, the device comprises:

[0192] The alarm module 74 is used to generate an alarm prompt message in response to a target service node that fails to roll back. The target service node that fails to roll back includes a service node that has not rolled back successfully after the rollback times exceed the set times, and a service node that has not rolled back successfully after the rollback time exceeds the set time.

[0193] In some further embodiments of the present disclosure, the device further comprises:

[0194] A second verification module 75, configured to perform consistency verification on the business data in each target service node based on the data change information after each target service node processes each sub-transaction;

[0195] The second exception handling module 76 is used to perform an exception handling operation in response to the result of the consistency check being inconsistent. The exception handling operation includes at least one of the following: canceling the data change operation before the consistency check, synchronizing the data operation, and triggering an alarm operation.

[0196] The modules and units in the device disclosed in the present invention can also be divided into finer granularity according to actual needs, and can be specifically set according to actual needs.

[0197] The device of the embodiment of the present disclosure can be used to implement the methods of the above-mentioned embodiments of the present disclosure. The two correspond to each other in specific implementation, and the specific implementations of related parts are referenced to each other, which will not be repeated here.

[0198] Exemplary electronic devices, computer program products, and computer-readable storage media

[0199] An embodiment of the present disclosure further provides an electronic device, comprising: a memory for storing a computer program; a processor for executing the computer program stored in the memory, and when the computer program is executed, the distributed transaction processing method of any of the above embodiments of the present disclosure is implemented.

[0200] Below, reference Figure 8 An electronic device according to an embodiment of the present disclosure is described, in which a device for implementing the method according to an embodiment of the present disclosure may be integrated. Figure 8 A structural diagram of an electronic device provided in an exemplary embodiment of the present disclosure, such as Figure 8As shown, the electronic device includes one or more processors 81, one or more computer-readable storage media memory 82, and a computer program stored in the memory and executable on the processor. When executing the program in the memory 82, the above-mentioned distributed transaction processing method can be implemented.

[0201] Specifically, in practical applications, the electronic device may further include components such as an input device 83 and an output device 84, and these components are interconnected via a bus system and / or other forms of connection mechanisms (not shown). Those skilled in the art will appreciate that Figure 8 The structure of the electronic device shown in the figure does not constitute a limitation of the electronic device, and may include more or less components than shown in the figure, or certain components, or different component arrangements.

[0202] in:

[0203] The processor 81 can be a central processing unit (CPU) or other forms of processing units with distributed transaction processing capabilities and / or instruction execution capabilities. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 82, and calling data stored in the memory 82, thereby monitoring the electronic device as a whole.

[0204] The memory 82 may include one or more computer program products, and the computer program product may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory (cache), etc. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on a computer-readable storage medium, and the processor 81 may run the program instructions to implement the processing method of distributed transactions of the various embodiments of the present disclosure above and / or other desired functions. Various contents such as input signals, signal components, noise components, etc. may also be stored in the computer-readable storage medium.

[0205] The input device 83 can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.

[0206] The output device 84 can output various information to the outside, including the determined distance information, direction information, etc. The output device 84 can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and the like.

[0207] The electronic device may also include a power supply for supplying power to various components, which may be logically connected to the processor 81 through a power management system, so as to manage charging, discharging, power consumption and other functions through the power management system. The power supply may also include one or more DC or AC power supplies, recharging systems, power failure detection circuits, power converters or inverters, power status indicators and other arbitrary components.

[0208] Of course, to simplify, Figure 8 Only some of the components related to the present disclosure in the electronic device are shown, and components such as a bus, an input / output interface, etc. are omitted. In addition, according to specific application situations, the electronic device may further include any other appropriate components.

[0209] In addition to the above-mentioned methods and devices, an embodiment of the present disclosure may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the distributed transaction processing method according to various embodiments of the present disclosure described in the above-mentioned "Exemplary Method" section of this specification.

[0210] The computer program product may be written in any combination of one or more programming languages ​​to write program code for performing the operations of the disclosed embodiments, including object-oriented programming languages ​​such as Java, C++, etc., and 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 separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0211] In addition, an embodiment of the present disclosure may also be a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the processor executes the steps of the method for processing distributed transactions according to various embodiments of the present disclosure described in the above "Exemplary Method" section of this specification.

[0212] Computer readable storage media can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can include, for example, but is not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (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 of the above.

[0213] The basic principles of the present disclosure are described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, effects, etc. mentioned in the present disclosure are only examples and not limitations, and it cannot be considered that these advantages, strengths, effects, etc. are required by each embodiment of the present disclosure. In addition, the specific details disclosed above are only for the purpose of illustration and ease of understanding, and are not limitations. The above details do not limit the present disclosure to the necessity of adopting the above specific details to be implemented.

[0214] Each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the system embodiment, since it basically corresponds to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0215] A person of ordinary skill in the art can understand that all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: ROM, RAM, magnetic disk or optical disk, etc., various media that can store program codes.

[0216] The method and apparatus of the present disclosure may be implemented in many ways. For example, the method and apparatus of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above order of steps for the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above, unless otherwise specifically stated. In addition, in some embodiments, the present disclosure may also be implemented as a program recorded in a recording medium, which includes machine-readable instructions for implementing the method according to the present disclosure. Therefore, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[0217] The description of the present disclosure is given for the purpose of illustration and description, and is not intended to be exhaustive or to limit the present disclosure to the disclosed form. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments are selected and described in order to better illustrate the principles and practical applications of the present disclosure, and to enable those of ordinary skill in the art to understand the present disclosure and thereby design various embodiments with various modifications suitable for specific uses.

Claims

1. A distributed transaction processing method, characterized in that: include: Split the pending distributed transaction into multiple sub-transactions; Based on the real-time performance indicators of each service node in the service node set corresponding to each sub-transaction, a target service node for processing each sub-transaction is determined respectively; Sending a prepare request message to the target service node of each sub-transaction respectively, wherein the prepare request message carries the execution data of the corresponding sub-transaction; In response to receiving a first response message returned by each target service node based on the prepare request message, and each first response message indicates that the corresponding target service node is qualified to execute the corresponding sub-transaction, respectively sending a pre-commit request message to the target service node of each sub-transaction; In response to receiving the second response message returned by each target service node based on the pre-submission request message, and each second response message indicates that the pre-submission of the target service node is successful, a submission request message is sent to the target service node of each sub-transaction respectively, and the submission request message is used to instruct each target service node to submit the corresponding sub-transaction.

2. The method according to claim 1, characterized in that Before determining the target service node for processing each sub-transaction based on the real-time performance index of each service node in the service node set corresponding to each sub-transaction, the method further includes: Acquire a first performance parameter of each service node, wherein the first performance parameter includes at least one of the following: historical transaction response time, historical transaction processing result; and Using the heartbeat signal, obtaining a second performance parameter of each service node, where the second performance parameter includes load information; Based on the first performance parameter and the second performance parameter, a real-time performance indicator of each service node is determined.

3. The method according to claim 2, characterized in that The obtaining of the first performance parameter of each service node includes: Obtain the number of historical transactions processed by each service node within the historical time period, the response time of each historical transaction, and the processing result of each historical transaction; Based on the number of historical transactions and the response time of each historical transaction, respectively determine the average response time of each service node processing the historical transaction within the historical time period, where the average response time is the historical transaction response time; Based on the number of historical transactions and the processing results of each historical transaction, the statistical processing results of the historical transactions processed by each service node within the historical time period are determined respectively, and the statistical processing results are the historical transaction processing results.

4. The method according to claim 1, characterized in that: After sending the prepare request message to the target service node of each sub-transaction respectively, the method further includes: In response to not receiving a first response message returned by each target service node based on the prepare request message, or the presence of a first response message indicating that the target service node does not have a condition for executing a corresponding sub-transaction, performing an abort operation of aborting processing of the pending distributed transaction; After sending the pre-commit request message to the target service node of each sub-transaction respectively, the method further includes: In response to not receiving a second response message returned by each target service node based on the pre-commit request message, or having a second response message indicating that the pre-commit of the target service node has failed, a rollback request message is sent to the target service node of each sub-transaction respectively.

5. The method according to claim 4, characterized in that After sending the rollback request message to the target service node of each sub-transaction respectively, the method further includes: Determine the rollback status of each target service node; In response to the rollback status of each target service node indicating that the rollback is successful, performing consistency check on the service data in each target service node; In response to the result of the consistency check being inconsistent, an exception handling operation is performed, and the exception handling operation includes at least one of the following: undoing the data change operation before the consistency check, synchronizing the data operation, and triggering an alarm operation.

6. The method according to claim 5, characterized in that After the rollback status of each target service node is determined, the method further includes: In response to a target service node that fails to roll back, an alarm prompt message is generated. The target service node that fails to roll back includes a service node that fails to roll back successfully after the rollback times exceed a set number, and a service node that fails to roll back successfully after the rollback time exceeds a set time.

7. The method according to claim 1, characterized in that After sending the submission request message to the target service node of each sub-transaction respectively, the method further includes: Based on the data change information after each target service node processes each sub-transaction, the business data in each target service node is checked for consistency; In response to the result of the consistency check being inconsistent, an exception handling operation is performed, and the exception handling operation includes at least one of the following: undoing the data change operation before the consistency check, synchronizing the data operation, and triggering an alarm operation.

8. A computer-readable storage medium, wherein the storage medium stores computer program instructions, and when the computer program instructions are executed, the method according to any one of claims 1 to 7 is implemented.

9. An electronic device, comprising: a memory for storing a computer program product; A processor is used to execute the computer program product stored in the memory, and when the computer program product is executed, it implements the method described in any one of claims 1 to 7.

10. A computer program product comprising computer program instructions, characterized in that When the computer program instructions are executed by a processor, the method described in any one of claims 1 to 7 is implemented.

Images