A distributed transaction processing method, device, equipment and medium

Abstract

The present invention discloses a distributed transaction processing method, device, equipment and medium. The method includes: determining a first service that participates in processing a pending transaction; sending a first preprocessing request to each first service, so that the first service preprocesses at least one sub-transaction based on the first preprocessing request; when the first preprocessing results fed back by some first services all meet the preset verification conditions, determining a second service from the first service based on the performance parameters to be selected of at least one service, sending a second preprocessing request to each second service, so that the second service preprocesses the sub-transaction again based on the second preprocessing request; when the second preprocessing results fed back by some second services all meet the preset verification conditions, sending an actual processing request to each first service, so that the first service actually processes the sub-transaction based on the actual processing request. The technical solution of the embodiment of the present invention achieves the effect of improving the reliability of distributed transaction processing and ensuring data consistency.

Description

Technical Field

[0001] The present invention relates to the field of computer processing technology, and in particular to a distributed transaction processing method, device, equipment and medium. Background Art

[0002] Today's Internet services usually adopt a distributed architecture to improve the scalability, high availability and performance of the system. However, in a distributed scenario, transaction management becomes more complex, especially when cross-system consistency operations need to be performed between different systems, which requires distributed transaction processing.

[0003] At present, the distributed transaction processing method usually adopts the three-phase model of TCC (Try Confirm Cancel) for distributed transaction processing. Based on this method, transaction processing requires that each transaction participant executes the actual transaction after the Try phase is successfully processed. However, in this process, there may be cases where the actual execution of the transaction participant fails, so that the data consistency between systems cannot be effectively guaranteed. Summary of the invention

[0004] The present invention provides a distributed transaction processing method, device, equipment and medium to improve the reliability of distributed transaction processing and ensure data consistency.

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

[0006] When receiving a pending transaction, determining at least one first service that participates in processing the pending transaction; wherein the pending transaction includes at least one sub-transaction;

[0007] Sending a first preprocessing request to each of the first services respectively, so that the first service preprocesses the at least one sub-transaction based on the first preprocessing request, and feeds back a first preprocessing result;

[0008] In a case where the first preprocessing results fed back by some of the first services all meet a preset verification condition, determining a service performance parameter corresponding to each of the first services based on the to-be-selected performance parameter of at least one service;

[0009] Determine at least one second service from the first service based on the service performance parameter, and send a second preprocessing request to each of the second services respectively, so that the second service preprocesses the at least one sub-transaction again based on the second preprocessing request, and feeds back a second preprocessing result;

[0010] When the second preprocessing results fed back by some of the second services meet the preset verification condition, an actual processing request is sent to each of the first services respectively, so that the first service actually processes the at least one sub-transaction based on the actual processing request.

[0011] According to another aspect of the present invention, there is provided a distributed transaction processing device, the device comprising:

[0012] A first service determination module, configured to determine, upon receiving a transaction to be processed, at least one first service that participates in processing the transaction to be processed; wherein the transaction to be processed includes at least one sub-transaction;

[0013] a first preprocessing module, configured to send a first preprocessing request to each of the first services respectively, so that the first service preprocesses the at least one sub-transaction based on the first preprocessing request, and feeds back a first preprocessing result;

[0014] a service performance parameter determination module, configured to determine, when the first preprocessing results fed back by some of the first services all meet a preset verification condition, a service performance parameter corresponding to each of the first services based on a to-be-selected performance parameter of at least one service;

[0015] a second preprocessing module, configured to determine at least one second service from the first service based on the service performance parameter, and send a second preprocessing request to each of the second services respectively, so that the second service preprocesses the at least one sub-transaction again based on the second preprocessing request, and feeds back a second preprocessing result;

[0016] The actual processing module is used to send an actual processing request to each of the first services respectively when the second preprocessing results fed back by some of the second services meet the preset verification conditions, so that the first service actually processes the at least one sub-transaction based on the actual processing request.

[0017] According to another aspect of the present invention, there is provided an electronic device, the electronic device comprising:

[0018] at least one processor; and

[0019] a memory communicatively connected to the at least one processor; wherein,

[0020] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the distributed transaction processing method described in any embodiment of the present invention.

[0021] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the distributed transaction processing method described in any embodiment of the present invention when executed.

[0022] The technical solution of the embodiment of the present invention is as follows: when receiving a transaction to be processed, at least one first service involved in processing the transaction to be processed is determined; the transaction to be processed includes at least one sub-transaction; a first preprocessing request is sent to each first service respectively, so that the first service preprocesses at least one sub-transaction based on the first preprocessing request, and feeds back the first preprocessing result; when the first preprocessing results fed back by some of the first services all meet the preset verification conditions, based on the to-be-selected performance parameters of at least one service, a service performance parameter corresponding to each first service is determined; based on the service performance parameters, at least one second service is determined from the first service, and a second preprocessing request is sent to each second service respectively, so that the second service preprocesses at least one sub-transaction again based on the second preprocessing request, and feeds back the second preprocessing result; when the second preprocessing results fed back by some of the second services all meet the preset verification conditions, Under the condition of setting verification conditions, an actual processing request is sent to each first service respectively, so that the first service actually processes at least one sub-transaction based on the actual processing request, which solves the problem of poor data consistency and low reliability in the prior art of processing distributed transactions based on the TCC mode. Before the formal execution of the transaction to be processed, a first preprocessing result fed back by at least one first service participating in processing the transaction to be processed is checked. If the check passes once, a second service with lower transaction processing reliability is selected according to the service performance parameters corresponding to each first service, and the second preprocessing result fed back by each second service is checked again. If the check passes again, the transaction to be processed is formally executed, thereby ensuring the success rate during formal execution and avoiding performance waste. At the same time, the performance and reliability of distributed transactions are improved to ensure data consistency.

[0023] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0025] Figure 1is a flow chart of a distributed transaction processing method provided according to Embodiment 1 of the present invention;

[0026] Figure 2 is a schematic diagram of a distributed transaction processing method provided according to Embodiment 1 of the present invention;

[0027] Figure 3 is a flow chart of a distributed transaction processing method provided according to Embodiment 2 of the present invention;

[0028] Figure 4 is a flow chart of a distributed transaction processing method provided according to Embodiment 3 of the present invention;

[0029] Figure 5 is a schematic diagram of the structure of a distributed transaction processing device provided according to Embodiment 5 of the present invention;

[0030] Figure 6 It is a schematic diagram of the structure of an electronic device for implementing the distributed transaction processing method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0031] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0033] Embodiment 1

[0034] Figure 11 is a flow chart of a distributed transaction processing method provided according to the first embodiment of the present invention. This embodiment is applicable to the case of processing distributed transactions. The method can be executed by a distributed transaction processing device. The distributed transaction processing device can be implemented in the form of hardware and / or software. The distributed transaction processing device can be configured in a computing device. Figure 1 As shown, the method includes:

[0035] S110. When receiving a transaction to be processed, determine at least one first service that participates in processing the transaction to be processed; the transaction to be processed includes at least one sub-transaction.

[0036] Among them, pending transactions can refer to global transactions that need to be processed. The pending transactions completed by different microservices through collaboration are called distributed transactions. Each distributed transaction can be understood as a sub-transaction in the pending transaction, and each microservice can be located on different nodes of the distributed system. For example, the pending transaction is an order settlement transaction. In the process of order settlement, the order settlement transaction is split into multiple sub-transactions, such as reducing inventory, creating orders, account submission, and sending resources after settlement. All of these can be considered sub-transactions. The first service can be a microservice that participates in transaction processing.

[0037] In this embodiment, when the transaction manager receives a global transaction, it is considered that a pending transaction is received. At this time, all services involved in processing the pending transaction can be used as first services, and each first service can respectively execute one or part of the sub-transactions in the pending transaction. For example, if the pending transaction is a settlement transaction, the first services involved in the settlement transaction can be: inventory service, order service, account service, reward service, compensation service, etc.

[0038] For example, see Figure 2 When a transaction coordinator (used to coordinate and manage multiple transaction participants to process distributed transactions) receives a request from a transaction manager to initiate a transaction (i.e., a pending transaction), a microservice participating in the transaction can be determined as the first service.

[0039] S120. Send a first preprocessing request to each first service respectively, so that the first service preprocesses at least one sub-transaction based on the first preprocessing request, and feeds back a first preprocessing result.

[0040] The first preprocessing request may be a program or code for requesting to attempt a business operation. The first preprocessing result may be preprocessing success or preprocessing failure.

[0041] In this embodiment, the transaction coordinator can send a first preprocessing request to each first service respectively, and each first service can call an interface to preprocess at least one sub-transaction in the first preprocessing request when receiving the first preprocessing request. Optionally, the preprocessing can be: performing business checks and resource reservations based on business rules, and feeding back the results of the preprocessing, which is the first preprocessing result. For example, the business check can be to verify the validity of the business data, such as checking whether the format, length, range, etc. of the input data meet the requirements; or, the business check can also be to determine whether the current business operation complies with the business rules and logic set by the system, such as checking whether the inventory is sufficient, whether the account resources meet the resources to be deducted, etc.

[0042] For example, see Figure 2 , enters the Try phase, the transaction coordinator sends a try operation request (i.e., the first preprocessing request) to each first service, the first service calls the Try interface, tries to process the business operation, performs necessary business checks, and reserves various resources required for transaction execution. It should be noted that the resources reserved by the first service in this phase (i.e., the preprocessing phase is also called the Try phase) are in a reserved state and have not been actually submitted.

[0043] Take the first service as inventory service, order service, and account service as an example: the inventory service and order service call the Try interface, and the order service calls the Try interface of the account service. Each service preprocesses its own business resources. For example, the inventory service does not directly deduct the inventory of the product for preprocessing, but freezes the inventory of the product. Orders and accounts also have similar logical operations. The account service needs to freeze the resources of the product price for preprocessing, and the order service adds a state of creating an order for preprocessing.

[0044] S130: When the first preprocessing results fed back by some of the first services all meet the preset verification condition, determine the service performance parameters corresponding to each first service based on the performance parameters to be selected of at least one service.

[0045] Among them, the performance parameters to be selected may refer to service performance parameters that can be selected. The service performance parameters can be used to characterize the unreliability of the service for transaction processing. For example, the larger the parameter value, the more unreliable the transaction execution process of the service. Conversely, the smaller the parameter value, the more reliable the transaction execution process of the service. The performance parameters to be selected may be dynamically updated based on the historical processing results corresponding to the service and the benchmark service performance parameters. The benchmark service performance parameters may be known performance parameters used to evaluate the reliability of the service. The historical processing results may refer to the results of the service preprocessing and / or actual processing of sub-transactions. As the historical processing results of the service change, the performance parameters to be selected for the service are dynamically updated. The preset verification condition may refer to a condition used to verify whether the first preprocessing result meets the requirements.

[0046] In this embodiment, it is possible to verify whether the first preprocessing result fed back by each first service meets the preset verification condition. For example, if the first preprocessing result is consistent with the preset result, it is determined that the first preprocessing result meets the preset verification condition; if the first preprocessing result is inconsistent with the preset result, it is determined that the first preprocessing result does not meet the preset verification condition; the preset result may be that the preprocessing is successful. When it is determined that the first preprocessing results fed back by all the first services meet the preset verification condition, the service performance parameters corresponding to each first service may be searched from the to-be-selected performance parameters of at least one service according to the service identifier of each first service.

[0047] Exemplarily, if the first preprocessing results fed back by each first service meet the preset verification conditions, it means that each first service can successfully attempt to execute the sub-transaction and reserve relevant resources, and then enter the TryAgain stage (i.e., the re-preprocessing stage). In the TryAgain stage, the transaction coordinator checks the performance parameters to be selected of at least one service in the service information record table, determines the service performance parameters corresponding to each first service, and selects a part of the first services with poor reliability for secondary preprocessing according to the service performance parameters.

[0048] In this embodiment, before determining the service performance parameters corresponding to each first service based on the performance parameters to be selected of at least one service: create a service information record table; for each service, determine the benchmark service performance parameters corresponding to the service and store them in the service information record table; the benchmark service performance parameters can be used as the initial performance parameters to be selected, so as to dynamically update the performance parameters to be selected of the service based on the historical processing results corresponding to the service and the benchmark service performance parameters.

[0049] It should be noted that the method for determining the benchmark service performance parameters of each service is the same, and the method for determining the benchmark service performance parameters of any one of the services may be used as an example for explanation.

[0050] Specifically, based on the performance parameters and actual operation of the service under different performance indicators, the transaction processing performance of the service can be comprehensively evaluated to determine the benchmark service performance parameters corresponding to the service. Optionally, the performance indicators include but are not limited to fault tolerance and fault recovery capabilities, load balancing capabilities, QPS (Queries Per Second, which refers to the number of queries or server accesses per unit time), TPS (Transactions Per Second, which refers to the number of transactions processed per unit time), response time, concurrent processing capabilities, etc. The benchmark service performance parameters of the service can be used as the initial values ​​of the performance parameters to be selected to avoid the inability to initially query the weight of the first service. At the same time, the benchmark service performance parameters also serve as a benchmark for the floating of the performance parameters to be selected, so that the performance parameters to be selected can fluctuate around the benchmark through the historical processing results of the service, so as to achieve dynamic updating of the performance parameters to be selected, which ensures both their correctness and timeliness.

[0051] Based on this, by maintaining a service information record table, after determining that all first services in the Try phase have been preprocessed successfully, the service information record table can be queried to obtain the service performance parameters corresponding to each first service, so as to sort the first services based on the service performance parameters, select unreliable first services, and check the feasibility of the services again in the TryAgain phase.

[0052] Exemplarily, the structural diagram of the service information record table is shown in Table 1 below. Table 1 shows the service record of a certain microservice, which includes but is not limited to the microservice ID, microservice name, benchmark service performance parameters (i.e., initial values ​​of performance parameters to be selected), positioning pointers, microservice processing results in the last n times (i.e., historical processing results), failure rate of microservice processing transactions in the last n times, and performance parameters to be selected.

[0053] Table 1

[0054]

[0055]

[0056] In this embodiment, the processing results of the microservice in the most recent n transactions can be recorded in the service information record table. As the historical processing results corresponding to the service change dynamically, the performance parameters to be selected for the service are dynamically updated based on the benchmark service performance parameters. The advantage of this setting is that, by maintaining a service information record table in the process of processing distributed transactions, the processing results of the microservice are recorded in real time, and the performance parameters to be selected are dynamically updated, providing a basis for selecting the second service for repeated inspection, thereby ensuring the success rate of transaction execution and improving the reliability of distributed transaction processing.

[0057] S140. Determine at least one second service from the first service based on the service performance parameter, and send a second preprocessing request to each second service respectively, so that the second service preprocesses at least one sub-transaction again based on the second preprocessing request, and feeds back a second preprocessing result.

[0058] The first service and the second service are relative. For example, service A can be the first service involved in processing the transaction to be processed, or it can be the second service determined from the first service.

[0059] In this embodiment, the service performance parameters of the first services can be sorted by size, and a preset number of first services in the front can be used as the second services; or, the service performance parameters can be compared with a preset threshold, and the first services whose service performance parameters exceed the preset threshold can be used as the second services. The transaction coordinator can send a second preprocessing request to each second service respectively, and each second service, when receiving the second preprocessing request, can call an interface to preprocess at least one sub-transaction again. At this time, when preprocessing again, the previously reserved resources can be retained, and only the business check is performed, and the preprocessing result is fed back, which is the second preprocessing result.

[0060] Exemplarily, when entering the TryAgain phase, a portion of the first services with the highest service performance parameters can be selected as the second services, and retry requests (i.e., second preprocessing requests) can be sent to these second services respectively. After the second service receives the retry request from the transaction coordinator, the second service reserves the previously reserved resources, and then calls the Try interface again to re-operate the previously performed business check. In other words, in the TryAgain phase, the resources reserved in the previous Try phase are reserved, and the operations in the Try phase are repeated and re-checked, thereby ensuring that the system environment at this time can guarantee the smooth progress of business operations, so that after there are no problems in the TryAgain phase, the actual processing phase is entered to formally execute the transaction operation.

[0061] In order to ensure successful transaction processing, a second preprocessing request is sent to each second service respectively so that the second service preprocesses at least one sub-transaction again based on the second preprocessing request. The method can be: a second preprocessing request is sent to each second service respectively so that the second service releases the reserved resources when preprocessing at least one sub-transaction for the first time based on the second preprocessing request, and preprocesses at least one sub-transaction again.

[0062] Specifically, when receiving the second preprocessing request, each second service may release the previously reserved resources (ie, the resources reserved in the Try phase), preprocess at least one sub-transaction again, perform service checks, and reserve resources. Figure 2After the Try stage attempts to process successfully, enter the TryAgain stage, query the service information record table and sort it, select a part of the first service with the highest parameter value, release the resources reserved in the Try stage, and check and reserve resources again. The technical solution provided by this embodiment adds a TryAgain stage after all attempts are successfully executed in the Try stage, and performs another business check and resource reservation operation for the second service with a high execution failure rate in the transaction, ensuring the reliability of the transaction participants when entering the Confirm stage, thereby better guaranteeing the success rate during formal execution and effectively guaranteeing data consistency.

[0063] S150: When the second preprocessing results fed back by some of the second services meet the preset verification conditions, send actual processing requests to each first service respectively, so that the first service actually processes at least one sub-transaction based on the actual processing request.

[0064] The preset verification condition may also be used to verify whether the second preprocessing result meets the requirement. The actual processing request may be a program or code for requesting to execute a business operation and submit a resource.

[0065] In this embodiment, the method of verifying whether the second preprocessing result meets the preset verification condition is similar to the method of verifying whether the first preprocessing result meets the preset verification condition, which will not be described in detail here. When all the second preprocessing results fed back by the second services meet the preset verification condition, an actual processing request can be sent to each first service respectively, so that the first service actually processes at least one sub-transaction based on the actual processing request. For example, the actual processing can be: executing business operations and submitting resources, etc., and the result of the actual processing is fed back, which is the actual processing result. For example, if no exception occurs during the execution process, the actual processing result is successful processing.

[0066] For example, see Figure 2 If the second preprocessing results fed back by each second service meet the preset verification conditions, it means that the second services can successfully attempt to execute business operations, and then the Confirm phase (i.e., the actual processing phase) can be entered. In the Confirm phase, the transaction coordinator sends a transaction execution request (i.e., the actual processing request). After receiving the transaction execution request, the first service formally executes the transaction operation, executes the actual business logic, commits the previously reserved resources, and persists the execution results. It should be noted that the resources processed by the first service in the Confirm phase will be actually committed, that is, the previously reserved resources will be formally allocated to the transaction. If the submission is successful, it is considered a successful processing, and if the submission fails, it is considered a processing failure.

[0067] In the actual transaction processing process, each service can feedback the processing result of this transaction to the system, so as to update the performance parameters to be selected of the service in real time according to the feedback processing result. It should be noted that the processing result fed back by the service can be stored in the service information record table as the historical processing result.

[0068] In this embodiment, when at least one feedback result among the first preprocessing result, the second preprocessing result, and the actual processing result is received, the historical processing result corresponding to the feedback service is updated based on the received feedback result and the message temporary storage queue of the corresponding feedback service.

[0069] The feedback service includes a first service and a second service. The actual processing result is the result of actually processing at least one sub-transaction. The message temporary storage queue is used to store the results to be stored, and the results to be stored refer to the feedback results that need to be stored in a specified location. In other words, the message temporary storage queue can be used to store the change request for the historical processing result corresponding to the service.

[0070] In this embodiment, a message temporary storage queue can be created in advance for each service in the service information record table, and the storage information in the newly created message temporary storage queue is empty. When any of the first preprocessing result, the second preprocessing result and the actual processing result of the feedback is received, the received result can be used as the feedback result; or, in the process of processing the pending event, if the same service feedbacks multiple results, then one or part of the results can also be selected from the multiple results as the feedback result, for example, at the end of the transaction, the last feedback processing result is used as the feedback result. Further, it can be determined whether the feedback result can be written into the service information record table according to the message temporary storage queue of the feedback service corresponding to the feedback result to update the historical processing result of the feedback service. For example, if the message temporary storage queue is not empty, it is necessary to wait for the result in the message temporary storage queue to be written into the service information record table, and then write the feedback result into the service information record table. The advantage of this setting is that the feedback result of the service can be recorded in the table in time sequence to ensure that the processing result of the service's most recent feedback is retained, thereby ensuring the accuracy of the service performance parameters.

[0071] On the basis of the above technical solution, when it is determined that the first preprocessing result or the second preprocessing result does not meet the preset verification conditions, a rollback processing request can be sent to each first service respectively, so that the first service can roll back to the state when at least one sub-transaction has not been preprocessed based on the rollback processing request.

[0072] Specifically, when it is detected that the first preprocessing result or the second preprocessing result does not meet the preset verification condition, a rollback processing request can be sent to each first service respectively. After the first service receives the rollback processing request, it can release the previously reserved resources, so that the first service rolls back to the state when at least one sub-transaction has not been preprocessed.

[0073] For example, see Figure 2 , after the processing fails in the Try phase, the check fails in the TryAgain phase, and the execution fails in the Confirm phase, the transaction enters the Cancel phase, releases the previously reserved resources, runs the corresponding compensation mechanism, and records the error information of the transaction execution to the log. In other words, if the business operation of a transaction participant (including the first service and the second service) cannot be executed normally, or the remaining resources of a system cannot meet the current business needs, a failure signal can be sent to the transaction coordinator (indicating that the feedback result is a processing failure), and the transaction enters the Cancel phase (i.e., the rollback phase); or, if an error or timeout occurs in the execution operation of a transaction participant, resulting in the inability to meet the business needs of the transaction, after the transaction participant finds this situation, it sends a failure signal to the transaction coordinator, and the transaction enters the Cancel phase. In the Cancel phase, the transaction coordinator sends a Cancel signal (i.e., a rollback processing request) to all first services. After receiving the Cancel signal, the first service enables the Cancel interface, releases the resources that have been reserved in the Try phase or the TryAgain phase or used in the Confirm phase, rolls back the operations that have been executed, and restores the state to the state before the transaction starts, and the transaction ends.

[0074] The technical solution of this embodiment is to verify the first preprocessing result fed back by at least one first service involved in processing the pending transaction before formally executing the pending transaction. If the first verification is passed, a second service with lower transaction processing reliability is selected according to the service performance parameters corresponding to each first service, and the second preprocessing result fed back by each second service is verified again. If the second verification is passed, the pending transaction is formally executed, thereby ensuring the success rate during formal execution and avoiding performance waste. At the same time, the performance and reliability of distributed transactions are improved and data consistency is guaranteed.

[0075] Embodiment 2

[0076] Figure 3It is a flowchart of a distributed transaction processing method provided according to the second embodiment of the present invention. On the basis of the above embodiment, based on the received feedback result and the message temporary storage queue of the corresponding feedback service, the historical processing result corresponding to the feedback service is updated, including: "If the message temporary storage queue corresponding to the feedback service is not empty, the feedback result is temporarily stored in the message temporary storage queue as a result to be stored; each result to be stored in the message temporary storage queue is updated in turn to the result record area corresponding to the feedback service, so as to update the historical processing result corresponding to the feedback service". The specific implementation method can be referred to the technical solution of this embodiment. Among them, the technical terms that are the same as or corresponding to the above embodiment are not repeated here.

[0077] like Figure 3 As shown, the method specifically comprises the following steps:

[0078] S210, determining whether the message temporary storage queue corresponding to the feedback service is empty, if so, executing step S220, if not, executing step S230.

[0079] In the process of maintaining the service information record table, in order to improve the data processing efficiency during busy periods and enable quick query of service performance parameters with strong timeliness, the message temporary storage queue can be used to process the feedback results sent during the transaction execution process.

[0080] Specifically, after creating a message temporary storage queue for each service in the service information record table, when an update request for the historical processing results of the feedback service in the service information record table is received, it is first determined whether the message temporary storage queue corresponding to the feedback service is empty. If it is empty, it means that there are no results to be written into the result recording area of ​​the feedback service in the message temporary storage queue at this time, and step S220 can be executed to immediately execute the corresponding result writing operation; if it is not empty, it means that there are results to be written into the result recording area of ​​the feedback service in the message temporary storage queue at this time, and the writing operation cannot be performed immediately. At this time, step S230 can be executed to wait for the results in the message temporary storage queue to be stored before executing this update request.

[0081] S220: Update the feedback result to the result recording area corresponding to the feedback service to update the historical processing result corresponding to the feedback service, and update the performance parameters to be selected of the feedback service based on the updated historical processing result and the baseline service performance parameters of the feedback service.

[0082] The result recording area is located in the service information recording table, and the result recording area includes a preset number of write locations, which are used to store historical processing results. For example, referring to Table 1 above, each IsSuccessful field corresponds to a write location, which records a historical processing result of the microservice.

[0083] In this embodiment, if the historical processing results in the result recording area corresponding to the feedback service reach a preset threshold, the historical processing results with the latest feedback time in the result recording area can be updated based on the feedback results as the new historical processing results to update the historical processing results corresponding to the feedback service. If the historical processing results in the result recording area corresponding to the feedback service do not reach the preset threshold, the feedback results can be updated to a write position in the result recording area where the historical processing results are not stored, and after writing, the historical processing results change. The performance parameters to be selected for the feedback service can be updated based on the updated historical processing results and the baseline service performance parameters of the feedback service each time there is an update of the historical processing results, or periodically, to ensure the correctness and timeliness of the service performance parameters.

[0084] In this embodiment, in order to improve data writing efficiency while ensuring the accuracy and timeliness of service performance parameters, it is also possible to determine the target to-be-written position currently located by the positioning pointer in the result recording area during the process of updating the feedback result to the result recording area corresponding to the feedback service; update the feedback result to the target to-be-written position, and move the positioning pointer to the next writing position of the target to-be-written position.

[0085] The feedback time of the historical processing result in the previous write position is earlier than the feedback time of the historical processing result in the next write position. The positioning pointer is used to locate the write position to be written.

[0086] In this embodiment, the write position currently located by the positioning pointer in the result recording area can be searched, and the position can be used as the target position to be written, and then the feedback result can be updated to the target position to be written, and the positioning pointer can be moved to the next write position of the target position to be written, so that the next feedback result can be directly written to the write position located by the positioning pointer.

[0087] For example, referring to Table 1 above, the table structure contains n binary variable fields and a positioning pointer Pointer, which is used to record the processing results of the microservice in the latest n transactions. For example, after each transaction is completed, the transaction coordinator uses the positioning pointer to locate the status field of this transaction (i.e., the target position to be written), and then fills it in as the historical processing result according to the feedback results of the transaction participants. After filling, the positioning pointer moves to the status field position of the next transaction (i.e., the next writing position of the target position to be written).

[0088] In this embodiment, determining the next writing position of the target to-be-written position includes: if the target to-be-written position is the last position in the result recording area, taking the first writing position in the result recording area as the next writing position of the target to-be-written position.

[0089] Exemplarily, referring to Table 1, if the target position to be written is the last position IsSuccessful-n in the result recording area, the first write position IsSuccessful-1 can be used as the next write position of the target position to be written, and the positioning pointer is positioned at this position so that the next feedback result is written to IsSuccessful-1, thereby achieving the technical effect of improving data processing efficiency while ensuring that the processing results of the most recent feedback are retained.

[0090] In this embodiment, based on the updated historical processing results and the benchmark service performance parameters of the feedback service, the performance parameters to be selected for the feedback service are updated, including: determining the processing failure rate based on the updated historical processing results; and updating the performance parameters to be selected for the feedback service based on the processing failure rate and the benchmark service performance parameters of the feedback service.

[0091] The processing failure rate can be used to represent the failure probability of the service processing transaction, and can be represented by percentage, decimal, fraction, etc., and the representation form is not limited. The higher the processing failure rate, the less reliable the performance of the service processing transaction.

[0092] In this embodiment, the number of historical processing results that failed in the result recording area can be counted, and the number and the number of all historical processing results in the result recording area are processed as a quotient to obtain the processing failure rate. Further, the benchmark service performance parameter can be floated according to the processing failure rate to obtain the parameter value after floating as a new performance parameter to be selected for the feedback service.

[0093] For example, referring to Table 1 above, a variable FailureRate is used to record the failure rate of the microservice processing transactions in the past n times, and the failure rate is calculated by the data of the n status fields IsSuccessful. A variable Weight is used to record the performance parameter to be selected, and the performance parameter to be selected is calculated by the benchmark service performance parameter and the failure rate. The calculation method or formula can be determined by the technician according to the system business requirements.

[0094] The technical solution provided in this embodiment records the processing status of microservices by adding fields in the service information record table, uses the failure rate of microservices in the recent period of operation as a recording indicator, and records an initial value of a performance parameter to be selected in the service information record table when registering the microservice. During the operation of the system, the result of each transaction is recorded in the table after the transaction is processed, and the performance parameter to be selected for each microservice is updated at regular intervals based on the processing result and initial value in the table, thereby ensuring the timeliness and correctness of the service performance parameters.

[0095] S230, temporarily storing the feedback result as a result to be stored in the message temporary storage queue; updating each result to be stored in the message temporary storage queue in turn to the result recording area corresponding to the feedback service, so as to update the historical processing result corresponding to the feedback service.

[0096] In this embodiment, the feedback result can be temporarily stored in the message temporary storage queue of the feedback service, and then each result to be stored in the message temporary storage queue is updated in sequence to the result recording area corresponding to the feedback service according to the storage sequence, so as to update the historical processing result corresponding to the feedback service, and update the performance parameters to be selected of the feedback service based on the updated historical processing result and the benchmark service performance parameters of the feedback service. It should be noted that the method of updating the result to be stored to the result recording area corresponding to the feedback service is similar to the implementation method of updating the feedback result to the result recording area corresponding to the feedback service in step S220, and will not be repeated here.

[0097] The technical solution of this embodiment is to determine whether the message temporary storage queue of the feedback service corresponding to the feedback result is empty when receiving the feedback result. If it is not empty, the feedback result is first temporarily stored in the message temporary storage queue as a result to be stored, so that each result to be stored in the message temporary storage queue is updated in sequence to the result recording area corresponding to the feedback service, thereby ensuring the timeliness of the historical processing results and retaining the processing results of the most recent feedback, thereby ensuring the timeliness and correctness of the service performance parameters.

[0098] Embodiment 3

[0099] Figure 4It is a flowchart of a distributed transaction processing method provided according to the third embodiment of the present invention. On the basis of the above-mentioned embodiment, based on the performance parameters to be selected of at least one service, the service performance parameters corresponding to each first service are determined, including: "For each first service, if the message temporary storage queue corresponding to the first service is empty, the service performance parameters corresponding to the first service are queried from the performance parameters to be selected of at least one service; if the message temporary storage queue is not empty, the results to be written in the message temporary storage queue at the current moment are determined, and after the results to be written are updated to the result record area corresponding to the first service, the service performance parameters corresponding to the first service are queried from the performance parameters to be selected of at least one service". The specific implementation method can be referred to the technical solution of this embodiment. Among them, the technical terms that are the same as or corresponding to the above-mentioned embodiments are not repeated here.

[0100] like Figure 4 As shown, the method specifically comprises the following steps:

[0101] S310. For each first service, determine whether the message temporary storage queue corresponding to the first service is empty. If so, execute step S320; if not, execute step S330.

[0102] In this embodiment, the method of querying the service performance parameters corresponding to each first service is the same, and the querying of the service performance parameters corresponding to any of the first services can be used as an example for introduction. Before querying, it can be determined whether the message temporary storage queue corresponding to the first service is empty. If it is empty, it means that there are no results to be written to the result recording area of ​​the first service at this time, and step S320 can be executed to directly query the service performance parameters corresponding to the first service from the table. If it is not empty, it means that there are results to be written to the result recording area of ​​the first service at this time. In order to ensure correctness, step S330 can be executed, and after waiting for the results to be stored, the service performance parameters corresponding to the first service can be queried from the table.

[0103] S320: Query the service performance parameter corresponding to the first service from the performance parameters to be selected of at least one service.

[0104] In this embodiment, the service identifier of the first service can be used to query the to-be-selected performance parameter corresponding to the service identifier from the service information record table as the service performance parameter of the first service.

[0105] S330: Determine the results to be written in the message temporary storage queue at the current moment, and after updating the results to be written to the result recording area corresponding to the first service, query the service performance parameters corresponding to the first service from the performance parameters to be selected of at least one service.

[0106] In this embodiment, the current moment may refer to the moment corresponding to querying the service performance parameters of the first service, and the results to be written in the message temporary storage queue of the first service at this moment may be determined. After all these results to be written are updated to the result recording area corresponding to the first service, the service performance parameters corresponding to the first service may be queried from the table.

[0107] For example, when the system receives a performance parameter query request for a service, it first checks whether the message temporary storage queue of the service is empty. If it is empty, it directly reads the service performance parameters of the service in the service information record table. If it is not empty, it needs to process all write requests (i.e., waiting to be written results) in the message temporary storage queue at one time, and then execute the performance parameter query request.

[0108] The technical solution of this embodiment first determines whether the message temporary storage queue of the first service is empty, and if it is empty, directly queries the service performance parameters corresponding to the first service from the table; if it is not empty, waits until all the results to be written in the message temporary storage queue at the current moment are updated to the result recording area corresponding to the first service, and then queries the service performance parameters corresponding to the first service from the table, thereby improving the accuracy of determining the service performance parameters at this time, thereby improving the reliability of distributed transaction processing.

[0109] Embodiment 4

[0110] As an optional embodiment of the above embodiment, in order to make those skilled in the art further understand the technical solution of the embodiment of the present invention, a specific application scenario example is given. For details, please refer to the following specific content.

[0111] The technical solution of the embodiment of the present invention can be implemented based on a microservice distributed transaction system, and its implementation method can be: during the operation of the microservice distributed transaction system, a service information record table is maintained. The service information record table includes information such as the transaction processing status of the microservice and the failure rate of recent processing. At the same time, n status fields and a pointer field are added to the service information record table. When the feedback result of a service transaction is to be written, the feedback result is written to the location pointed to by the pointer, and then the pointer is changed to move to the write location of the next transaction.

[0112] Furthermore, before the Confirm phase, the transaction coordinator repeats the check on the transaction participants (i.e., the second service) with a high failure rate in the service information record table. If there is no error, the formal execution is carried out; if an error occurs, the execution is cancelled. The method of repeating the check before formal execution includes: after the transaction is initiated, the transaction participants (i.e., the first service) are subjected to the first business check, and the resources required for the business are reserved; after the transaction coordinator finds no problem in the first check, the service information record table is queried to obtain the service performance parameters of each first service involved in the transaction; the first services are sorted according to the service performance parameters, and a part of the first services with the highest service performance parameters are selected as the second service, and the business check is re-performed. When repeating the check, the previously reserved resources are retained, the interface of the first check is called again to perform the business check, and the check result (i.e., the second preprocessing result) is reported to the transaction coordinator.

[0113] After the transaction ends, the transaction coordinator writes the feedback results of the microservices involved in this transaction into the service information record table, and the system processes the write request from the transaction coordinator based on the message temporary queue.

[0114] On the basis of the above technical solution, the method for maintaining the service information record table includes: when each distributed transaction ends, the transaction coordinator sends the feedback results of the microservices participating in this transaction to the system; after the system receives the feedback results of the microservices, if the message temporary storage queue of the microservice is empty, the feedback results can be written immediately; if the message temporary storage queue of the microservice is not empty, these feedback results are temporarily stored in the message temporary storage queue and queued to be written into the service information record table. If a query request for the performance parameters of a microservice is received from the transaction coordinator, the write request of the message temporary storage queue corresponding to the microservice is processed in priority according to the order of receipt, and then the service performance parameters of the microservice are returned to the transaction coordinator.

[0115] The technical solution of this embodiment is to verify the first preprocessing result fed back by at least one first service involved in processing the pending transaction before formally executing the pending transaction. If the first verification is passed, a second service with lower transaction processing reliability is selected according to the service performance parameters corresponding to each first service, and the second preprocessing result fed back by each second service is verified again. If the second verification is passed, the pending transaction is formally executed, thereby ensuring the success rate during formal execution and avoiding performance waste. At the same time, the performance and reliability of distributed transactions are improved and data consistency is guaranteed.

[0116] Embodiment 5

[0117] Figure 5 Schematic diagram of the structure of a distributed transaction processing device provided according to Embodiment 5 of the present invention. Figure 5As shown, the device includes: a first service determination module 410, a first pre-processing module 420, a service performance parameter determination module 430, a second pre-processing module 440 and an actual processing module 450.

[0118] The first service determination module 410 is used to determine at least one first service that participates in processing the pending transaction when receiving the pending transaction; wherein the pending transaction includes at least one sub-transaction; the first pre-processing module 420 is used to send a first pre-processing request to each of the first services respectively, so that the first service pre-processes the at least one sub-transaction based on the first pre-processing request and feeds back a first pre-processing result; the service performance parameter determination module 430 is used to determine the service performance parameter corresponding to each of the first services based on the to-be-selected performance parameter of at least one service when the first pre-processing results fed back by some of the first services meet the preset verification condition; the second pre-processing module 440 is used to determine at least one second service from the first service based on the service performance parameter, and send a second pre-processing request to each of the second services respectively, so that the second service pre-processes the at least one sub-transaction again based on the second pre-processing request and feeds back a second pre-processing result; the actual processing module 450 is used to send an actual processing request to each of the first services respectively, so that the first service actually processes the at least one sub-transaction based on the actual processing request when the second pre-processing results fed back by some of the second services meet the preset verification condition.

[0119] The technical solution of this embodiment is to verify the first preprocessing result fed back by at least one first service involved in processing the pending transaction before formally executing the pending transaction. If the first verification is passed, a second service with lower transaction processing reliability is selected according to the service performance parameters corresponding to each first service, and the second preprocessing result fed back by each second service is verified again. If the second verification is passed, the pending transaction is formally executed, thereby ensuring the success rate during formal execution and avoiding performance waste. At the same time, the performance and reliability of distributed transactions are improved and data consistency is guaranteed.

[0120] Based on the above-mentioned device, optionally, the device also includes: a rollback module, which is used to send a rollback processing request to each of the first services respectively when it is determined that the first preprocessing result or the second preprocessing result does not meet the preset verification condition, so that the first service rolls back to the state when the at least one sub-transaction is not preprocessed based on the rollback processing request.

[0121] Based on the above-mentioned device, optionally, the device also includes: a historical processing result updating module, which is used to update the historical processing result corresponding to the feedback service based on the received feedback result and the message temporary storage queue of the feedback service corresponding to the feedback result when receiving at least one feedback result among the first preprocessing result, the second preprocessing result and the actual processing result; wherein the feedback service includes a first service and a second service; the actual processing result is the result of actually processing the at least one sub-transaction; and the message temporary storage queue is used to store the results to be stored.

[0122] Based on the above-mentioned device, optionally, the historical processing result updating module includes: a first updating unit, which is used to update the feedback result to the result recording area corresponding to the feedback service if the message temporary storage queue corresponding to the feedback service is empty, so as to update the historical processing result corresponding to the feedback service, and update the performance parameters to be selected of the feedback service based on the updated historical processing results and the baseline service performance parameters of the feedback service; wherein the result recording area includes a preset number of write locations, and the write locations are used to store the historical processing results.

[0123] Based on the above device, optionally, the historical processing result updating module also includes: a temporary storage unit, which is used to temporarily store the feedback result as a result to be stored in the message temporary storage queue if the message temporary storage queue corresponding to the feedback service is not empty; and a second updating unit, which is used to update each result to be stored in the message temporary storage queue in turn to the result recording area corresponding to the feedback service, so as to update the historical processing result corresponding to the feedback service.

[0124] Based on the above device, optionally, the first update unit includes: a target to-be-written position determination unit, used to determine the target to-be-written position where the positioning pointer in the result recording area is currently located; a next write position determination unit, used to update the feedback result to the target to-be-written position, and move the positioning pointer to the next write position of the target to-be-written position.

[0125] Based on the above device, optionally, a next write position determination unit is specifically used to use the first write position in the result recording area as the next write position of the target to-be-written position if the target to-be-written position is the last position in the result recording area; wherein the feedback time of the historical processing result in the previous write position is earlier than the feedback time of the historical processing result in the next write position.

[0126] Based on the above-mentioned device, optionally, the service performance parameter determination module 430 includes: a first query unit, which is used to query the service performance parameters corresponding to the first service from the performance parameters to be selected of the at least one service for each of the first services if the message temporary storage queue corresponding to the first service is empty; a second query unit, which is used to determine the results to be written in the message temporary storage queue at the current moment if the message temporary storage queue is not empty, and after updating the results to be written to the result recording area corresponding to the first service, query the service performance parameters corresponding to the first service from the performance parameters to be selected of the at least one service.

[0127] Based on the above-mentioned device, optionally, the first update unit includes: a processing failure rate determination unit, used to determine the processing failure rate based on the updated historical processing results; a performance parameter updating unit, used to update the performance parameters to be selected of the feedback service based on the processing failure rate and the benchmark service performance parameters of the feedback service.

[0128] Based on the above-mentioned device, optionally, a second preprocessing module 440 is specifically used to send a second preprocessing request to each of the second services respectively, so that the second service releases the reserved resources when preprocessing the at least one sub-transaction for the first time based on the second preprocessing request, and preprocesses the at least one sub-transaction again.

[0129] The distributed transaction processing device provided in the embodiment of the present invention can execute the distributed transaction processing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0130] Embodiment 6

[0131] Figure 6 1 is a schematic diagram of the structure of an electronic device that implements the distributed transaction processing method of an embodiment of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0132] like Figure 6As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0133] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0134] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as a distributed transaction processing method.

[0135] In some embodiments, the distributed transaction processing method may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the distributed transaction processing method described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to execute the distributed transaction processing method in any other appropriate manner (e.g., by means of firmware).

[0136] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0137] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0138] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, device, or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), 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 foregoing.

[0139] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0140] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0141] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0142] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

[0143] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A distributed transaction processing method, characterized in that: include: When receiving a pending transaction, determining at least one first service that participates in processing the pending transaction; wherein the pending transaction includes at least one sub-transaction; Sending a first preprocessing request to each of the first services respectively, so that the first service preprocesses the at least one sub-transaction based on the first preprocessing request, and feeds back a first preprocessing result; In a case where the first preprocessing results fed back by some of the first services all meet a preset verification condition, determining a service performance parameter corresponding to each of the first services based on the to-be-selected performance parameter of at least one service; Determine at least one second service from the first service based on the service performance parameter, and send a second preprocessing request to each of the second services respectively, so that the second service preprocesses the at least one sub-transaction again based on the second preprocessing request, and feeds back a second preprocessing result; When the second pre-processing results fed back by some of the second services all meet the preset verification condition, respectively sending an actual processing request to each of the first services, so that the first service actually processes the at least one sub-transaction based on the actual processing request; Wherein, the performance parameter to be selected is dynamically updated based on the historical processing results corresponding to the service and the benchmark service performance parameters; The method further includes: updating the performance parameter to be selected of the feedback service based on the updated historical processing result and the benchmark service performance parameter of the feedback service, including: Determine the processing failure rate based on the updated historical processing results; Based on the processing failure rate and the benchmark service performance parameter of the feedback service, the performance parameter to be selected of the feedback service is updated; wherein the feedback service includes a first service and a second service.

2. The method according to claim 1, characterized in that The method further comprises: When it is determined that the first preprocessing result or the second preprocessing result does not meet the preset verification condition, a rollback processing request is sent to each of the first services respectively, so that the first service rolls back to the state when the at least one sub-transaction is not preprocessed based on the rollback processing request.

3. The method according to claim 1, characterized in that The method further comprises: When receiving at least one feedback result among the first preprocessing result, the second preprocessing result and the actual processing result, based on the received feedback result and the message temporary storage queue of the corresponding feedback service, updating the historical processing result corresponding to the feedback service; The actual processing result is the result of actually processing the at least one sub-transaction; and the message temporary storage queue is used to store the results to be stored.

4. The method according to claim 3, characterized in that The updating of the historical processing result corresponding to the feedback service based on the received feedback result and the message temporary storage queue of the feedback service corresponding to the feedback result includes: If the message temporary storage queue corresponding to the feedback service is empty, updating the feedback result to the result recording area corresponding to the feedback service to update the historical processing result corresponding to the feedback service; The result recording area includes a preset number of writing locations, and the writing locations are used to store the historical processing results.

5. The method according to claim 3, characterized in that: The updating of the historical processing result corresponding to the feedback service based on the received feedback result and the message temporary storage queue of the feedback service corresponding to the feedback result includes: If the message temporary storage queue corresponding to the feedback service is not empty, temporarily storing the feedback result in the message temporary storage queue as a result to be stored; Each to-be-stored result in the message temporary storage queue is sequentially updated to the result recording area corresponding to the feedback service, so as to update the historical processing result corresponding to the feedback service.

6. The method according to claim 4, characterized in that The updating of the feedback result to the result recording area corresponding to the feedback service includes: Determine the target to-be-written position currently located by the positioning pointer in the result recording area; Updating the feedback result to the target position to be written, and moving the positioning pointer to the next writing position of the target position to be written, comprises: If the target position to be written is the last position in the result recording area, the first writing position in the result recording area is used as the next writing position of the target position to be written; The feedback time of the historical processing result in the previous write position is earlier than the feedback time of the historical processing result in the next write position.

7. The method according to claim 1, characterized in that The determining, based on the to-be-selected performance parameter of at least one service, a service performance parameter corresponding to each of the first services comprises: For each of the first services, if the message temporary storage queue corresponding to the first service is empty, querying the service performance parameter corresponding to the first service from the performance parameters to be selected of the at least one service; If the message temporary storage queue is not empty, determine the results to be written in the message temporary storage queue at the current moment, and after updating the results to be written to the result recording area corresponding to the first service, query the service performance parameters corresponding to the first service from the performance parameters to be selected of the at least one service.

8. The method according to claim 1, characterized in that The sending a second preprocessing request to each of the second services respectively, so that the second service preprocesses the at least one sub-transaction again based on the second preprocessing request, comprises: A second preprocessing request is sent to each of the second services respectively, so that the second service releases the reserved resources used for the first preprocessing of the at least one sub-transaction based on the second preprocessing request, and preprocesses the at least one sub-transaction again.

9. A distributed transaction processing device, characterized in that: include: A first service determination module, configured to determine, upon receiving a transaction to be processed, at least one first service that participates in processing the transaction to be processed; wherein the transaction to be processed includes at least one sub-transaction; a first preprocessing module, configured to send a first preprocessing request to each of the first services respectively, so that the first service preprocesses the at least one sub-transaction based on the first preprocessing request, and feeds back a first preprocessing result; a service performance parameter determination module, configured to determine, when the first preprocessing results fed back by some of the first services all meet a preset verification condition, a service performance parameter corresponding to each of the first services based on a to-be-selected performance parameter of at least one service; wherein the to-be-selected performance parameter is dynamically updated based on a historical processing result corresponding to the service and a benchmark service performance parameter; a second preprocessing module, configured to determine at least one second service from the first service based on the service performance parameter, and send a second preprocessing request to each of the second services respectively, so that the second service preprocesses the at least one sub-transaction again based on the second preprocessing request, and feeds back a second preprocessing result; an actual processing module, configured to send an actual processing request to each of the first services respectively, if the second preprocessing results fed back by some of the second services all meet the preset verification condition, so that the first service actually processes the at least one sub-transaction based on the actual processing request; The device further includes a historical processing result updating module; the historical processing result updating module includes a first updating unit; the first updating unit is used to update the performance parameter to be selected of the feedback service based on the updated historical processing result and the benchmark service performance parameter of the feedback service; The first updating unit includes: a processing failure rate determining unit, used to determine the processing failure rate based on the updated historical processing results; a performance parameter updating unit, used to update the performance parameters to be selected of the feedback service based on the processing failure rate and the benchmark service performance parameters of the feedback service; wherein the feedback service includes a first service and a second service.

Images