Distributed transaction processing method and device
By determining database sharding based on transaction ID and sharding rules in a distributed system, and using idempotent information table and compensation transaction mechanism, the consistency problem of distributed transactions in a multi-slicing environment is solved, and the stability of the system is achieved and consistency.
Patent Information
- Application Number
- CN202411722185.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-28
- Publication Date
- 2025-02-21
AI Technical Summary
In a distributed system, the complex relationship between multiple sharding elements and sharding rules makes it difficult to ensure consistency in transactions across multiple shards.
By receiving a submission request for a branch transaction, the database shard is determined based on the transaction ID and preset shard rules, and the transaction is started on the shard. If the transaction is successfully written to the idempotent information table, business logic is executed; otherwise, it will roll back to the target branch transaction and return the failed information. For compensation transaction requests, similar processing is performed to ensure consistency.
Ensure the consistency of distributed transactions in a multi-slicing environment, and avoid data inconsistency and system errors through idempotent information tables and compensation transaction mechanisms.
Smart Images
Figure CN119493635A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing technology, and in particular to a method and device for processing distributed transactions. Background Art
[0002] With the rapid development of global informatization, system architecture upgrade has become an imminent trend. During the distributed upgrade of the system architecture, distributed transactions are needed to ensure the data consistency between this system and other systems.
[0003] At present, sharding elements and sharding rules are generally defined in this system, and the data of this system and other systems are unified through these sharding elements and sharding rules. However, if there are multiple sharding elements and sharding rules in other systems, and there is a many-to-many relationship between sharding rules and sharding elements, when a transaction involves multiple shards, the system needs to ensure the atomicity, isolation and consistency of these operations. If the sharding rules and elements are complex and inconsistent, it is difficult to ensure that transactions across multiple shards can guarantee consistency.
[0004] Therefore, how to ensure the consistency of distributed transactions has become an urgent problem to be solved in this field. Summary of the invention
[0005] The present application provides a distributed transaction processing method and device, the purpose of which is to ensure the consistency of distributed transactions.
[0006] In order to achieve the above objectives, this application provides the following technical solutions:
[0007] A distributed transaction processing method, comprising:
[0008] When receiving a commit request for the current branch transaction, determining the database shard where the current branch transaction is located according to the current branch transaction ID in the commit request and the preset sharding rule, and opening the current branch transaction at the database shard where the current branch transaction is located;
[0009] If the current branch transaction is started and completed, write the current branch transaction into the idempotent information table;
[0010] If the current branch transaction is written successfully, the business logic corresponding to the current branch transaction is executed;
[0011] If the business logic fails to execute, roll back to the target branch transaction of the current branch transaction and return submission failure information; the target branch transaction indicates all branch transactions that have been executed before the current branch transaction is executed;
[0012] When receiving a compensation transaction request of the target branch transaction sent according to the submission failure information, determining the database shard where the target branch transaction is located according to the target branch transaction ID and the preset sharding rule, and opening the target branch transaction at the database shard where the target branch transaction is located;
[0013] When the target branch transaction is successfully written into the idempotent information table, writing the compensation transaction branch transaction in the compensation transaction request into the idempotent information table;
[0014] When the compensating transaction branch transaction is written successfully, the compensating transaction branch transaction is committed.
[0015] Optionally, also include:
[0016] If the writing of the current branch transaction fails, obtaining the failure reason of the current branch transaction;
[0017] When the failure reason is a first other reason, an error prompt message is fed back; the first other reason indicates a reason other than a branch transaction consistent with the current branch transaction.
[0018] Optionally, also include:
[0019] When the failure reason is that there is a branch transaction that is consistent with the current branch transaction, query the idempotence information table to see whether there is a compensation transaction corresponding to the current branch transaction ID;
[0020] If there is a compensation transaction corresponding to the current branch transaction ID in the idempotence information table, a failure prompt message is returned;
[0021] If there is no compensating transaction corresponding to the current branch transaction ID in the idempotent information table, a successful prompt message is returned.
[0022] Optionally, also include:
[0023] If the business logic is executed successfully, the current branch transaction is committed and prompt information of successful execution is returned.
[0024] Optionally, also include:
[0025] When the target branch transaction fails to be written into the idempotent information table, obtaining the failure reason of the target branch transaction;
[0026] When the failure reason is that there is a branch transaction that is consistent with the target branch transaction, writing the compensation transaction branch transaction in the compensation transaction request into the idempotent information table;
[0027] When the compensation transaction branch transaction is written successfully, executing the business logic corresponding to the compensation transaction branch transaction;
[0028] If the business logic corresponding to the compensation transaction branch transaction is executed successfully, submit the compensation transaction transaction;
[0029] If the business logic corresponding to the compensation transaction branch transaction fails to execute, it is rolled back to the target branch transaction.
[0030] Optionally, also include:
[0031] When the writing of the compensation transaction branch transaction fails, obtaining the failure reason of the compensation transaction branch transaction;
[0032] When the failure reason is that there is a branch transaction that is consistent with the compensation transaction branch transaction, a success prompt message is returned.
[0033] Optionally, also include:
[0034] When the failure reason is a second other reason, or when the writing of the compensation transaction branch transaction fails, error prompt information is fed back; wherein the second other reason indicates a reason other than a branch transaction consistent with the target branch transaction.
[0035] A distributed transaction processing device, comprising:
[0036] A first determining unit is configured to, when receiving a commit request for a current branch transaction, determine the database shard where the current branch transaction is located according to the current branch transaction ID in the commit request and a preset sharding rule, and start the current branch transaction at the database shard where the current branch transaction is located;
[0037] A first writing unit, configured to write the current branch transaction into an idempotent information table if the current branch transaction is started and completed;
[0038] An execution unit, configured to execute the business logic corresponding to the current branch transaction if the current branch transaction is written successfully;
[0039] A return unit, configured to roll back to the target branch transaction of the current branch transaction and return submission failure information if the business logic fails to execute; the target branch transaction indicates all branch transactions that have been executed before the current branch transaction is executed;
[0040] A second determining unit is configured to, when receiving a compensation transaction request of the target branch transaction sent according to the submission failure information, determine the database shard where the target branch transaction is located according to the target branch transaction ID and a preset sharding rule, and start the target branch transaction at the database shard where the target branch transaction is located;
[0041] A second writing unit, configured to write the compensation transaction branch transaction in the compensation transaction request into the idempotence information table when the target branch transaction is successfully written into the idempotence information table;
[0042] The commit unit is used to commit the compensating transaction branch transaction when the compensating transaction branch transaction is written successfully.
[0043] Optionally, also include:
[0044] an acquisition unit, configured to acquire a failure reason of the current branch transaction if the writing of the current branch transaction fails;
[0045] A feedback unit is used to feedback error prompt information when the failure reason is a first other reason; the first other reason indicates a reason other than a branch transaction consistent with the current branch transaction.
[0046] Optionally, also include:
[0047] A query unit, configured to query whether there is a compensation transaction corresponding to the current branch transaction ID in the idempotence information table when the failure reason is that there is a branch transaction consistent with the current branch transaction;
[0048] A first information returning unit, configured to return a failure prompt message if there is a compensation transaction corresponding to the current branch transaction ID in the idempotent information table;
[0049] The second information returning unit is used to return a successful prompt message if there is no compensation transaction corresponding to the current branch transaction ID in the idempotent information table.
[0050] The technical solution provided by the present application is as follows: when a commit request for the current branch transaction is received, the database shard where the current branch transaction is located is determined according to the current branch transaction ID and the preset sharding rules in the commit request, and the current branch transaction is started at the database shard where the current branch transaction is located; if the current branch transaction is started, the current branch transaction is written into the idempotence information table; if the current branch transaction is written successfully, the business logic corresponding to the current branch transaction is executed; if the business logic execution fails, it is rolled back to the target branch transaction of the current branch transaction, and the commit failure information is returned; when a compensation transaction request for the target branch transaction sent according to the commit failure information is received, the database shard where the target branch transaction is located is determined according to the target branch transaction ID and the preset sharding rules, and the target branch transaction is started at the database shard where the target branch transaction is located; when the target branch transaction is successfully written into the idempotence information table, the compensation transaction branch transaction in the compensation transaction request is written into the idempotence information table; when the compensation transaction branch transaction is written successfully, the compensation transaction branch transaction is committed. If the business logic of the current branch transaction fails to execute, it will roll back to the branch transaction that has been executed before the current branch transaction, and execute the compensation transaction request. Through the compensation operation, the part of the transaction that has been successfully executed is corrected or recovered, thereby ensuring the consistency of the distributed transaction. BRIEF DESCRIPTION OF THE DRAWINGS
[0051] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0052] Figure 1 A flowchart of a distributed transaction processing method provided in an embodiment of the present application;
[0053] Figure 2 A flowchart of a method for analyzing failure causes provided in an embodiment of the present application;
[0054] Figure 3 A flowchart of a supplementary transaction query method provided in an embodiment of the present application;
[0055] Figure 4 A flowchart of a method for writing a compensation transaction branch transaction provided in an embodiment of the present application;
[0056] Figure 5 A flowchart of a method for analyzing a compensation transaction branch transaction provided in an embodiment of the present application;
[0057] Figure 6A schematic diagram of a global transaction and branch transaction calling process provided in an embodiment of the present application;
[0058] Figure 7 A schematic diagram of the architecture of a distributed transaction processing device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0059] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0060] In this application, the terms "comprises", "comprising" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprising a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element.
[0061] like Figure 1 As shown, it is a flowchart of a distributed transaction processing method provided in an embodiment of the present application, which is applied to a service provider and includes the following steps:
[0062] S101: When a commit request for a current branch transaction is received, the database shard where the current branch transaction is located is determined according to the current branch transaction ID in the commit request and a preset sharding rule, and the current branch transaction is started at the database shard where the current branch transaction is located.
[0063] When the service caller opens a global transaction, each branch transaction will be executed in sequence, and a branch transaction ID will be calculated for each branch transaction. When a branch transaction is an RPC call, the branch transaction ID is transmitted to the service provider through the RPC call.
[0064] It can be understood that when a current branch transaction submission request is received from a service caller, the database shard where the current branch transaction is located is determined based on the current branch transaction ID in the submission request and the preset sharding rule. Specifically, the current branch transaction ID is used as input for hash operation to obtain the database shard ID, and the database shard corresponding to the database shard ID is selected from the preset sharding rule and used as the database shard where the current branch transaction is located.
[0065] It should be noted that for the service caller, if distributed transactions are required and there are rpc calls in the distributed transaction business logic, the service provider needs to provide an rpc interface that can have branch transaction characteristics. The service provider first needs to introduce the dependency of the present invention in the pom file, and then add the @idempotent annotation in this solution to the rpc interface. At the same time, the service provider needs to specify the sharding elements and sharding rules of the current branch transaction in the @idempotent annotation, so that the database shard where the branch transaction is located can be calculated later according to the @idempotent annotation.
[0066] It should be emphasized that the AOP feature is used to set the entry point on the @idempotent annotation. In the section, the shard key of the current branch transaction (that is, the database shard where the current branch transaction is located) is calculated according to the sharding elements and sharding rules specified in the annotation, ensuring that the idempotent information table and business logic processing are in the same shard, thereby ensuring the effectiveness of the current branch transaction opening.
[0067] S102: If the current branch transaction is started and completed, the current branch transaction is written into the idempotent information table.
[0068] The specific form of the idempotence information table is shown in Table 1.
[0069] Table 1
[0070] Field Name Field meaning constraint type branch_id Branch transaction id Primary Key varchar(64) id_shard Shard key Primary Key char(8) trans_status Branch transaction status Primary Key varchar(20) shard_key Slice elements Not empty varchar(64) shard_method Sharding rules Not empty varchar(64) code_tr Transaction Code Not empty varchar(64) date_req Transaction request date Not empty char(8) num_jrn_no Transaction log number Not empty varchar(10) time_cur Log insertion time Not empty datetime txt_rem Remark varchar(500)
[0071] It should be noted that the contents shown in the idempotence information table are only used for illustration.
[0072] It should be emphasized that the main purpose of writing the current branch transaction into the idempotence information table is to ensure that transaction operations in the distributed system are idempotent, that is, multiple executions of the same transaction will not produce inconsistent or duplicate results.
[0073] Optionally, after step S102, if the current branch transaction fails to write, it is also necessary to analyze the cause of the write failure to ensure the atomicity and consistency of the transaction. Therefore, another embodiment of the present application provides a method for analyzing the cause of the failure, such as Figure 2 As shown, the following steps are included:
[0074] S201: If the writing of the current branch transaction fails, the failure reason of the current branch transaction is obtained.
[0075] The failure reasons of the current branch transaction include but are not limited to: database connection failure, network failure, and primary key conflict.
[0076] Optionally, after step S201, if the failure reason is a primary key conflict, it is also necessary to query whether there is a compensating transaction to avoid repeated submission of the same transaction request and ensure the idempotence of the system operation. Therefore, another embodiment of the present application provides a supplementary transaction query method, such as Figure 3 As shown, the following steps are included:
[0077] S301: When the failure reason is that there is a branch transaction that is consistent with the current branch transaction, query whether there is a compensation transaction corresponding to the current branch transaction ID in the idempotence information table.
[0078] If there is a compensating transaction corresponding to the current branch transaction ID in the idempotence information table, step S302 is executed; if there is no compensating transaction corresponding to the current branch transaction ID in the idempotence information table, step S303 is executed.
[0079] Among them, when the failure reason is that there is a branch transaction that is consistent with the current branch transaction, it means that there is a primary key conflict in the idempotence information table. Check whether there is a compensation transaction corresponding to the current branch transaction ID in the idempotence information table. If there is a compensation transaction corresponding to the current branch transaction ID in the idempotence information table, it means that the transaction has already executed a compensation transaction or has been processed. At this time, the current compensation operation should be skipped (that is, a failure prompt message is returned) to avoid repeated processing. If the query result is empty, it means that the branch transaction has not yet executed a compensation operation, and a successful prompt message is returned. Continue to execute the idempotence operation (such as the execution of the compensation transaction) and insert it into the idempotence information table.
[0080] S302: Return failure prompt information.
[0081] S303: Return a successful prompt message.
[0082] S202: When the failure reason is the first other reason, an error prompt message is fed back.
[0083] The first other reason indicates a reason other than a branch transaction consistent with the current branch transaction.
[0084] It is understandable that when the cause of the failure is not a primary key conflict, the error prompt information is fed back. The purpose of feeding back the error prompt information is to help developers or operation and maintenance personnel quickly locate the problem and ensure that the system can correctly recover and handle the failure.
[0085] S103: If the current branch transaction is written successfully, the business logic corresponding to the current branch transaction is executed.
[0086] It can be understood that if the current branch transaction is successfully written into the idempotent information table, it means that the current branch transaction has not been executed yet, and the business logic corresponding to the current branch transaction continues to be executed.
[0087] Optionally, after step S103, the method further includes:
[0088] If the business logic is executed successfully, the current branch transaction is committed and a prompt message indicating successful execution is returned.
[0089] Among them, after the business logic is executed successfully, we can return a clear prompt message to inform the service caller that the current transaction has been successfully executed.
[0090] S104: If the business logic execution fails, roll back to the target branch transaction of the current branch transaction and return submission failure information.
[0091] The target branch transaction indicates all branch transactions that have been executed before the current branch transaction is executed.
[0092] It is understandable that if the business logic fails to execute, it will roll back to the target branch transaction of the current branch transaction. The rollback operation is to ensure the consistency and integrity of the system. In particular, when a branch transaction fails to execute, all related operations must be undone. By rolling back, you can restore to the state before the business logic is executed, avoiding data inconsistency or system errors caused by the success of some operations.
[0093] For example, a distributed transaction in an order system involves three operations: branch transaction 1, payment processing: deducting the user's balance, branch transaction 2, inventory deduction: reducing the inventory of the corresponding goods, branch transaction 3, order delivery: marking the order as delivered. When the user places an order, the payment system performs the deduction operation and successfully deducts the user's balance. Status: payment is successful, the balance is reduced, and the transaction continues to execute. After the payment is successful, the inventory system will deduct the number of goods purchased by the user to reduce the inventory. Status: inventory deduction is successful, and the transaction continues to execute. Order delivery: After both payment and inventory deduction are successful, the last operation is delivery. However, for some reason, an error occurred in the delivery system, such as a problem with inventory data, resulting in unsuccessful delivery. Rollback delivery operation: Due to the failure of the delivery operation, the system will roll back this operation (although the operation was not successfully submitted, it still needs to be ensured that it is revoked). Rollback inventory deduction: The inventory deduction is successful, but due to the failure of delivery, the system needs to roll back the inventory deduction operation, because the entire order processing should be an atomic operation, either all successful or all rolled back. Rollback payment processing: The payment operation also needs to be rolled back. Even if the payment is successful, due to the delivery failure, the system will cancel the deducted balance and restore to the state before the transaction started. Status: Delivery failed, the transaction needs to be rolled back.
[0094] S105: When a compensation transaction request for a target branch transaction sent according to the submission failure information is received, the database shard where the target branch transaction is located is determined according to the target branch transaction ID and the preset sharding rule, and the target branch transaction is opened on the database shard where the target branch transaction is located.
[0095] It can be understood that when a compensation transaction request for the target branch transaction sent by the service caller according to the failure information is received, the database shard where the target branch transaction is located is determined according to the target branch transaction ID and the preset sharding rules. The specific implementation process of determining the database shard where the target branch transaction is located can refer to step S101 accordingly and will not be repeated here.
[0096] Optionally, after step S105, when the target branch transaction fails to write the idempotent information table, in order to ensure eventual consistency and reduce the impact of the failure, it is necessary to write the compensating transaction branch transaction and execute the business logic of the compensating transaction branch transaction. Therefore, in another embodiment of the present application, a method for writing a compensating transaction branch transaction is provided, such as Figure 4 As shown, the following steps are included:
[0097] S401: When the target branch transaction fails to be written into the idempotent information table, the failure reason of the target branch transaction is obtained.
[0098] It should be noted that the specific implementation of step S401 may refer to step S201 accordingly, and will not be repeated here.
[0099] S402: When the failure reason is that there is a branch transaction that is consistent with the target branch transaction, the compensating transaction branch transaction in the compensating transaction request is written into the idempotent information table.
[0100] It is understandable that when the failure reason is that there is a branch transaction consistent with the target branch transaction (that is, there is a primary key conflict), it means that the target branch transaction has been executed at this time, so it is only necessary to write the compensation transaction branch transaction in the compensation transaction request into the idempotent information table.
[0101] Optionally, after step S402, if the write of the compensating transaction branch transaction fails, it is also necessary to analyze the cause of the write failure to ensure the atomicity and consistency of the transaction. Therefore, another embodiment of the application provides a method for analyzing the compensating transaction branch transaction, such as Figure 5 As shown, the following steps are included:
[0102] S501: When the writing of the compensation transaction branch transaction fails, the failure reason of the compensation transaction branch transaction is obtained.
[0103] It should be noted that the specific implementation of step S501 may refer to step S401 accordingly, and will not be described in detail here.
[0104] Optionally, after step S501, the method further includes:
[0105] When the failure reason is the second other reason, or when the write of the compensation transaction branch transaction fails, an error prompt message is fed back.
[0106] The second other reason indicates a reason other than a branch transaction consistent with the target branch transaction.
[0107] S502: When the failure reason is that there is a branch transaction that is consistent with the compensation transaction branch transaction, a success prompt message is returned.
[0108] It is understandable that when the failure reason is the existence of a branch transaction that is consistent with the compensation transaction branch transaction, our goal is to avoid repeated execution of the compensation operation and prevent unnecessary rollback or compensation operations. If the system detects that a compensation transaction has been executed, it should return a successful prompt message, indicating that the compensation operation has been completed and does not need to be executed again.
[0109] S403: When the compensation transaction branch transaction is written successfully, the business logic corresponding to the compensation transaction branch transaction is executed.
[0110] For example, suppose there is an e-commerce business process that includes the following operations: User places an order: create an order. Deduct inventory: update inventory. Successful payment: complete payment. If a problem occurs in the payment process, the system needs to perform a compensating operation to undo the operation that has been performed, such as undoing the inventory deduction or deleting the order. Compensating transaction branch transaction: If the payment operation fails, the system should execute a compensating transaction branch to cancel the deducted inventory and restore the inventory quantity. Business logic: After the compensating transaction branch transaction is successfully written, the actual compensating business logic will be to restore the inventory and avoid inventory reduction operations.
[0111] S404: If the business logic corresponding to the compensation transaction branch transaction is successfully executed, the compensation transaction transaction is submitted.
[0112] Among them, after the business logic corresponding to the compensation transaction branch transaction is successfully executed, the purpose of submitting the compensation transaction transaction is usually to ensure the consistency and reliability of the system and record the operation results so that the subsequent system can correctly restore the state or provide corresponding remedial measures.
[0113] S405: If the business logic corresponding to the compensation transaction branch transaction fails to execute, roll back to the target branch transaction.
[0114] Among them, if the business logic corresponding to the compensation transaction branch transaction fails to execute, a rollback operation is usually taken to maintain the consistency of the system and the correctness of the data.
[0115] S106: When the target branch transaction is successfully written into the idempotent information table, the compensating transaction branch transaction in the compensating transaction request is written into the idempotent information table.
[0116] It is understandable that when the target branch transaction is successfully written into the idempotence information table, the compensation transaction branch transaction in the compensation transaction request is written into the idempotence information table in order to ensure the idempotence of the compensation operation and avoid the same compensation operation being executed repeatedly.
[0117] S107: When the compensation transaction branch transaction is written successfully, the compensation transaction branch transaction is committed.
[0118] Among them, when the compensation transaction branch is written successfully, the operation of submitting the compensation transaction branch usually involves ensuring the consistency of the system and completing the normal submission of the compensation logic. The submission of the compensation transaction branch is one of the key steps in transaction management. Its purpose is to undo or correct the problems that occurred in the original transaction and ensure the final consistency of the overall system.
[0119] In addition, when the compensation transaction request of the target branch transaction arrives at the service provider before the target branch transaction, the compensation logic of the target branch transaction is not executed due to the empty rollback operation. At the same time, the target branch transaction record has been inserted into the idempotent information table when the compensation transaction request arrives at the service provider, so the target branch transaction record cannot be inserted into the data table. At this time, the system will not execute the forward transaction business logic of the target branch transaction, and then complete the anti-hanging operation.
[0120] In order to better Figure 1 For an explanation of the contents shown, see Figure 6 A schematic diagram of a global transaction and branch transaction calling process is shown, Figure 6 It includes the service caller and the service provider. The service caller first splits the global transaction into n branch transactions, and transmits the private domain and branch transaction ID through RPC calls. After the service provider receives the branch transaction ID, it calculates the sharding key through the sharding elements and sharding rules in the @idempotent annotation; starts the transaction in the database shard corresponding to the sharding key, inserts the transaction information into the idempotent control table, and executes the business logic after the transaction information is inserted. After the business is successfully executed, the transaction information is committed.
[0121] To summarize, if the business logic of the current branch transaction fails to execute, it will roll back to the previously executed branch transaction of the current branch transaction, and execute a compensation transaction request. Through the compensation operation, the part of the transaction that has been successfully executed is corrected or recovered, thereby ensuring the consistency of the distributed transaction.
[0122] like Figure 7As shown, it is a schematic diagram of the architecture of a distributed transaction processing device provided in an embodiment of the present application, and the processing device includes: a first determination unit 100, a first writing unit 200, an execution unit 300, a return unit 400, a second determination unit 500, a second writing unit 600 and a submission unit 700.
[0123] The first determination unit 100 is used to determine the database shard where the current branch transaction is located according to the current branch transaction ID and preset sharding rules in the submission request when receiving the submission request of the current branch transaction, and start the current branch transaction at the database shard where the current branch transaction is located.
[0124] The first writing unit 200 is used to write the current branch transaction into the idempotent information table if the current branch transaction is started and completed.
[0125] The execution unit 300 is used to execute the business logic corresponding to the current branch transaction if the current branch transaction is written successfully.
[0126] The return unit 400 is used to roll back to the target branch transaction of the current branch transaction and return the commit failure information if the business logic execution fails; the target branch transaction indicates all the branch transactions that have been executed before the execution of the current branch transaction.
[0127] The second determination unit 500 is used to determine the database shard where the target branch transaction is located according to the target branch transaction ID and the preset sharding rule when receiving the compensation transaction request of the target branch transaction sent according to the submission failure information, and start the target branch transaction at the database shard where the target branch transaction is located.
[0128] The second writing unit 600 is used to write the compensation transaction branch transaction in the compensation transaction request into the idempotence information table when the target branch transaction is successfully written into the idempotence information table.
[0129] The commit unit 700 is used to commit the compensating transaction branch transaction when the compensating transaction branch transaction is written successfully.
[0130] To summarize, if the business logic of the current branch transaction fails to execute, it will roll back to the previously executed branch transaction of the current branch transaction, and execute a compensation transaction request. Through the compensation operation, the part of the transaction that has been successfully executed is corrected or recovered, thereby ensuring the consistency of the distributed transaction.
[0131] Preferably, combined Figure 7 The processing device also includes: an acquisition unit and a feedback unit.
[0132] An acquisition unit, used for acquiring the failure reason of the current branch transaction if the writing of the current branch transaction fails;
[0133] The feedback unit is used to feedback error prompt information when the failure reason is the first other reason; the first other reason indicates a reason other than a branch transaction consistent with the current branch transaction.
[0134] Preferably, combined Figure 7 According to the content shown, the processing device also includes: a query unit, a first information returning unit and a second information returning unit.
[0135] The query unit is used to query whether there is a compensation transaction corresponding to the current branch transaction ID in the idempotence information table when the failure reason is that there is a branch transaction consistent with the current branch transaction.
[0136] The first information returning unit is used to return a failure prompt message if there is a compensation transaction corresponding to the current branch transaction ID in the idempotence information table.
[0137] The second information returning unit is used to return a successful prompt message if there is no compensation transaction corresponding to the current branch transaction ID in the idempotent information table.
[0138] Preferably, combined Figure 7 As shown in the content, the processing device also includes: a third information returning unit, which is used to commit the current branch transaction if the business logic is executed successfully, and return prompt information of successful execution.
[0139] Preferably, combined Figure 7 As shown in the content, the processing device also includes: a cause acquisition unit, a third writing unit, an execution unit, an information submission unit and a rollback unit.
[0140] A reason acquisition unit, used for acquiring the failure reason of the target branch transaction when the target branch transaction fails to write the idempotent information table;
[0141] A third writing unit is used to write the compensation transaction branch transaction in the compensation transaction request into the idempotent information table when the failure reason is that there is a branch transaction that is consistent with the target branch transaction;
[0142] An execution unit, configured to execute the business logic corresponding to the compensation transaction branch transaction after the compensation transaction branch transaction is successfully written;
[0143] An information submission unit, used to submit the compensation transaction if the business logic corresponding to the compensation transaction branch transaction is successfully executed;
[0144] The rollback unit is used to roll back to the target branch transaction if the business logic corresponding to the compensation transaction branch transaction fails to execute.
[0145] Preferably, combined Figure 7According to the content shown, the processing device also includes: a data acquisition unit and a fourth information returning unit.
[0146] The data acquisition unit is used to acquire the failure reason of the compensation transaction branch transaction when the writing of the compensation transaction branch transaction fails.
[0147] The fourth information returning unit is used to return successful prompt information when the failure reason is the existence of a branch transaction that is consistent with the compensation transaction branch transaction.
[0148] Preferably, combined Figure 7 As shown in the content, the processing device also includes: an information feedback unit, which is used to feedback error prompt information when the failure cause is a second other reason, or when the compensating transaction branch transaction fails to be written; wherein the second other reason indicates a reason other than a branch transaction consistent with the target branch transaction.
[0149] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can refer to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system or system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiment. The system and system embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative work.
[0150] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.
[0151] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A distributed transaction processing method, characterized in that: include: When receiving a commit request for the current branch transaction, determining the database shard where the current branch transaction is located according to the current branch transaction ID in the commit request and the preset sharding rule, and opening the current branch transaction at the database shard where the current branch transaction is located; If the current branch transaction is started and completed, write the current branch transaction into the idempotent information table; If the current branch transaction is written successfully, the business logic corresponding to the current branch transaction is executed; If the business logic fails to execute, roll back to the target branch transaction of the current branch transaction and return submission failure information; The target branch transaction indicates all branch transactions that have been executed before the current branch transaction is executed; When receiving a compensation transaction request of the target branch transaction sent according to the submission failure information, determining the database shard where the target branch transaction is located according to the target branch transaction ID and the preset sharding rule, and opening the target branch transaction at the database shard where the target branch transaction is located; When the target branch transaction is successfully written into the idempotent information table, writing the compensation transaction branch transaction in the compensation transaction request into the idempotent information table; When the compensating transaction branch transaction is written successfully, the compensating transaction branch transaction is committed.
2. The method according to claim 1, characterized in that: Also includes: If the writing of the current branch transaction fails, obtaining the failure reason of the current branch transaction; When the failure reason is a first other reason, an error prompt message is fed back; the first other reason indicates a reason other than a branch transaction consistent with the current branch transaction.
3. The method according to claim 2, characterized in that Also includes: When the failure reason is that there is a branch transaction that is consistent with the current branch transaction, query the idempotence information table to see whether there is a compensation transaction corresponding to the current branch transaction ID; If there is a compensation transaction corresponding to the current branch transaction ID in the idempotence information table, a failure prompt message is returned; If there is no compensating transaction corresponding to the current branch transaction ID in the idempotent information table, a successful prompt message is returned.
4. The method according to claim 1, characterized in that: Also includes: If the business logic is executed successfully, the current branch transaction is committed and prompt information of successful execution is returned.
5. The method according to claim 1, characterized in that Also includes: When the target branch transaction fails to be written into the idempotent information table, obtaining the failure reason of the target branch transaction; When the failure reason is that there is a branch transaction that is consistent with the target branch transaction, writing the compensation transaction branch transaction in the compensation transaction request into the idempotent information table; When the compensation transaction branch transaction is written successfully, executing the business logic corresponding to the compensation transaction branch transaction; If the business logic corresponding to the compensation transaction branch transaction is executed successfully, submit the compensation transaction transaction; If the business logic corresponding to the compensation transaction branch transaction fails to execute, it is rolled back to the target branch transaction.
6. The method according to claim 5, characterized in that Also includes: When the writing of the compensation transaction branch transaction fails, obtaining the failure reason of the compensation transaction branch transaction; When the failure reason is that there is a branch transaction that is consistent with the compensation transaction branch transaction, a success prompt message is returned.
7. The method according to claim 5, characterized in that Also includes: When the failure reason is a second other reason, or when the writing of the compensation transaction branch transaction fails, error prompt information is fed back; wherein the second other reason indicates a reason other than a branch transaction consistent with the target branch transaction.
8. A distributed transaction processing device, characterized in that: include: A first determining unit is configured to, when receiving a commit request for a current branch transaction, determine the database shard where the current branch transaction is located according to the current branch transaction ID in the commit request and a preset sharding rule, and start the current branch transaction at the database shard where the current branch transaction is located; A first writing unit, configured to write the current branch transaction into an idempotent information table if the current branch transaction is started and completed; An execution unit, configured to execute the business logic corresponding to the current branch transaction if the current branch transaction is written successfully; A return unit, configured to roll back to the target branch transaction of the current branch transaction and return submission failure information if the business logic fails to execute; The target branch transaction indicates all branch transactions that have been executed before the current branch transaction is executed; A second determining unit is configured to, when receiving a compensation transaction request of the target branch transaction sent according to the submission failure information, determine the database shard where the target branch transaction is located according to the target branch transaction ID and a preset sharding rule, and start the target branch transaction at the database shard where the target branch transaction is located; a second writing unit, configured to write the compensation transaction branch transaction in the compensation transaction request into the idempotence information table when the target branch transaction is successfully written into the idempotence information table; The commit unit is used to commit the compensating transaction branch transaction when the compensating transaction branch transaction is written successfully.
9. The device according to claim 8, characterized in that Also includes: an acquisition unit, configured to acquire a failure reason of the current branch transaction if the writing of the current branch transaction fails; A feedback unit is used to feedback error prompt information when the failure reason is a first other reason; the first other reason indicates a reason other than a branch transaction consistent with the current branch transaction.
10. The device according to claim 9, characterized in that Also includes: A query unit, configured to query whether there is a compensation transaction corresponding to the current branch transaction ID in the idempotence information table when the failure reason is that there is a branch transaction consistent with the current branch transaction; A first information returning unit, configured to return a failure prompt message if a compensation transaction corresponding to the current branch transaction ID exists in the idempotent information table; The second information returning unit is used to return a successful prompt message if there is no compensation transaction corresponding to the current branch transaction ID in the idempotent information table.