Distributed transaction processing method and device, electronic equipment and medium

Abstract

The embodiment of the invention provides a distributed transaction processing method and device, electronic equipment and a medium. The method specifically comprises the steps that first calling results returned by multiple participants based on a first calling request are received; when a first calling result returned by any participant of the target transaction identifier is calling failure, generating an abnormal message; under the condition that a first calling result returned by any participant of the target transaction identifier is calling failure, sending a second calling request to a rollback interface provided by the target participant by adopting an asynchronous mode for the target transaction identifier; according to a second calling result returned by the target participant based on the second calling request, generating a corresponding database record; fields recorded in the database comprise a calling result field; and performing data consistency verification according to the field content of the calling result field. According to the embodiment of the invention, the processing duration of the distributed transaction can be reduced.

Description

Technical Field

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

[0002] Distributed transactions refer to transactions in which the participants, servers supporting transactions, resource servers, and transaction managers are located on different nodes of different distributed systems. The TCC (Try-Confirm-Cancel) solution is a common distributed transaction solution, and its core idea is to split transactions into two phases. The first phase is the Try phase, in which all participants in the transaction complete business checks, reserve and lock resources; the second phase is determined by the results of the first phase. If all participants succeed in the Try phase, the Confirm phase is initiated to use the resources reserved in the first phase. Otherwise, the Cancel phase is initiated to cancel the reserved resources in the first phase.

[0003] Distributed transactions can be applied to a variety of application scenarios. For example, the user registration process of a video platform involves distributed transactions. Specifically, after receiving the user information submitted by the user, the user registration subsystem will synchronize the user information with multiple preset subsystems, and provide the user with the response result of the user registration process based on the synchronization result.

[0004] The processing method of distributed transactions in the related technology specifically includes: first receiving user information; then, performing resource reservation processing based on the synchronous call of multiple preset subsystems; then, in the event that the resource reservation processing of any preset subsystem fails, performing resource rollback processing based on the synchronous call of the corresponding preset subsystem; after completing the resource rollback processing, providing the user with a response result of the user registration process.

[0005] In actual applications, resource rollback processing is performed based on synchronous calls of corresponding preset subsystems, which means that before the resource rollback processing of one preset subsystem is completed, the resource rollback processing of another preset subsystem will be blocked and waited, which increases the processing time of distributed transactions. Summary of the invention

[0006] The purpose of the embodiments of the present invention is to provide a method, device, electronic device, and medium for processing distributed transactions, which can reduce the processing time of distributed transactions and improve the processing efficiency of distributed transactions.

[0007] The specific technical solutions are as follows:

[0008] In a first aspect of the present invention, a method for processing a distributed transaction is provided, the method comprising:

[0009] Send a first call request to the attempt interfaces provided to multiple participants for a transaction identifier.

[0010] Receive first call results respectively returned by multiple participants based on the first call request.

[0011] Generate an exception message when the first call result returned by any one of the participants for the target transaction identifier is a call failure.

[0012] When the first call result returned by any one of the participants for the target transaction identifier is a call failure, asynchronously send a second call request to the rollback interface provided to the target participant for the target transaction identifier; the target participant is used to represent the participant that needs to perform rollback processing.

[0013] Generate a corresponding database record according to the second call result returned by the target participant based on the second call request; the fields of the database record include: a call result field.

[0014] Perform data consistency verification according to the field content of the call result field.

[0015] In the second aspect of the implementation of the present invention, a method for processing a distributed transaction is provided. The method is applied to a user registration scenario and includes:

[0016] Receive a user registration request.

[0017] Determine the transaction identifier corresponding to the user registration request and multiple preset subsystems corresponding to the user registration request; the transaction identifier is used to synchronize the user information to multiple preset subsystems.

[0018] Send a first call request to the attempt interfaces provided to multiple preset subsystems for the transaction identifier.

[0019] Receive first call results respectively returned by the multiple preset subsystems based on the first call request.

[0020] Generate an exception message when the first call result returned by any one of the preset subsystems for the target transaction identifier is a call failure.

[0021] When the first call result returned by any one of the participants for the target transaction identifier is a call failure, asynchronously send a second call request to the rollback interface provided to the target preset subsystem for the target transaction identifier; the target preset subsystem is used to represent the preset subsystem that needs to perform rollback processing.

[0022] After sending the second call request, return the user registration result.

[0023] Generate a corresponding database record according to the second call result returned by the target preset subsystem based on the second call request; the fields of the database record include: a call result field;

[0024] Perform data consistency verification according to the field content of the call result field.

[0025] In a third aspect of the implementation of the present invention, a distributed transaction processing device is provided, and the device includes:

[0026] A first call sending module, configured to send a first call request to a try interface provided by multiple participants for a transaction identifier;

[0027] A first call result receiving module, configured to receive first call results respectively returned by multiple participants based on the first call request;

[0028] An exception message generating module, configured to generate an exception message when the first call result returned by any one of the participants of the target transaction identifier is a call failure;

[0029] A second call sending module, configured to, when the first call result returned by any one of the participants of the target transaction identifier is a call failure, send a second call request to a rollback interface provided by the target participant in an asynchronous manner for the target transaction identifier; the target participant is used to represent the participant that needs to perform rollback processing;

[0030] A database record generating module, configured to generate a corresponding database record according to the second call result returned by the target participant based on the second call request; the fields of the database record include: a call result field;

[0031] A data consistency verification module, configured to perform data consistency verification according to the field content of the call result field.

[0032] Optionally, the fields of the database record include: a transaction identifier field, a participant identifier field, and a call result field; the second call result includes: rollback success or rollback failure; the data consistency verification module includes:

[0033] A first verification module, configured to, if the field content of the call result field is rollback success, the verification result is data consistent; or

[0034] A second verification module, configured to, if the field content of the call result field is rollback failure, the verification result is data inconsistent.

[0035] Optionally, when the field content of the call result field is rollback failure, or the verification result is data inconsistent, the device further includes:

[0036] The first preset processing module is configured to send a second call request to the rollback interface where the rollback fails again in an asynchronous manner for the target transaction identifier; and / or

[0037] The second preset processing module is configured to send the relevant transaction information of the failed rollback to a preset user by using a preset medium; the relevant transaction information is used to represent the relevant information of the transaction where the rollback fails.

[0038] Optionally, the apparatus further includes:

[0039] A generation module is configured to generate corresponding database records according to the first call results respectively returned by multiple parties based on the first call request;

[0040] The fields of the database record further include: a call type field; the field content of the call type field includes: an attempt type or a rollback type;

[0041] The field content of the call type field corresponding to the first call request is the attempt type. When the field content of the call type field is the attempt type, the field content of the call result field is determined according to the first call result;

[0042] The field content of the call type field corresponding to the second call request is the rollback type. When the field content of the call type field is the rollback type, the field content of the call result field is determined according to the second call result.

[0043] Optionally, the data consistency verification module includes:

[0044] A record acquisition module is configured to acquire a target database record whose field content of the call type field is the rollback type from the database record corresponding to the target transaction identifier;

[0045] A third verification module is configured to, if the field content of the call result field in the target database record is rollback success, the verification result is that the data is consistent; or

[0046] A fourth verification module is configured to, if the field content of the call result field in the target database record is rollback failure, the verification result is that the data is inconsistent.

[0047] In a fourth aspect of the implementation of the present invention, a processing apparatus for distributed transactions is provided. The apparatus is applied to a user registration scenario and includes:

[0048] A request receiving module is configured to receive a user registration request;

[0049] A determination module, configured to determine a transaction identifier corresponding to the user registration request and multiple preset subsystems corresponding to the user registration request; the transaction identifier is used to synchronize the user information to the multiple preset subsystems;

[0050] A first call module, configured to send a first call request to a try interface provided by multiple preset subsystems for a transaction identifier;

[0051] A first call result receiving module, configured to receive first call results respectively returned by the multiple preset subsystems based on the first call request;

[0052] An exception message generation module, configured to generate an exception message when the first call result returned by any one of the preset subsystems for a target transaction identifier is a call failure;

[0053] A second call module, configured to, when the first call result returned by any one of the participants for a target transaction identifier is a call failure, send a second call request to a rollback interface provided by a target preset subsystem in an asynchronous manner for the target transaction identifier; the target preset subsystem is used to represent a preset subsystem that needs to perform a rollback process;

[0054] A registration result return module, configured to return a user registration result after sending the second call request;

[0055] A database record generation module, configured to generate a corresponding database record according to a second call result returned by the target preset subsystem based on the second call request; fields of the database record include: a call result field;

[0056] A data consistency verification module, configured to perform data consistency verification according to the field content of the call result field.

[0057] In a fifth aspect of the implementation of the present invention, there is also provided an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory complete communication with each other through the communication bus;

[0058] The memory is used to store a computer program;

[0059] The processor is configured to implement the foregoing method steps when executing the program stored on the memory.

[0060] In a sixth aspect of the implementation of the present invention, there is also provided a computer-readable storage medium, in which instructions are stored, and when the instructions run on a computer, the computer is enabled to execute any one of the foregoing methods.

[0061] The method, apparatus, electronic device, and medium for processing distributed transactions provided by the embodiments of the present invention first send a first call request to the attempt interfaces of multiple participants for a transaction identifier; then receive the first call results returned by these participants; next, generate an exception message when the first call result of any participant is a call failure; and, when the first call result returned by any participant of the target transaction identifier is a call failure, send a second call request to the rollback interface of the target participant that needs to be rolled back asynchronously for the target transaction identifier of the target participant; subsequently, generate a corresponding database record according to the second call result returned by the target participant, and the database record includes a call result field; then, perform data consistency verification based on the content of the call result field.

[0062] The embodiments of the present invention send a second call request to the rollback interface of the target participant asynchronously. When the target participant is one, after the embodiments of the present invention send a second call request to the rollback interface of one target participant, they can not wait for the return result of this target participant. Therefore, the processing duration of the distributed transaction can be reduced. When the target participants are multiple, after the embodiments of the present invention send a second call request to the rollback interface of target participant A, they can not wait for the return result of target participant A and directly send a second call request to the rollback interface of target participant B; therefore, the processing duration of the distributed transaction can be reduced. In summary, whether the target participant is one or multiple, the embodiments of the present invention can reduce the processing duration of the distributed transaction and improve the processing efficiency of the distributed transaction.

[0063] Moreover, when the first call result returned by any participant is a call failure, the embodiments of the present invention generate an exception message, and the above exception message can quickly and accurately locate the participant with the call failure and the target participant that has a successful call and needs to be rolled back.

[0064] In addition, the embodiments of the present invention generate a database record according to the second call result returned by the target participant and perform data consistency verification based on the call result field in the database record, and the obtained verification result can reflect whether the data is consistent during the processing of the distributed transaction. In this way, the situation of data inconsistency can be discovered and processed in time. Therefore, the accuracy and reliability of the distributed transaction can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art.

[0066] Figure 1 It is a step flowchart of the method for processing distributed transactions according to an embodiment of the present invention;

[0067] Figure 2 Flowchart of the steps of the method for processing distributed transactions according to an embodiment of the present invention;

[0068] Figure 3 Flowchart of the method for processing distributed transactions according to an embodiment of the present invention;

[0069] Figure 4 Schematic structural diagram of an apparatus for processing distributed transactions according to an embodiment of the present invention;

[0070] Figure 5 Schematic structural diagram of an apparatus for processing distributed transactions according to an embodiment of the present invention;

[0071] Figure 6 Block diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed implementation manners

[0072] Next, the technical solutions in the embodiments of the present invention will be described in conjunction with the accompanying drawings in the embodiments of the present invention.

[0073] The method for processing distributed transactions according to the embodiments of the present invention can be used to process distributed transactions to reduce the processing duration of distributed transactions.

[0074] Distributed transactions can be applied to a variety of application scenarios. For example, the application scenarios of distributed transactions can include: user registration scenarios, e-commerce transaction scenarios, financial transfer scenarios, and so on.

[0075] For example, in the user registration scenario, after the user registration subsystem receives the user information submitted by the user, it will synchronize the user information to multiple preset subsystems and provide the response result of the user registration process to the user according to the synchronization result.

[0076] Another example is that in the e-commerce transaction scenario, when a user places an order to purchase a product, it may involve multiple operations such as inventory deduction, order creation, payment processing, and points increase. These multiple operations may be distributed in different systems or databases. To ensure the consistency of the entire transaction, distributed transactions need to be used to ensure that either all operations are successful or all are rolled back.

[0077] Another example is that in the financial transfer scenario, when performing cross-bank transfers or fund transfers between multiple accounts, it is necessary to ensure the consistency of the fund transfer-out and transfer-in operations. If the transfer-out is successful but the transfer-in fails, it will lead to inconsistent funds and potential risks. For example, when transferring funds from an account in Bank A to an account in Bank B, it is necessary to ensure that Bank A successfully deducts the funds while Bank B can accurately record the incoming funds.

[0078] It can be understood that those skilled in the art can apply the method for processing distributed transactions in the embodiments of the present invention to various application scenarios according to actual application requirements, and the embodiments of the present invention do not limit specific application scenarios.

[0079] The method for processing distributed transactions in the related art specifically includes: first, receiving user information; then, performing resource reservation processing based on synchronous calls of multiple preset subsystems; next, in the case where the resource reservation processing of any one of the preset subsystems fails, performing resource rollback processing based on the synchronous call of the corresponding preset subsystem; after completing the resource rollback processing, providing the response result of the user registration process to the user.

[0080] However, performing resource rollback processing based on the synchronous call of the corresponding preset subsystem means that before the resource rollback processing of one preset subsystem is completed, the resource rollback processing of another preset subsystem will be blocked and waiting, which increases the processing duration of the distributed transaction.

[0081] In view of the technical problem of the processing duration of distributed transactions in the related art, the embodiments of the present invention provide a method for processing distributed transactions, which specifically includes:

[0082] Sending a first call request to the attempt interfaces provided to multiple participants for a transaction identifier;

[0083] Receiving the first call results respectively returned by the multiple participants based on the first call request;

[0084] Generating an exception message in the case where the first call result returned by any one of the participants for the target transaction identifier is a call failure;

[0085] In the case where the first call result returned by any one of the participants for the target transaction identifier is a call failure, sending a second call request to the rollback interface provided to the target participant in an asynchronous manner for the target transaction identifier; the above target participant is used to represent the participant that needs to perform rollback processing;

[0086] Generating a corresponding database record according to the second call result returned by the above target participant based on the second call request; the fields of the above database record include: a call result field;

[0087] Performing data consistency verification according to the field content of the above call result field.

[0088] In an embodiment of the present invention, a first call request is first sent to the attempt interfaces of multiple participants for a transaction identifier; then, the first call results returned by these participants are received; next, in the case where the first call result of any participant is a call failure, an exception message is generated; in the case where the first call result returned by any participant of the target transaction identifier is a call failure, for the target transaction identifier of the target participant that needs to be rolled back, a second call request is sent to its rollback interface asynchronously; subsequently, a corresponding database record is generated according to the second call result returned by the target participant, and the database record includes a call result field; then, data consistency verification is performed based on the content of the call result field.

[0089] In an embodiment of the present invention, a second call request is sent to the rollback interface of the target participant asynchronously. When there is one target participant, after sending the second call request to the rollback interface of one target participant, this embodiment of the present invention may not wait for the return result of this target participant. Therefore, the processing duration of the distributed transaction can be reduced. When there are multiple target participants, after sending the second call request to the rollback interface of target participant A, this embodiment of the present invention may not wait for the return result of target participant A and directly send the second call request to the rollback interface of target participant B; therefore, the processing duration of the distributed transaction can be reduced. In summary, whether there is one or multiple target participants, this embodiment of the present invention can reduce the processing duration of the distributed transaction and improve the processing efficiency of the distributed transaction.

[0090] Moreover, in the case where the first call result returned by any participant is a call failure, an exception message is generated in an embodiment of the present invention, and the above exception message can quickly and accurately locate the participant with the call failure and the target participant that has a successful call and needs to be rolled back.

[0091] In addition, in an embodiment of the present invention, a database record is generated according to the second call result returned by the target participant, and data consistency verification is performed based on the call result field in the database record. The obtained verification result can reflect whether the data is consistent during the processing of the distributed transaction. In this way, the situation of data inconsistency can be discovered and processed in a timely manner. Therefore, the accuracy and reliability of the distributed transaction can be improved.

[0092] Next, the embodiments of the present invention will be described through specific examples.

[0093] Refer to Figure 1 , which shows a step flowchart of a method for processing a distributed transaction according to an embodiment of the present invention. The method may specifically include the following steps:

[0094] Step 101: Send a first call request to the attempt interfaces provided by multiple participants for a transaction identifier;

[0095] Step 102: Receive first call results respectively returned by multiple participants based on a first call request;

[0096] Step 103: Generate an exception message when the first call result returned by any participant with a target transaction identifier is a call failure;

[0097] Step 104: When the first call result returned by any participant with a target transaction identifier is a call failure, send a second call request to a rollback interface provided by a target participant in an asynchronous manner for the target transaction identifier; the above target participant is used to represent a participant that needs to perform a rollback process;

[0098] Step 105: Generate corresponding database records according to the second call result returned by the above target participant based on the second call request; the fields of the above database records include: a call result field;

[0099] Step 106: Perform data consistency verification according to the field content of the above call result field.

[0100] Figure 1 The method embodiments shown can be executed by the initiator of a distributed transaction. Of course, the embodiments of the present invention do not limit Figure 1 the specific execution entity of the method embodiments shown.

[0101] In step 101, the transaction identifier can be an identifier used to uniquely identify a distributed transaction. Different distributed transactions can have different transaction identifiers.

[0102] In practical applications, the initiator can determine multiple participants of a distributed transaction according to actual application requirements. For example, in a user registration scenario, the initiator of the distributed transaction can be a user registration subsystem, and the participants of the distributed transaction can be multiple preset subsystems. Examples of multiple preset subsystems can include: an identity authentication subsystem, a data center subsystem, a video management subsystem, etc. It can be understood that the embodiments of the present invention do not limit the specific participants.

[0103] The embodiments of the present invention can use TCC to handle distributed transactions. TCC splits a transaction into two phases. Among them, the first phase is the try phase, where each participant of the transaction completes business checks, reserves and locks resources; the second phase decides according to the result of the first phase. If all participants are successful in the try phase, an confirm phase is initiated to use the resources reserved in the first phase, otherwise, a cancel phase is initiated to cancel the resources reserved in the first phase.

[0104] In a specific implementation, multiple participants can respectively provide their own attempt interfaces. In the art, an attempt interface is an interface used to attempt to execute transaction operations in the start phase of a transaction. The attempt interface is used to complete business checks, reserve and lock resources in the attempt phase of a distributed transaction. Sending a first call request to the attempt interfaces provided to multiple participants for a transaction identifier can cause the attempt interfaces of the participants to execute the first call request: for the transaction identifier, complete business checks, reserve and lock resources. The result obtained by the attempt interface of a participant executing the first call request can be used as the corresponding first call result.

[0105] In one example, the initiator can use RPC (Remote Procedure Call) technology to send a first call request to the attempt interfaces provided to multiple participants for a transaction identifier. It can be understood that the embodiments of the present invention do not limit the specific sending technology for the first call request. For example, SOAP (Simple Object Access Protocol) technology can be used instead of RPC technology.

[0106] It should be noted that, for a transaction identifier, the first call request can be sent to the attempt interfaces provided to multiple participants in a synchronous or asynchronous manner. The embodiments of the present invention do not limit the synchronous or asynchronous manner corresponding to the first call request.

[0107] In step 102, RPC technology usually provides a conventional way to return a response. After processing the first call request, the attempt interface provided by a participant encapsulates the corresponding first call result in the format specified by RPC technology and sends it to the initiator through the established communication connection.

[0108] In step 103, for any transaction identifier, there can be two types of first call results returned by its corresponding participants: call success or call failure. The reasons for call failure can include: service timeout or system exception, etc. It can be understood that the embodiments of the present invention do not limit the specific reasons for call failure.

[0109] The embodiments of the present invention can divide transaction identifiers into two categories according to the types of first call results returned by participants: target transaction identifiers and non-target transaction identifiers. Among them, the first call result returned by any participant of a target transaction identifier is call failure. The first call results returned by all participants of a non-target transaction identifier are all call success. Therefore, all participants of a non-target transaction identifier are successful in the attempt phase, so a confirmation phase can be initiated for the non-target transaction identifier to use the resources reserved in one phase.

[0110] In the embodiment of the present invention, when the first call result returned by any party participating in the target transaction identifier is a call failure, an exception message can be generated; specifically, the above exception message includes: the target transaction identifier, the party identifier, and the first call result corresponding to the party identifier.

[0111] In one example, the format of the exception message can be JSON (JavaScript Object Notation) format, and specifically can include:

[0112] {

[0113] "uid": "123",

[0114] "lego": "success",

[0115] "passport": "success",

[0116] "qipu": "fail"

[0117] }。

[0118] Among them, the string before the colon ":" represents the key, and the string after the colon ":" represents the value. The key "uid" represents the target transaction identifier, and its value is specifically "123". The key "lego" represents the first party identifier, and its value "success" represents that the first call result corresponding to the first party identifier is a successful call. The key "passport" represents the second party identifier, and its value "success" represents that the first call result corresponding to the second party identifier is a successful call. The key "qipu" represents the third party identifier, and its value "fail" represents that the first call result corresponding to the third party identifier is a call failure.

[0119] In step 104, the above target party is used to represent the party that needs to perform rollback processing. In the embodiment of the present invention, for the target transaction identifier included in the exception message, the party with the first call result of successful call included in the exception message can be used as the target party. The target party can be one or more.

[0120] In a specific implementation, multiple parties can each provide their own rollback interfaces. In this field, the rollback interface is used to cancel the operations performed during the attempt phase when the transaction needs to be cancelled. The rollback interface can be used to initiate the cancellation phase to cancel the reserved resources in the first phase.

[0121] After the initiator of the embodiment of the present invention sends the second call request, it will not wait for the response of the rollback interface (the second call result), but immediately continue to execute the subsequent code. The response of the rollback interface will be processed asynchronously in the background, and when the response is ready, the initiator will be notified through a callback function, an event mechanism, etc.

[0122] For example, if there are multiple target participants, after the main thread sends the second call request to target participant A, it will not wait for the response of the rollback interface of target participant A, but then send the second call request to target participant B. Or, if there are two target participants, the main thread can create a first child thread and a second child thread. The first child thread is used to send the second call request to target participant A, and the second child thread is used to send the second call request to target participant B.

[0123] In step 105, the database processing module can generate corresponding database records according to the second call result returned by the above-mentioned target participant based on the second call request.

[0124] Optionally, after the exception message generation module generates an exception message, it can send the exception message to the database processing module so that the database processing module generates corresponding database records for the target transaction identifier in the exception message.

[0125] The database processing module can obtain the second call result returned by the target participant and generate corresponding database records according to the second call result.

[0126] Referring to Table 1, an example of the database record of an embodiment of the present invention is shown. Among them, the fields of the above-mentioned database record include: a transaction identifier field, a participant identifier field, and a call result field; the field content of the above-mentioned call result field is determined according to the above-mentioned second call result. Among them, when the second call result is a successful rollback, the field content of the call result field can be a successful rollback. When the second call result is a failed rollback, the field content of the call result field can be a failed rollback.

[0127] For example, in the above example of the exception message, for the target transaction identifier "123", the first call result corresponding to the first participant identifier is a successful call, the first call result corresponding to the second participant identifier is a successful call, and the first call result corresponding to the third participant identifier is a failed call. Therefore, the first participant identifier and the second participant identifier can be determined as the target participants. In this way, the database processing module can obtain the second call results returned by the first participant identifier and the second participant identifier and generate corresponding database records according to the second call results. As shown in Table 1, the second call results returned by the first participant identifier and the second participant identifier are both successful rollbacks.

[0128] In addition, in Table 1, the participant identification field "qipu" and the call result field "rollback failed" corresponding to the target transaction identification "456" are also recorded.

[0129] It should be noted that in addition to the transaction identification field, the participant identification field, and the call result field, the above database records may also include other fields. Examples of other fields may include: a record creation time field, a transaction object field, a call number field, etc. Among them, the record creation time field is used to represent the creation time of a database record. The transaction object field can be used to represent the object of the distributed transaction. Taking the user registration transaction as an example, the object of the distributed transaction can be the user account. The call number field may refer to the call number of the distributed transaction corresponding to the database record, and this call number can indicate the number of times the distributed transaction is called.

[0130] Table 1

[0131] Transaction identification field Participant identification field Call result field 123 lego Rollback successful 123 passport Rollback successful 456 qipu Rollback failed …… …… ……

[0132] In step 106, the embodiment of the present invention performs data consistency verification according to the field content of the above call result field. Since the field content of the call result field is determined according to the second call result, and the second call result is the call result of the target participant for the rollback interface, the field content of the above call result field can reflect whether the rollback process is successful.

[0133] In the processing scenario of a distributed transaction, the success or failure of the rollback process is closely related to data consistency. This is because if the rollback process fails to execute successfully, it will lead to an inconsistent state of the data. In the processing scenario of a distributed transaction, multiple participants jointly process the transaction. If the rollback of one target participant fails, it is very likely that the data of the entire distributed transaction will be contradictory or incomplete. Therefore, the embodiment of the present invention can effectively determine whether the data in the distributed transaction is in a consistent state based on the analysis of the call result field, providing an important guarantee for the reliability of the data in the distributed transaction.

[0134] In one implementation manner, the fields of the database record include: a transaction identification field, a participant identification field, and a call result field; the above second call result may specifically include: rollback success or rollback failure; then the process of step 106 performing data consistency verification according to the field content of the above call result field specifically includes:

[0135] Step A1: If the field content of the call result field is rollback success, the verification result is that the data is consistent; or

[0136] Step A2: If the field content of the call result field is rollback failure, the verification result is that the data is inconsistent.

[0137] The above process of data consistency verification can clearly and definitely judge the data consistency status based on the call result field, thereby providing an effective method and a reliable way for data consistency in distributed transaction processing.

[0138] In another implementation, the second call result specifically includes: rollback success or rollback failure; the above method may further include: performing preset processing when the field content of the call result field is rollback failure or the verification result is data inconsistency.

[0139] The above preset processing can provide a repair path for rollback failure, ultimately achieving the result of rollback success, and thus being able to improve the data consistency of distributed transactions.

[0140] Correspondingly, the above-mentioned performing preset processing when the field content of the call result field is rollback failure may specifically include:

[0141] Step B1: For the target transaction identifier, in an asynchronous manner, send a second call request to the rollback interface that failed to roll back again; and / or

[0142] Step B2: Use a preset medium to send relevant transaction information about the rollback failure to a preset user.

[0143] Among them, the preset processing in Step B1 can send a second call request again to re-perform the rollback processing. In a specific implementation, the reason for the rollback failure can be checked, such as network connection problems, system failures, or resource conflicts, etc., and after solving these problems, the second call request is sent again. For example, if the rollback fails due to unstable network connection, then after waiting for the network to recover stability, send a second call request to the rollback interface that failed to roll back again.

[0144] In Step B2, the preset medium can refer to a pre-set channel for transmitting relevant transaction information. The preset processing uses a preset medium such as an email to send relevant transaction information about the rollback failure to a preset user. The relevant transaction information can be used to represent the relevant information of the transaction that failed to roll back. The relevant transaction information may include: target transaction identifier, target participant, time and number of the second call request, etc. information. The preset user is usually a person with certain technical capabilities and decision-making authority. After receiving the relevant transaction information about the rollback failure, the preset user can, based on the analysis of the relevant transaction information, determine the reason for the rollback failure, and after eliminating these reasons, trigger the rollback processing again to obtain the result of rollback success.

[0145] In an alternative implementation of the present invention, the method may further include: generating corresponding database records according to the first call results respectively returned by multiple participants based on the first call request;

[0146] The fields of the database record may further include: a call type field; the field content of the call type field includes: an attempt type, or a rollback type;

[0147] If the field content of the call type field corresponding to the first call request is the attempt type, then when the field content of the call type field is the attempt type, the field content of the call result field is determined according to the first call result;

[0148] If the field content of the call type field corresponding to the second call request is the rollback type, when the field content of the call type field is the rollback type, the field content of the call result field is determined according to the second call result.

[0149] The database record of the embodiment of the present invention can not only record the second call result shown in Table 1, but also record the first call result. In this case, the fields of the database record may further include: a call type field; the field content of the call type field includes: an attempt type, or a rollback type. Among them, the attempt type can represent the call to the attempt interface, and the rollback type can represent the call to the rollback interface.

[0150] Referring to Table 2, an example of the database record of an embodiment of the present invention is shown. Among them, the fields of the above database record include: a call number field, a transaction identification field, a participant identification field, a call result field, and a call type field. In Table 2, the field content of the call number field can be an integer, and its value can start from 1 and increase gradually.

[0151] Table 1 can be used to record the second call result of the rollback type. And Table 2 can not only record the second call result of the rollback type, but also record the first call result of the attempt type. In Table 2, the call result field can represent both the first call result and the second call result. Which call result the call result field specifically represents can be determined according to the call type field.

[0152] It can be understood that those skilled in the art can set other fields in the database record shown in Table 2 according to actual application requirements, such as a record creation time field.

[0153] Table 2

[0154]

[0155] In the case where the call result field can represent both the first call result and the second call result, the process of performing data consistency verification in step 106 according to the field content of the call result field specifically includes:

[0156] Step C1: Obtain the target database records whose field content of the call type field is the rollback type from the database records corresponding to the target transaction identifier;

[0157] Step C2: Perform data consistency verification according to the field content of the call result field in the target database record, specifically including:

[0158] If the field content of the call result field in the target database record is rollback successful, the verification result is data consistent; or

[0159] If the field content of the call result field in the target database record is rollback failed, the verification result is data inconsistent.

[0160] Assume that the target transaction identifier is "123". First, the target database records whose field content of the call type field is the rollback type can be obtained from the database records shown in Table 2: the data records with call numbers 4 and 5. Then, data consistency verification can be performed according to the field content of the call result field in the data records with call numbers 4 and 5. Since the field content of the call result field in the data records with call numbers 4 and 5 is rollback successful, the corresponding verification results can both be data consistent.

[0161] In summary, for the distributed transaction processing method according to the embodiments of the present invention, first, a first call request is sent to the attempt interfaces of multiple participants for the transaction identifier; then, the first call results returned by these participants are received; next, in the case where the first call result of any participant is a call failure, an exception message is generated; after that, in the case where the first call result returned by any participant of the target transaction identifier is a call failure, for the target transaction identifier of the target participant that needs to be rollback processed, a second call request is sent to its rollback interface asynchronously; subsequently, a corresponding database record is generated according to the second call result returned by the target participant, and this database record includes a call result field; then, data consistency verification is performed according to the content of the call result field.

[0162] In the embodiments of the present invention, the second call request is sent to the rollback interface of the target participant in an asynchronous manner. When there is only one target participant, after the second call request is sent to the rollback interface of the single target participant, the embodiments of the present invention do not need to wait for the return result of this target participant. Therefore, the processing duration of the distributed transaction can be reduced. When there are multiple target participants, after the second call request is sent to the rollback interface of target participant A, the embodiments of the present invention do not need to wait for the return result of target participant A and directly send the second call request to the rollback interface of target participant B. Therefore, the processing duration of the distributed transaction can be reduced. In summary, whether there is one or multiple target participants, the embodiments of the present invention can reduce the processing duration of the distributed transaction and improve the processing efficiency of the distributed transaction.

[0163] Moreover, when the first call result returned by any participant is a call failure, the embodiments of the present invention generate an exception message, and the above exception message can quickly and accurately locate the participant with the call failure and the target participant that has a successful call and requires rollback processing.

[0164] In addition, the embodiments of the present invention generate database records according to the second call results returned by the target participants, and perform data consistency verification based on the call result fields in the database records. The obtained verification results can reflect whether the data is consistent during the processing of the distributed transaction. In this way, the situation of data inconsistency can be discovered and processed in a timely manner. Therefore, the accuracy and reliability of the distributed transaction can be improved.

[0165] Referring to Figure 2 , a step flowchart of a method for processing a distributed transaction according to an embodiment of the present invention is shown. This method is used for processing a distributed transaction in a user registration scenario, and the method may specifically include the following steps:

[0166] Step 201, receive a user registration request;

[0167] Step 202, determine the transaction identifier corresponding to the above user registration request and multiple preset subsystems corresponding to the above user registration request; the above transaction identifier is used to synchronize the above user information to multiple preset subsystems;

[0168] Step 203, send a first call request to the attempt interfaces provided by multiple preset subsystems for the transaction identifier;

[0169] Step 204, receive the first call results respectively returned by the above multiple preset subsystems based on the first call request;

[0170] Step 205, generate an exception message when the first call result returned by any preset subsystem of the target transaction identifier is a call failure;

[0171] Step 206, in the case where the first call result returned by any preset subsystem of the target transaction identifier is a call failure, for the target transaction identifier, in an asynchronous manner, send a second call request to the rollback interface provided by the target preset subsystem; the above target preset subsystem is used to represent the preset subsystem that needs to perform rollback processing;

[0172] Step 207, after sending the second call request, return the user registration result;

[0173] Step 208, generate a corresponding database record according to the second call result returned by the above target preset subsystem based on the second call request; the fields of the above database record may include: a call result field;

[0174] Step 209, perform data consistency verification according to the field content of the above call result field.

[0175] Figure 2 The method embodiments shown can be used for processing distributed transactions in the user registration scenario, and can be executed by the user registration subsystem. The user registration subsystem can be the initiator of the distributed transaction, and multiple preset subsystems can be the participants of the distributed transaction. Examples of multiple preset subsystems can include: an identity authentication subsystem, a data center subsystem, a video management subsystem, etc. It can be understood that the embodiments of the present invention do not limit the specific preset subsystems.

[0176] In step 201, the user registration subsystem can provide a user interface to the user so that the user can input and submit a user registration request in the user interface. The user registration request may include: various user information.

[0177] After receiving the user registration request, the user registration subsystem can allocate a user account for the user registration request and trigger the distributed transaction corresponding to the user registration request.

[0178] In step 202, determine the transaction identifier corresponding to the above user registration request and the multiple preset subsystems corresponding to the above user registration request. Among them, a string can be allocated for the user registration request as the transaction identifier. Or, the user account can be used as the transaction identifier. It can be understood that those skilled in the art can determine the transaction identifier corresponding to the above user registration request according to actual application requirements. The embodiments of the present invention do not limit the specific determination method of the transaction identifier.

[0179] In step 203, multiple preset subsystems can be multiple participants of the distributed transaction. Specifically, for the transaction identifier, in a synchronous manner or an asynchronous manner, send a first call request to the try interface provided by the multiple preset subsystems.

[0180] In step 204, the RPC technology can be used to receive the first call results respectively returned by the multiple preset subsystems based on the first call request. The first call result can be a successful call or a failed call.

[0181] In step 205, in the case where the first call result returned by any one of the preset subsystems with the target transaction identifier is a failed call, an exception message is generated. The above exception message can quickly and accurately locate the preset subsystem where the call fails and the target preset subsystem that has a successful call and requires rollback processing.

[0182] In step 206, for the target transaction identifier included in the exception message, the preset subsystems with the first call result of successful call included in the exception message can be used as the target preset subsystems. The target preset subsystem can be one or more.

[0183] In a specific implementation, each of the multiple preset subsystems can provide its own rollback interface. The rollback interface can be used to initiate a cancellation phase to cancel the reserved resources in the first phase.

[0184] After the user registration subsystem of the embodiment of the present invention sends the second call request, it does not wait for the response (the second call result) of the rollback interface, but immediately continues to execute the subsequent code. The response of the rollback interface will be processed asynchronously in the background, and when the response is ready, the initiator will be notified through methods such as callback functions and event mechanisms.

[0185] In step 207, after the user registration subsystem sends the second call request, it can return the user registration result to the user, so that the response efficiency of the user registration request can be improved.

[0186] In step 208, the database processing module can generate corresponding database records according to the second call results returned by the above target preset subsystems based on the second call request.

[0187] Optionally, after generating the exception message, the exception message generation module can send the exception message to the database processing module, so that the database processing module generates corresponding database records for the target transaction identifier in the exception message.

[0188] The database processing module can obtain the second call results returned by the target preset subsystems and generate corresponding database records according to the second call results.

[0189] Since the target preset subsystem is a specific example of the target participant, the database record in step 208 can refer to Table 1. The fields of the above database record include: a transaction identification field, a participant identification field, and a call result field; the field content of the above call result field is determined according to the above second call result. Among them, when the second call result is a successful rollback, the call result field can also be a successful rollback. When the second call result is a failed rollback, the call result field can also be a failed rollback.

[0190] In step 209, since the field content of the call result field is determined according to the second call result, and the second call result is the call result of the target participant for the rollback interface, the field content of the above call result field can reflect whether the rollback process is successful.

[0191] In the processing scenario of distributed transactions, the success or failure of the rollback process is closely related to data consistency. This is because if the rollback process fails to execute successfully, it will cause the data to be in an inconsistent state. In the processing scenario of distributed transactions, multiple participants jointly process transactions. If the rollback of one target participant fails, it is very likely that the data of the entire distributed transaction will be contradictory or incomplete. Therefore, the embodiment of the present invention can effectively determine whether the data in the distributed transaction is in a consistent state based on the analysis of the call result field, providing an important guarantee for the reliability of the data in the distributed transaction.

[0192] In one implementation, the above second call result may specifically include: a successful rollback or a failed rollback; then, the process of performing data consistency verification according to the field content of the above call result field specifically includes: if the field content of the call result field is a successful rollback, the verification result is that the data is consistent; or, if the field content of the call result field is a failed rollback, the verification result is that the data is inconsistent.

[0193] The above process of data consistency verification can clearly and definitely judge the consistency state of the data based on the call result field, thereby providing an effective method and a reliable way for data consistency in distributed transaction processing.

[0194] In another implementation, the second call result specifically includes: a successful rollback or a failed rollback; the above method may further include: performing a preset process when the field content of the call result field is a failed rollback or the verification result is that the data is inconsistent.

[0195] The above preset process can provide a repair path for a failed rollback, ultimately achieving the result of a successful rollback, and thus being able to improve the data consistency of distributed transactions.

[0196] Accordingly, when the field content of the above call result field is a rollback failure, preset processing is performed, which may specifically include: for the target transaction identifier, asynchronously sending a second call request to the rollback interface where the rollback fails; and / or using a preset medium to send relevant transaction information about the rollback failure to a preset user.

[0197] Referring to Figure 3 , a schematic flowchart of a method for processing a distributed transaction according to an embodiment of the present invention is shown, where the method specifically includes: a user registration link 301, a try processing link 302, an exception message generation link 303, a rollback processing link 304, and a data consistency verification link 305.

[0198] Among them, in the user registration link 301, a user registration request can be received, and processing such as user account allocation can be performed on the user registration request. User account allocation can allocate a corresponding user account for the user registration request.

[0199] In the try processing link 302, synchronous calls can be made to try interfaces provided by multiple preset subsystems such as an identity authentication subsystem, a data center subsystem, and a video management subsystem. Specifically, a first call request can be sent to the try interface of the preset subsystem. The try interface of the preset subsystem can return the first call result.

[0200] In practical applications, due to reasons such as service timeout or system exception, the first call result of a preset subsystem may be a call failure. When the first call result returned by any preset subsystem with the target transaction identifier is a call failure, the exception message generation link 303 generates an exception message and sends the exception message to the rollback processing link 304 and the data consistency verification link 305.

[0201] In one example, the exception message may specifically include:

[0202] {

[0203] "uid": "123",

[0204] "lego": "success",

[0205] "passport": "success",

[0206] "qipu": "fail"

[0207] }.

[0208] In the example of the above abnormal message, for the target transaction identifier "123", the first call result corresponding to the first participant identifier (video management subsystem) is a successful call, the first call result corresponding to the second participant identifier (identity authentication subsystem) is a successful call, and the first call result corresponding to the third participant identifier (data center subsystem) is a failed call.

[0209] In the rollback processing step 304, the video management subsystem and the identity authentication subsystem can be determined as the target preset subsystems, and the rollback interfaces provided by the target preset subsystems such as the video management subsystem and the identity authentication subsystem can be asynchronously called. The rollback interface of the target preset subsystem can pass back the second call result.

[0210] In the data consistency verification step 305, a corresponding database record can be generated according to the second call result returned by the above target preset subsystem based on the second call request, and data consistency verification can be performed according to the field content of the above call result field.

[0211] The database record of the data consistency verification step 305 is shown in Table 1. The embodiments of the present invention can effectively determine whether the data in the distributed transaction is in a consistent state based on the analysis of the call result field in the database record, providing an important guarantee for the reliability of the data in the distributed transaction.

[0212] In the case where the field content of the call result field is a failed rollback or the verification result is inconsistent data, preset processing is performed. The above preset processing can provide a repair path for the failed rollback, and finally achieve the result of a successful rollback, thereby being able to improve the data consistency of the distributed transaction.

[0213] It should be noted that for the method embodiments, for simplicity of description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the embodiments of the present invention are not limited by the described action sequence, because according to the embodiments of the present invention, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily essential for the embodiments of the present invention.

[0214] Refer to Figure 4 , which shows a schematic structural diagram of a distributed transaction processing device according to an embodiment of the present invention. The distributed transaction processing device may specifically include the following modules: a first call sending module 401, a first call result receiving module 402, an abnormal message generating module 403, a second call sending module 404, a database record generating module 405, and a data consistency verification module 406.

[0215] Among them, the first call sending module 401 is used to send a first call request to the attempt interfaces provided by multiple participants for a transaction identifier;

[0216] The first call result receiving module 402 is used to receive the first call results respectively returned by multiple participants based on the first call request;

[0217] The exception message generating module 403 is used to generate an exception message when the first call result returned by any one of the participants of the target transaction identifier is a call failure;

[0218] The second call sending module 404 is used to, when the first call result returned by any one of the participants of the target transaction identifier is a call failure, send a second call request to the rollback interface provided by the target participant in an asynchronous manner for the target transaction identifier; the target participant is used to represent the participant that needs to perform rollback processing;

[0219] The database record generating module 405 is used to generate a corresponding database record according to the second call result returned by the target participant based on the second call request; the fields of the database record include: a call result field;

[0220] The data consistency verification module 406 is used to perform data consistency verification according to the field content of the call result field.

[0221] Optionally, the fields of the database record include: a transaction identifier field, a participant identifier field, and a call result field; the second call result includes: rollback success or rollback failure; the data consistency verification module includes:

[0222] The first verification module is used to, if the field content of the call result field is rollback success, the verification result is data consistency; or

[0223] The second verification module is used to, if the field content of the call result field is rollback failure, the verification result is data inconsistency.

[0224] Optionally, when the field content of the call result field is rollback failure, or the verification result is data inconsistency, the device further includes:

[0225] The first preset processing module is used to, for the target transaction identifier, send a second call request to the rollback interface with rollback failure again in an asynchronous manner; and / or

[0226] The second preset processing module is used to send the relevant transaction information of rollback failure to a preset user by using a preset medium.

[0227] Optionally, the device further includes:

[0228] A generation module, configured to generate corresponding database records according to first call results respectively returned by multiple participating parties based on a first call request;

[0229] The fields of the database records further include: a call type field; the field content of the call type field includes: an attempt type or a rollback type;

[0230] When the field content of the call type field corresponding to the first call request is the attempt type, the field content of the call result field is determined according to the first call result;

[0231] When the field content of the call type field corresponding to the second call request is the rollback type, the field content of the call result field is determined according to the second call result.

[0232] Optionally, the data consistency verification module includes:

[0233] A record acquisition module, configured to acquire target database records whose field content of the call type field is the rollback type from the database records corresponding to the target transaction identifier;

[0234] A third verification module, configured to, if the field content of the call result field in the target database record is rollback successful, the verification result is that the data is consistent; or

[0235] A fourth verification module, configured to, if the field content of the call result field in the target database record is rollback failed, the verification result is that the data is inconsistent.

[0236] Refer to Figure 5 , which shows a schematic structural diagram of a processing device for a distributed transaction according to an embodiment of the present invention. The processing device for the distributed transaction is applied to a user registration scenario and may specifically include the following modules: a request receiving module 501, a determination module 502, a first call module 503, a first call result receiving module 504, an exception message generation module 505, a second call module 506, a registration result return module 507, a database record generation module 508, and a data consistency verification module 509.

[0237] Among them, the request receiving module 501 is configured to receive a user registration request;

[0238] The determination module 502 is configured to determine a transaction identifier corresponding to the user registration request and multiple preset subsystems corresponding to the user registration request; the transaction identifier is used to synchronize the user information to the multiple preset subsystems;

[0239] The first call module 503 is configured to send a first call request to the attempt interfaces provided by multiple preset subsystems for a transaction identifier.

[0240] The first call result receiving module 504 is configured to receive the first call results respectively returned by the multiple preset subsystems based on the first call request.

[0241] The exception message generating module 505 is configured to generate an exception message when the first call result returned by any one of the preset subsystems for the target transaction identifier is a call failure.

[0242] The second call module 506 is configured to, when the first call result returned by any party involved in the target transaction identifier is a call failure, send a second call request to the rollback interface provided by the target preset subsystem for the target transaction identifier in an asynchronous manner; the target preset subsystem is used to represent the preset subsystem that needs to perform rollback processing.

[0243] The registration result returning module 507 is configured to return a user registration result after sending the second call request.

[0244] The database record generating module 508 is configured to generate a corresponding database record according to the second call result returned by the target preset subsystem based on the second call request; the fields of the database record include: a call result field.

[0245] The data consistency verification module 509 is configured to perform data consistency verification according to the field content of the call result field.

[0246] An embodiment of the present invention further provides an electronic device, and this electronic device can implement the functions of the foregoing storage node or scheduling node or ledger node or management node.

[0247] As Figure 6 shown, the electronic device may include a processor 1001, a communication interface 1002, a memory 1003, and a communication bus 1004. Among them, the processor 1001, the communication interface 1002, and the memory 1003 communicate with each other through the communication bus 1004.

[0248] The memory 1003 is used to store a computer program.

[0249] When the processor 1001 is configured to execute the program stored in the memory 1003, the following steps are implemented:

[0250] Store the storage object.

[0251] Send the storage object to the coupled second storage node so that the second storage node stores and / or forwards the storage object.

[0252] After successfully storing a storage object, object information of the storage object is sent to a ledger node so that the ledger node saves ledger information of the first storage node; the ledger information includes: object information stored in the corresponding storage node.

[0253] The communication bus mentioned in the above electronic device may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience in representation, only a thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0254] The communication interface is used for communication between the above electronic device and other devices.

[0255] The memory may include a Random Access Memory (RAM), or may also include a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one processing device for distributed transactions located far from the aforementioned processor.

[0256] The above processor may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0257] In another embodiment provided by the present invention, a computer-readable storage medium is further provided. Instructions are stored in the computer-readable storage medium, and when it runs on a computer, it causes the computer to execute the processing method of the distributed transaction described in any one of the above embodiments.

[0258] In another embodiment provided by the present invention, there is also provided a computer program product including instructions, which, when running on a computer, causes the computer to execute the processing method of the distributed transaction described in any one of the above embodiments.

[0259] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that includes one or more integrated available media. Examples of the available medium can be magnetic media (such as floppy disks, hard disks, magnetic tapes), optical media, or semiconductor media (such as solid state disk (SSD)). Examples of optical media can include DVD (Digital Video Disc).

[0260] It should be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including", or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or further includes elements inherent to such process, method, article, or device. Without further limitation, an element defined by the statement "including a..." does not exclude the existence of additional identical elements in the process, method, article, or device including the element.

[0261] Each embodiment in this specification is described in a related manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for the relevant parts, reference can be made to the partial description of the method embodiment.

[0262] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention are all included in the protection scope of the present invention.

Claims

1. A distributed transaction processing method, characterized in that: The method comprises: Sending a first call request to the attempt interface provided by the multiple participants according to the transaction identifier; Receiving first call results returned by multiple participants based on the first call request; When the first call result returned by any participant of the target transaction identifier is a call failure, an exception message is generated; In the case that the first call result returned by any participant of the target transaction identifier is a call failure, a second call request is sent to the rollback interface provided by the target participant in an asynchronous manner for the target transaction identifier; the target participant is used to represent the participant that needs to be rolled back; Generate a corresponding database record according to the second call result returned by the target participant based on the second call request; the database record includes: a call result field; A data consistency check is performed based on the field content of the call result field.

2. The method according to claim 1, characterized in that The fields of the database record include: a transaction identification field, a participant identification field, and a call result field; the second call result includes: rollback success or rollback failure; The performing of data consistency check according to the field content of the call result field includes: If the field content of the call result field is rollback success, the verification result is data consistency; or If the field content of the call result field is rollback failure, the verification result is data inconsistency.

3. The method according to claim 2, characterized in that When the field content of the call result field is rollback failure, or the verification result is data inconsistency, the method further includes: For the target transaction identifier, in an asynchronous manner, a second call request is sent again to the rollback interface that failed to roll back; and / or The relevant transaction information of the failed rollback is sent to the preset user by using the preset medium; the relevant transaction information is used to represent the relevant information of the transaction that failed to roll back.

4. The method according to claim 2, characterized in that: The method further includes: generating corresponding database records according to first call results returned by the multiple participants based on the first call request respectively; The fields of the database record also include: a call type field; the field content of the call type field includes: an attempt type or a rollback type; The field content of the call type field corresponding to the first call request is an attempt type. In the case where the field content of the call type field is an attempt type, the field content of the call result field is determined according to the first call result; The field content of the call type field corresponding to the second call request is a rollback type. In the case where the field content of the call type field is a rollback type, the field content of the call result field is determined according to the second call result.

5. The method according to claim 4, characterized in that The performing of data consistency check according to the field content of the call result field includes: Obtain, from the database record corresponding to the target transaction identifier, a target database record whose field content of the call type field is a rollback type; If the field content of the call result field in the target database record is rollback success, the verification result is data consistency; or If the field content of the call result field in the target database record is rollback failure, the verification result is data inconsistency.

6. A method for processing distributed transactions, characterized in that: The method is applied to a user registration scenario, including: Receive user registration request; Determine a transaction identifier corresponding to the user registration request and a plurality of preset subsystems corresponding to the user registration request; the transaction identifier is used to synchronize the user information to the plurality of preset subsystems; Sending a first call request to the attempt interface provided by the plurality of preset subsystems according to the transaction identifier; Receiving first call results returned by the plurality of preset subsystems respectively based on the first call request; When the first call result returned by any preset subsystem of the target transaction identifier is a call failure, an exception message is generated; In the case that the first call result returned by any participant of the target transaction identifier is a call failure, a second call request is sent to the rollback interface provided by the target preset subsystem in an asynchronous manner for the target transaction identifier; the target preset subsystem is used to represent the preset subsystem that needs to be rolled back; After sending the second call request, the user registration result is returned; Generate a corresponding database record according to the second call result returned by the target preset subsystem based on the second call request; the fields of the database record include: a call result field; A data consistency check is performed based on the field content of the call result field.

7. A distributed transaction processing device, characterized in that: The device comprises: A first call sending module is used to send a first call request to the attempt interface provided by multiple participants according to the transaction identifier; A first call result receiving module, used to receive first call results returned by multiple participants based on the first call request; An exception message generating module, used for generating an exception message when the first call result returned by any participant of the target transaction identification is a call failure; A second call sending module is used to send a second call request to a rollback interface provided by a target participant in an asynchronous manner for the target transaction identifier when the first call result returned by any participant of the target transaction identifier is a call failure; the target participant is used to represent the participant that needs to be rolled back; A database record generation module, used to generate a corresponding database record according to the second call result returned by the target participant based on the second call request; the fields of the database record include: a call result field; The data consistency check module is used to perform data consistency check according to the field content of the call result field.

8. A distributed transaction processing device, characterized in that: The device is applied to a user registration scenario, including: A request receiving module, used to receive user registration requests; A determination module, used to determine a transaction identifier corresponding to the user registration request and a plurality of preset subsystems corresponding to the user registration request; the transaction identifier is used to synchronize the user information to the plurality of preset subsystems; A first calling module, used for sending a first calling request to the attempt interface provided by the plurality of preset subsystems according to the transaction identifier; A first call result receiving module, used for receiving first call results returned by the plurality of preset subsystems respectively based on the first call request; An exception message generating module, used for generating an exception message when the first call result returned by any preset subsystem of the target transaction identifier is a call failure; A second calling module is used to send a second calling request to a rollback interface provided by a target preset subsystem in an asynchronous manner for the target transaction identifier when the first calling result returned by any participant of the target transaction identifier is a call failure; the target preset subsystem is used to represent a preset subsystem that needs to be rolled back; A registration result returning module, used to return the user registration result after sending the second call request; A database record generation module, used to generate a corresponding database record according to the second call result returned by the target preset subsystem based on the second call request; the fields of the database record include: a call result field; The data consistency check module is used to perform data consistency check according to the field content of the call result field.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, for implementing the method steps described in any one of claims 1 to 6 when executing a program stored in a memory.

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

Images