Transaction rollback method and device, electronic equipment, medium and product

Abstract

The embodiment of the invention provides a transaction rollback method and device, electronic equipment, a medium and a product, and relates to the field of distribution. The method comprises the following steps: acquiring a to-be-executed transaction, and decomposing the to-be-executed transaction into a plurality of fragments; when execution of the to-be-executed transaction is abnormal, whether execution of each fragment is actually completed or not is verified according to whether submission records of the fragments exist in a database log or not; if the fragments which are not executed completely exist, determining a corresponding compensation strategy according to the fragment execution condition of the to-be-executed transaction; and rolling back the transaction to be executed according to the compensation strategy. The method is used for improving the reliability of transaction rollback.

Description

Technical Field

[0001] This application relates to the field of distributed systems, and more particularly to a transaction rollback method, apparatus, electronic device, medium, and product. Background Technology

[0002] Atomicity is a core concept in computer science that describes the characteristics of transaction processing. It means that an operation or a series of operations must either all succeed or none of them must succeed. It cannot be partially completed or interrupted.

[0003] Since database logs are generated during transaction execution, related technologies can determine the actual execution status of transactions based on these logs, and roll back transactions if they fail to execute successfully, thus ensuring the atomicity of transactions.

[0004] However, this rollback method requires a complete log chain. When the database's disk or other storage is damaged, the actual execution status of the transaction cannot be determined, and the rollback mechanism fails. Summary of the Invention

[0005] This application provides a transaction rollback method, apparatus, electronic device, medium, and product for reliably performing transaction rollback.

[0006] Firstly, this application provides a transaction rollback method, including:

[0007] Obtain the transaction to be executed, and decompose the transaction to be executed into multiple fragments;

[0008] When the pending transaction fails to execute, check whether each shard has actually been completed by checking whether there is a shard commit record in the database log.

[0009] If there are unexecuted shards, a corresponding compensation strategy is determined based on the shard execution status of the pending transactions.

[0010] According to the compensation strategy, the pending transaction is rolled back.

[0011] Secondly, this application provides a transaction rollback apparatus, comprising:

[0012] The acquisition module is used to acquire transactions to be executed and decompose the transactions to be executed into multiple fragments;

[0013] The verification module is used to verify whether each shard has actually been completed when the execution of the transaction to be executed is abnormal, based on whether there is a shard commit record in the database log.

[0014] The determination module is used to determine the corresponding compensation strategy based on the shard execution status of the transaction to be executed if there are shards that have not been completed.

[0015] The rollback module is used to roll back the transaction to be executed according to the compensation strategy.

[0016] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0017] The memory stores computer-executed instructions;

[0018] The processor executes computer execution instructions stored in the memory to implement the method described above.

[0019] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described above.

[0020] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described above.

[0021] The transaction rollback method, apparatus, electronic device, medium, and product provided in this application decompose the transaction to be executed into multiple fragments, breaking down atomic transactions into multiple independently traceable operation units. By verifying the actual execution status of each fragment through database logs, the actual subdivided execution status of the entire transaction to be executed can be better reflected, ensuring accurate identification of abnormal fragments. Based on the fragment execution status of the transaction to be executed, a corresponding compensation strategy is matched, and rollback is performed based on compensation measurements. This allows for clear and accurate rollback even when the transaction to be executed fails, ensuring the atomicity of the transaction. Furthermore, even when the database logs are incomplete, fragments that have partially completed or not completed can still be quickly identified based on the residual logs, effectively locating the fragment execution status of the transaction to be executed and improving the reliability of transaction rollback. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] Figure 1 A flowchart illustrating the transaction rollback method provided in this application embodiment;

[0024] Figure 2 This is a schematic diagram of the transaction rollback device provided in an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0026] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0029] It should be noted that the transaction rollback method, apparatus, electronic device, medium and product provided in this application can be used in the distributed field, or in any field other than distributed fields. The application field of the transaction rollback method, apparatus, electronic device, medium and product in this application is not limited.

[0030] Atomicity is a core concept in computer science that describes the characteristics of transaction processing. It means that an operation or a series of operations must either all succeed or none of them must succeed. It cannot be partially completed or interrupted.

[0031] Since database logs are generated during transaction execution, related technologies can determine the actual execution status of transactions based on these logs, and roll back transactions if they fail to execute successfully, thus ensuring the atomicity of transactions.

[0032] However, this rollback method requires a complete log chain. When the database's disk or other storage is damaged, the actual execution status of the transaction cannot be determined, and the rollback mechanism fails.

[0033] The transaction rollback method, apparatus, electronic device, medium, and product provided in this application are intended to solve the above-mentioned technical problems of the prior art.

[0034] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0035] Figure 1 This is a flowchart illustrating the transaction rollback method provided in an embodiment of this application. Figure 1 As shown, the method includes:

[0036] S101. Obtain the transaction to be executed and decompose it into multiple fragments.

[0037] In practical implementation, atomic transactions can be broken down into multiple independently traceable operation units, i.e., multiple shards. During shard execution, the database logs all operations, including insert, update, and delete operations. This log information is used to recover data in the event of a system crash. When a transaction executes a commit command, the database writes this log information to persistent storage to ensure data durability and generates a commit record.

[0038] For example, a transaction T can be decomposed into a fragmented sequence: T={TX1, TX2, ..., TXn}.

[0039] S102. When an execution exception occurs during the execution of a pending transaction, check whether each shard has actually been completed based on whether there is a shard commit record in the database log.

[0040] Optionally, exceptions during the execution of a pending transaction can be caught by the transaction's business code or result in validation failure. For example, in a financial payment system, when insufficient balance, duplicate order submission, or timeout failure occurs, the business code will catch the exception or detect validation failure.

[0041] Optionally, an exception to the pending transaction execution can be a cross-node failure in a distributed system. For example, in an interbank transfer, if the receiving node goes down, the payment may be successfully deducted, but the recipient may not receive the funds.

[0042] Optionally, if there are unexecuted shards, it indicates that the transaction to be executed has not actually been executed or has been partially executed. In this case, it is necessary to roll back the transaction to be executed.

[0043] Optionally, if all shards have actually been executed, it indicates that the transaction to be executed has actually been completed, and there is no need to roll back the transaction to be executed.

[0044] Optionally, since the transaction to be executed is decomposed into multiple shards, the determination of the execution status of the transaction to be executed does not depend on the complete database log. Even when the database log is incomplete, the execution status of some shards can still be determined based on the shard commit records saved in the residual database log, and the corresponding rollback method can be determined to avoid the complete failure of the rollback mechanism and effectively improve the reliability of transaction rollback.

[0045] S103. If there are unexecuted shards, determine the corresponding compensation strategy based on the shard execution status of the pending transactions.

[0046] For example, the compensation strategy is used to indicate the specific implementation of transaction rollback.

[0047] In practical implementation, the compensation strategy varies depending on the execution status of each transaction's shards. For example, if shards TX1 and TX2 in transaction T are completed but other shards are not, compensation strategy 1 is chosen; if shards TX1 to TX4 in transaction T are completed but other shards are not, compensation strategy 2 is chosen. Flexibly selecting the appropriate compensation strategy based on the shard execution status of the transaction ensures accurate and reliable transaction rollback.

[0048] S104. Roll back the transaction to be executed according to the compensation strategy.

[0049] For example, the compensation strategy may include an inverse operation function. By executing the inverse operation function, the transaction to be executed can be rolled back.

[0050] In this embodiment, the transaction to be executed is decomposed into multiple shards, which breaks down the atomic transaction into multiple independently traceable operation units. Verifying the actual execution status of each shard through database logs better reflects the actual detailed execution status of the entire transaction, ensuring accurate identification of abnormal shards. Based on the shard execution status of the transaction, a corresponding compensation strategy is matched, and rollback is performed based on the compensation measurement. This allows for clear and accurate rollback when the transaction fails to execute, ensuring the atomicity of the transaction. Furthermore, even when the database log is incomplete, it is still possible to quickly identify partially completed or incomplete shards based on the residual logs, effectively locating the shard execution status of the transaction and improving the reliability of transaction rollback.

[0051] In one possible implementation, different shards are identified differently; based on whether there are shard commit records in the database log, it is verified whether each shard has actually completed execution, including:

[0052] For the first shard, based on the identifier of the first shard, search the database log to see if there is a commit record for the first shard;

[0053] If it exists, then the first slice is considered to have completed execution;

[0054] If it does not exist, then the first slice is determined not to have completed execution.

[0055] In practical implementation, when decomposing a transaction into multiple shards, a unique shard identifier can be generated for each shard, such as a unique shard ID. During shard execution, the database generates logs corresponding to each shard based on its identifier. Therefore, the commit record of the corresponding shard can be retrieved from the database log based on its identifier, accurately determining the completion status of each shard. This approach is independent of complete database logs; even when database logs are incomplete, residual logs can be quickly identified to determine the execution status of partial shards, effectively improving the reliability of transaction rollback.

[0056] Furthermore, the reliability of fragmentation completion verification can be improved through a dual-track verification method. In some embodiments, the method further includes:

[0057] For the first shard, before the first shard is executed, a target hash value corresponding to the first shard is generated. The target hash value is the hash value of the data page after the first shard is actually executed successfully. The first shard is used to operate on the data page.

[0058] When the database log is corrupted, determine whether the first shard has actually been completed based on the current hash value and the target hash value corresponding to the first shard.

[0059] In practical implementation, after decomposing the transaction to be executed into multiple shards, a target execution snapshot for each shard can be generated. This involves pre-generating the hash value of each shard's data page operation success using a hash algorithm, which serves as the target hash value. When the database log is completely or partially corrupted, it's impossible to determine the execution status of each shard solely based on the database log. In this case, a hash value verification mechanism can be triggered. By comparing the current data page hash value of each shard with the target hash value, the consistency can be determined to see if the first shard has actually completed execution. This hash value verification mechanism effectively supplements the log verification mechanism, reliably determining the shard execution status when the database log is corrupted, thus significantly improving the reliability of transaction rollback.

[0060] Optionally, the generated target hash values ​​can be stored in a lightweight storage pool. The lightweight storage pool is a database-independent storage service dedicated to storing the hash fingerprints of data pages.

[0061] In one possible implementation, determining whether the first slice has actually completed execution is based on the current hash value and the target hash value corresponding to the first slice, including:

[0062] If the difference between the current hash value and the target hash value is greater than the threshold, it is determined that the first shard has not actually been completed.

[0063] Otherwise, the first segment is deemed to have been actually executed.

[0064] In the specific implementation, when comparing the consistency between the current hash value and the target hash value of a shard, a certain margin can be left. That is, a shard is only considered not to have actually completed execution and is marked as a dirty shard when the difference between the current hash value and the target hash value of the shard is greater than a threshold, rather than being considered not to have actually completed execution when the current hash value is different from the target hash value. This allows for accurate and reliable determination of the execution status of the shard.

[0065] For example, the threshold can be set according to actual needs, such as 5%.

[0066] In some technologies, the compensation strategy required for transaction rollback needs to be pre-coded and generated manually. This method of generating compensation strategies cannot adapt to dynamic business scenarios. When business changes occur, the compensation strategy needs to be reconstructed, which is inflexible and inefficient.

[0067] This application embodiment, by incorporating an artificial intelligence model, can dynamically generate compensation strategies. In some embodiments, determining the corresponding compensation strategy based on the sharding execution status of the transaction to be executed includes:

[0068] The fragmented execution status of the pending transaction is input into the artificial intelligence model. The artificial intelligence model analyzes historical cases in the knowledge graph to obtain the compensation strategy output by the artificial intelligence model. The compensation strategy includes the inverse operation function corresponding to the fragmented execution status of the pending transaction.

[0069] In practice, after inputting the sharded execution status of the transaction to be executed into the AI ​​model, the model analyzes the current scenario and examines historical cases of similar or identical scenarios in the knowledge graph to dynamically generate a compensation strategy. For example, if the AI ​​model analyzes the current scenario as a failed interbank transfer based on the sharded execution status of the transaction to be executed, and learns from similar historical cases, it generates a compensation strategy of rolling back the deduction data and sending a deduction failure notification to the user.

[0070] Optionally, the knowledge graph can be a graph-structured database that stores exception types, transaction dependencies, and historical compensation strategies.

[0071] For example, the compensation strategy includes the inverse operation function corresponding to the sharded execution status of the transaction to be executed. By executing the inverse operation, the transaction to be executed can be rolled back.

[0072] When the business logic remains unchanged, the compensation strategy corresponding to the sharded execution status of the same pending transaction only needs to be generated once. In one possible implementation, before inputting the sharded execution status of the pending transaction into the AI ​​model, the following steps are also included:

[0073] Based on the sharding execution status of the pending transactions, determine whether there are historically generated compensation strategies. If there are historically generated compensation strategies, then use the historically generated compensation strategy as the corresponding compensation strategy.

[0074] The fragmented execution status of the pending transactions is input into the artificial intelligence model, including:

[0075] If there is no historical compensation strategy, the fragmented execution status of the pending transactions will be input into the artificial intelligence model.

[0076] In the specific implementation, after obtaining the sharded execution status of the transaction to be executed, it first determines whether a historically generated compensation strategy exists. This compensation strategy corresponds to the same sharded execution status of transactions of the same type. If a historically generated compensation strategy exists, it can be directly used as the compensation strategy corresponding to the current sharded execution status of the transaction to be executed, thereby quickly achieving compensation strategy matching and improving transaction rollback efficiency. If no historically generated compensation strategy exists, the sharded execution status of the transaction to be executed is input into the artificial intelligence model, which generates a compensation strategy. The generated compensation strategy and the corresponding sharded execution status of the transaction are recorded, thus avoiding the repeated generation of compensation strategies after the initial generation.

[0077] When rolling back pending transactions, queuing may be required. In one possible implementation, the number of pending transactions to be rolled back is one or more, and the rollback of these transactions is performed according to a compensation strategy, including:

[0078] Determine the detailed compensation operations for the compensation strategy of all pending transactions; execute each detailed compensation operation according to the preset priority.

[0079] In practical implementation, when resources for rolling back pending transactions are limited, compensation strategies for all pending transactions to be rolled back can be obtained. Each compensation strategy includes at least one sub-compensation operation, and each sub-compensation operation can be implemented by at least one inverse operation function. These sub-compensation operations are executed in priority order to ensure orderly and reliable transaction rollback. For example, assuming the current scenario is a failed cross-bank payment, the corresponding sub-compensation operations include rolling back the deduction data and sending a payment failure notification to the user. In this case, the execution priority of rolling back the deduction data can be higher than that of sending the payment failure notification to the user.

[0080] Optionally, an artificial intelligence model can be used to prioritize the subdivision compensation operations and generate a priority list.

[0081] The above is the transaction rollback method provided in the embodiments of this application. Figure 2 This is a schematic diagram of the transaction rollback device provided in an embodiment of this application. Figure 2 As shown, the method includes:

[0082] The acquisition module 21 is used to acquire transactions to be executed and decompose them into multiple fragments.

[0083] The verification module 22 is used to verify whether each shard has actually been completed when an execution of a pending transaction fails, based on whether there is a shard commit record in the database log.

[0084] The determination module 23 is used to determine the corresponding compensation strategy based on the shard execution status of the transaction to be executed if there are shards that have not been completed.

[0085] Rollback module 24 is used to roll back the transaction to be executed according to the compensation strategy.

[0086] It should be noted that the transaction rollback device is used to execute the transaction rollback method as described above. For the specific implementation method, please refer to the method embodiment provided in this application, which will not be repeated here.

[0087] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 3 As shown, the electronic device includes:

[0088] The electronic device includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, memory 292, and communication interface 293 can communicate with each other via the bus 294. The communication interface 293 can be used for information transmission. The processor 291 can invoke logical instructions stored in the memory 292 to execute the methods of the above embodiments.

[0089] Furthermore, the logic instructions in the aforementioned memory 292 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0090] The memory 292, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, thereby implementing the methods in the above-described method embodiments.

[0091] The memory 292 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 292 may include high-speed random access memory and may also include non-volatile memory.

[0092] This application provides a non-transitory computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods described in the foregoing embodiments.

[0093] This application provides a computer program product, including a computer program that, when executed by a processor, implements the methods provided in any of the embodiments described above.

[0094] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0095] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0096] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0097] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0098] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0099] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0100] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0101] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0102] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A transaction rollback method, characterized by, The method comprises the following steps: acquiring a to-be-executed transaction, and decomposing the to-be-executed transaction into a plurality of shards; when an exception occurs in execution of the to-be-executed transaction, checking whether each shard is actually executed according to whether there is a submission record of the shard in a database log; if there is a shard that is not executed, determining a corresponding compensation strategy according to the execution of the shards of the to-be-executed transaction; and rolling back the to-be-executed transaction according to the compensation strategy.

2. The method of claim 1, wherein, The identifiers of different shards are different, and the checking whether each shard is actually executed according to whether there is a submission record of the shard in a database log comprises the following steps: for a first shard, searching whether there is a submission record of the first shard in the database log according to the identifier of the first shard; if there is, determining that the first shard is executed; if there is not, determining that the first shard is not executed.

3. The method of claim 1, wherein, The method further comprises the following steps: for a first shard, generating a target hash value corresponding to the first shard before the first shard is executed, the target hash value being a hash value of a data page after the first shard is actually executed successfully, and the first shard being used to operate on the data page; and judging whether the first shard is actually executed according to the current hash value corresponding to the first shard and the target hash value when the database log is damaged.

4. The method of claim 3, wherein, The judging whether the first shard is actually executed according to the current hash value corresponding to the first shard and the target hash value comprises the following steps: if the difference between the current hash value and the target hash value is greater than a threshold, determining that the first shard is not actually executed; otherwise, determining that the first shard is actually executed.

5. The method according to any one of claims 1 to 4, characterized in that, The determining a corresponding compensation strategy according to the execution of the shards of the to-be-executed transaction comprises the following steps: inputting the execution of the shards of the to-be-executed transaction into an artificial intelligence model, analyzing historical cases in a knowledge graph through the artificial intelligence model, and obtaining a compensation strategy output by the artificial intelligence model, the compensation strategy comprising an inverse operation function corresponding to the execution of the shards of the to-be-executed transaction.

6. The method of claim 5, wherein, Before the inputting the execution of the shards of the to-be-executed transaction into the artificial intelligence model, the method further comprises the following steps: judging whether there is a historically generated compensation strategy according to the execution of the shards of the to-be-executed transaction, and if there is a historically generated compensation strategy, taking the historically generated compensation strategy as the corresponding compensation strategy; and the inputting the execution of the shards of the to-be-executed transaction into the artificial intelligence model comprises the following steps: if there is not a historically generated compensation strategy, inputting the execution of the shards of the to-be-executed transaction into the artificial intelligence model.

7. The method of claim 5, wherein, The number of to-be-rolled-back to-be-executed transactions is one or more, and the rolling back the to-be-executed transaction according to the compensation strategy comprises the following steps: determining a subdivided compensation operation of the compensation strategies of all the to-be-executed transactions; and executing each subdivided compensation operation according to a preset priority order.

8. An apparatus for transaction rollback, comprising: The method comprises the following steps: an acquiring module, configured to acquire a to-be-executed transaction, and decompose the to-be-executed transaction into a plurality of shards; The checking module is configured to, when the to-be-executed transaction executes abnormally, check whether each shard is actually executed completely according to whether there is a shard commit record in the database log; The determining module is configured to, if there is a shard that is not executed completely, determine a corresponding compensation strategy according to shard execution of the to-be-executed transaction; The rollback module is configured to roll back the to-be-executed transaction according to the compensation strategy.

9. An electronic device, comprising: Comprise: A processor and a memory connected with the processor in communication; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method of any one of claims 1 to 7.

11. A computer program product, characterised in that, The computer program is executed by the processor to implement the method of any one of claims 1 to 7.

Images