Distributed transaction consistency execution method, device, equipment, medium and product
By assigning a unique transaction identifier to distributed transactions and storing it in the blockchain network, the problem of data inconsistency caused by partial commit failures in distributed systems is solved, achieving atomicity and consistency of distributed transactions and reducing development and maintenance costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- INDUSTRIAL AND COMMERCIAL BANK OF CHINA
- Filing Date
- 2026-01-13
- Publication Date
- 2026-06-05
AI Technical Summary
Existing technologies are difficult to effectively solve the data inconsistency problem caused by partial commit failures in distributed transactions in distributed systems. They are complex to develop and costly to maintain, and are prone to data inconsistency due to logical vulnerabilities.
A unique transaction identifier is assigned to each distributed transaction, and a corresponding reverse operation instruction is generated and stored in the blockchain network. When a partial commit fails, the reverse operation instruction is retrieved from the blockchain network using the unique transaction identifier to perform a rollback operation, thus ensuring the consistency of distributed transactions.
It achieves data consistency in distributed transactions under complex environments, significantly reduces development complexity and maintenance costs, and provides strong support for the stable operation of distributed systems.
Smart Images
Figure CN122152829A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of distributed technology, and in particular to a distributed transaction consistency execution method, apparatus, device, medium and product. Background Technology
[0002] In distributed systems such as microservice architectures, cross-organizational collaborations, or cross-regional deployments, transactions for a single business typically involve multiple service nodes or database instances. Due to factors such as network latency, node downtime, resource contention, or concurrency conflicts, such distributed transactions are highly susceptible to situations where some operations succeed while others fail, leading to inconsistent system data states and seriously threatening the integrity of business operations in high-reliability scenarios such as finance and regulation.
[0003] In existing technologies, traditional mainframe platforms typically rely on the global transaction coordination mechanism built into the customer information control system to achieve strong consistency across resources. Open platforms, on the other hand, primarily depend on the COMMIT statement of relational databases, combined with two-phase commit or local transaction rollback mechanisms, to achieve atomicity with either full success or full failure.
[0004] However, existing methods are complex to develop, costly to maintain, and prone to data inconsistency due to logical flaws. Summary of the Invention
[0005] This application provides a distributed transaction consistency execution method, apparatus, device, medium, and product. It assigns a unique transaction identifier to each distributed transaction and pre-generates a reverse operation instruction that strictly corresponds to its transaction operation. Then, the reverse operation instruction is associated with the unique transaction identifier and persistently stored in a blockchain network with immutable characteristics. When a partial commit failure of a distributed transaction is detected, the corresponding reverse operation instruction is retrieved from the blockchain network based on the unique transaction identifier, and the reverse operation instruction is automatically executed to accurately roll back the committed data changes. This achieves end-to-end transaction consistency assurance and effectively reduces development complexity and maintenance costs.
[0006] Firstly, this application provides a distributed transaction consistency execution method, including:
[0007] Receive transaction requests initiated by users; these requests are used to request the execution of distributed transactions.
[0008] Based on the transaction request, generate a unique transaction identifier to identify the distributed transaction;
[0009] Based on the distributed transaction and the unique transaction identifier, generate the reverse operation instruction corresponding to the transaction operation of the distributed transaction;
[0010] A unique transaction identifier is associated with and stored in the blockchain network along with the reverse operation instruction;
[0011] Execute distributed transactions, and when a partial commit of a distributed transaction fails, retrieve the reverse operation instructions associated with the unique transaction identifier from the blockchain network based on the unique transaction identifier;
[0012] Execute the reverse operation instruction to achieve the rollback operation of the distributed transaction.
[0013] Secondly, this application provides a distributed transaction consistency execution device, comprising: a receiving module, a generating module, a storage module, and an execution module;
[0014] The receiving module is used to receive transaction requests initiated by users, which are used to request the execution of distributed transactions.
[0015] The generation module is used to generate a unique transaction identifier to identify a distributed transaction based on the transaction request.
[0016] The generation module is also used to generate reverse operation instructions corresponding to the transaction operations of the distributed transaction based on the distributed transaction and the unique transaction identifier.
[0017] The storage module is used to associate a unique transaction identifier with the reverse operation instruction and store it in the blockchain network;
[0018] The execution module is used to execute distributed transactions and, when a partial commit of a distributed transaction fails, to extract the reverse operation instructions associated with the unique transaction identifier from the blockchain network.
[0019] The execution module is also used to execute reverse operation instructions to implement the rollback operation of distributed transactions.
[0020] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;
[0021] The memory stores the instructions that the computer executes;
[0022] The processor executes computer execution instructions stored in memory to implement a distributed transaction consistency execution method according to the first aspect of the invention.
[0023] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement a distributed transaction consistency execution method according to the first aspect of the invention.
[0024] Fifthly, this application provides a computer program product, including a computer program, which, when executed by a processor, is used to implement a distributed transaction consistency execution method according to the first aspect of the invention.
[0025] This application provides a distributed transaction consistency execution method, apparatus, device, medium, and product, comprising: first, receiving a transaction request initiated by a user, the transaction request being used to request the execution of a distributed transaction; next, generating a unique transaction identifier to identify the distributed transaction based on the transaction request; then, generating a reverse operation instruction corresponding to the transaction operation of the distributed transaction based on the distributed transaction and the unique transaction identifier; subsequently, storing the unique transaction identifier and the reverse operation instruction in association in a blockchain network; then, executing the distributed transaction, and when a partial commit of the distributed transaction fails, retrieving the reverse operation instruction associated with the unique transaction identifier from the blockchain network based on the unique transaction identifier; finally, executing the reverse operation instruction to achieve a rollback operation of the distributed transaction. This achieves the following technical effect: during the execution of a distributed transaction, if a partial commit fails, the reverse operation instruction associated with the pre-allocated unique transaction identifier is accurately retrieved from the blockchain network. By executing these reverse operation instructions, the successfully committed partial operations are rolled back, restoring the entire distributed transaction to its state before the transaction began, thereby achieving the atomicity and consistency of the distributed transaction. This approach effectively ensures data consistency in distributed transactions under complex environments, while significantly reducing development complexity and maintenance costs, providing strong support for the stable operation of distributed systems. It effectively solves the data inconsistency problem caused by partial commit failures in distributed scenarios, while reducing development complexity. By assigning a unique transaction identifier to each distributed transaction, which serves as a unique identity throughout the entire lifecycle of the distributed transaction, specific transactions can be accurately located and tracked. By associating the unique transaction identifier with the reverse operation instruction corresponding to the transaction operation of the distributed transaction, and storing the associated information in the blockchain network, the integrity and reliability of the stored information are ensured, providing a solid data foundation for subsequent transaction rollback operations. Attached Figure Description
[0026] 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.
[0027] Figure 1 This is a schematic diagram illustrating an application scenario of a distributed transaction consistency execution method provided in an embodiment of this application.
[0028] Figure 2 This is a flowchart illustrating a distributed transaction consistency execution method provided in an embodiment of this application.
[0029] Figure 3 This is a schematic diagram of the structure of a distributed transaction consistency execution device provided in an embodiment of this application.
[0030] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0031] 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
[0032] 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.
[0033] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply difference. It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being better or more advantageous than other embodiments or design schemes. Specifically, the use of "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.
[0034] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the distributed transaction consistency execution method provided in the embodiments of this application is merely an example; a distributed transaction consistency execution method may include more or fewer elements.
[0035] It should be noted that the distributed transaction consistency execution method, apparatus, device, medium and product provided in this application can be used in the field of distributed technology, or in any field other than the field of distributed technology. The application field of the distributed transaction consistency execution method, apparatus, device, medium and product in this application is not limited.
[0036] Distributed systems are widely used in numerous scenarios, including microservice architectures, cross-organizational collaboration, and cross-regional deployments. Within distributed systems, transaction processing faces many complex and severe challenges. Due to uncontrollable factors such as network latency, node failures, and concurrency conflicts, distributed transactions are highly susceptible to situations where some operations succeed while others fail, leading to serious data inconsistencies and severely damaging normal business operations and data accuracy.
[0037] Currently, different platforms employ different technical solutions for distributed transaction management. In the mainframe platform domain, the customer information control system in mainframe system software is widely used to manage online distributed transactions. This system ensures that single-node transactions achieve strong consistency requirements through a series of complex mechanisms, thus guaranteeing the reliability of transaction processing to a certain extent. However, this system primarily focuses on single-node transactions and has limitations in coordinating and ensuring consistency of multi-node transactions in a distributed environment. Furthermore, its architecture and implementation are relatively complex, resulting in high development and maintenance costs.
[0038] In open platforms, the atomicity of distributed transaction commits is typically achieved using the database's COMMIT statement, requiring all operations to either all succeed or all fail. While this database-commit-based approach can guarantee atomicity to some extent, its limitations become increasingly apparent in complex distributed scenarios. Firstly, as business logic becomes more complex, the number of database operations and external system calls involved in transactions increases, making it difficult to comprehensively cover all potential problems by relying solely on database commit statements. Secondly, this approach is highly complex to develop, requiring developers to have a deep understanding and precise control over database transaction mechanisms, which can easily lead to data inconsistencies due to logical flaws. Moreover, as distributed systems continue to expand and evolve, maintaining and optimizing these database-commit-based transaction processing logics requires significant human and material resources, resulting in substantial maintenance costs.
[0039] Therefore, existing distributed transaction execution methods suffer from high development complexity, high maintenance costs, and susceptibility to data inconsistencies due to logical vulnerabilities when dealing with complex and ever-changing distributed system environments, failing to meet the ever-increasing business demands and system stability requirements. Thus, there is an urgent need for a more efficient, reliable, and easy-to-develop and maintain distributed transaction consistency execution method.
[0040] Based on this, embodiments of this application propose a distributed transaction consistency execution method, apparatus, device, medium, and product, which can be used in the field of distributed technology and aims to solve the above-mentioned technical problems of the prior art. By assigning a unique transaction identifier to each distributed transaction, this unique transaction identifier serves as a unique identity identifier for the distributed transaction throughout its entire lifecycle, enabling precise location and tracking of specific transactions. Simultaneously, this unique transaction identifier is associated with the reverse operation instruction corresponding to the transaction operation of the distributed transaction, and the associated information is stored in a blockchain network. The blockchain network possesses characteristics such as decentralization, immutability, and traceability, ensuring the integrity and reliability of stored information and providing a solid data foundation for subsequent transaction rollback operations.
[0041] During the execution of a distributed transaction, if a partial commit fails, the reverse operation instructions associated with that pre-assigned unique transaction identifier are precisely retrieved from the blockchain network. These reverse operation instructions are then executed to roll back the successfully committed portions of the operation, restoring the entire distributed transaction to its state before the transaction began, thus achieving atomicity and consistency. This approach effectively ensures data consistency in complex environments while significantly reducing development complexity and maintenance costs, providing a strong guarantee for the stable operation of distributed systems.
[0042] 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.
[0043] To better understand the solutions of the embodiments of this application, an application scenario involved in the embodiments of this application will be introduced below.
[0044] For specific application scenarios of this application, please refer to [link / reference needed]. Figure 1 . Figure 1 This is a schematic diagram illustrating an application scenario of a distributed transaction consistency execution method provided in an embodiment of this application. It should be noted that... Figure 1 The examples shown are merely application scenarios that can be applied to the embodiments of this application, in order to help those skilled in the art understand the technical content of this application, but do not mean that the embodiments of this application cannot be used in other devices, systems, environments or scenarios.
[0045] like Figure 1 As shown, the application scenario includes: user terminal 101 and data processing server 102.
[0046] The data processing server 102 is connected to the user terminal 101 and is used to receive transaction requests initiated by users through the user terminal 101, execute distributed transactions, and when a partial failure of a distributed transaction is detected, it retrieves the corresponding reverse operation instruction from the blockchain network based on the unique transaction identifier and automatically executes the reverse operation instruction to accurately roll back the committed data changes, thereby achieving end-to-end transaction consistency guarantee and effectively reducing development complexity and maintenance costs.
[0047] Figure 2 This is a flowchart illustrating a distributed transaction consistency execution method provided in an embodiment of this application. The execution entity in this embodiment can be... Figure 1 The data processing server 102 in the illustrated embodiment can also be other computer-related devices, and this embodiment does not impose any particular limitation on it. For ease of description, this application embodiment uniformly describes the execution subject of a distributed transaction consistency execution method as a server. Figure 2 As shown, the method includes:
[0048] S201, Receive transaction requests initiated by users.
[0049] In this embodiment of the application, the transaction request is used to request the execution of a distributed transaction.
[0050] Specifically, the server can receive transaction requests from user terminals, which are used to initiate a distributed transaction involving multiple data shards, service nodes, or database instances. For example, in a financial scenario, this distributed transaction may include two cross-database operations: "deducting funds from account A" and "depositing funds into account B".
[0051] In other words, a transaction request refers to a business operation instruction initiated by a user, the core purpose of which is to request the server to execute a distributed transaction. For example, in interbank transfers in the financial sector, a user initiates a transaction request to transfer funds from their own bank account to another bank account through a mobile banking application; or in the complex shopping scenarios of e-commerce platforms, a user simultaneously purchases goods from multiple merchants and completes the order payment using multiple payment methods. These series of business requests involving multiple services and database operations can all be considered as distributed transaction requests. Upon receiving such a transaction request, the server formally initiates the distributed transaction processing flow.
[0052] S202. Based on the transaction request, generate a unique transaction identifier to identify the distributed transaction.
[0053] Specifically, in response to a transaction request, the server can invoke a transaction identifier generator to generate a globally unique transaction identifier. This unique transaction identifier can be generated based on a combination of factors such as timestamp, node identifier (ID), sequence number, and random entropy (e.g., using a snowflake-like algorithm), ensuring no conflicts in a distributed environment. In some embodiments, the transaction identifier generator can also integrate a dynamic priority analysis module, which can assign execution priorities to the distributed transaction according to preset business rules (such as transaction amount, customer credit rating, regulatory compliance requirements, etc.) for scheduling decisions during subsequent exception handling.
[0054] In other words, a unique transaction identifier is a unique identity for the entire distributed transaction throughout its lifecycle, possessing uniqueness and non-repeatability. Unique transaction identifiers can be generated in various ways, such as by combining timestamps, random numbers, and system-specific encoding rules. Taking timestamps as an example, the system can obtain current time information accurate to milliseconds or even microseconds, combine it with a randomly generated number within a certain range, and incorporate elements such as pre-defined business type codes. This information is then combined into a unique transaction identifier using a pre-defined algorithm (such as a hash algorithm). This method of generating unique transaction identifiers ensures accurate differentiation of each independent distributed transaction within the massive volume of transactions in a distributed system, providing crucial information for subsequent transaction tracking, operation correlation, and rollback processing.
[0055] S203. Based on the distributed transaction and the unique transaction identifier, generate the reverse operation instruction corresponding to the transaction operation of the distributed transaction.
[0056] Specifically, the server can parse every data manipulation statement contained in a distributed transaction, such as a Structured Query Language (SQL) update statement, and based on the principle of balanced syntax—that is, the SET clause and WHERE clause contain the same set of fields—generate corresponding reverse operation instructions through value substitution. Furthermore, a unique transaction identifier can be embedded in the reverse operation instructions to establish a strong association with the distributed transaction.
[0057] In other words, while generating a unique transaction identifier, the server can deeply analyze the reverse operation corresponding to each transaction operation based on the specific content and operational logic of the distributed transaction, and generate corresponding reverse operation instructions. Distributed transactions typically consist of multiple sub-operations, which may involve different database tables, different service modules, or even different system nodes. For example, in a distributed transaction that includes order creation, inventory deduction, and transaction processing, the order creation operation might be inserting a new order record into the order database; the inventory deduction operation might be reducing the inventory quantity of the corresponding product in the inventory database; and the transaction processing operation might be calling a third-party interface to complete the transfer of funds. For the order creation operation, the reverse operation instruction is to delete the newly inserted order record from the order database; the reverse operation instruction for inventory deduction is to increase the inventory quantity of the corresponding product in the inventory database back to its original value; and the reverse operation instruction for transaction processing is to call a third-party interface to perform a refund operation, returning the funds to the user's account. The server can accurately identify the reverse operation of each transaction operation and generate detailed and accurate reverse operation instructions to ensure correct execution when a rollback is required.
[0058] S204. Associate the unique transaction identifier with the reverse operation instruction and store it in the blockchain network.
[0059] Specifically, the server can bind the aforementioned reverse operation instructions with a unique transaction identifier, encapsulate them into blockchain transaction data, and submit them to a blockchain network composed of financial institutions, regulatory nodes, or trusted third parties. After the transaction is verified by the consensus mechanism, it is written into an immutable distributed ledger, achieving traceable and verifiable evidence of the reverse operation instructions.
[0060] In other words, after generating reverse operation instructions, the server can tightly associate unique transaction identifiers with these instructions and store the associated information in the blockchain network. Blockchain networks possess significant characteristics such as decentralization, immutability, and traceability, which provide security and reliability guarantees for distributed transaction data storage. Associating unique transaction identifiers with reverse operation instructions and storing them in the blockchain network means that this information is distributed across multiple nodes in the blockchain, and no single node can tamper with this data independently. Simultaneously, the chain structure of the blockchain can completely record the storage and modification history of data, making the reverse operation instructions for each distributed transaction traceable and auditable. For example, in a cross-border distributed transaction involving multiple financial institutions, by storing unique transaction identifiers and reverse operation instructions in the blockchain network, each financial institution can jointly maintain and verify this data, ensuring that the corresponding reverse operation instructions can be accurately located in case of anomalies, providing a reliable basis for transaction rollback.
[0061] S205. Execute a distributed transaction, and if the distributed transaction fails to commit, extract the reverse operation instruction associated with the unique transaction identifier from the blockchain network based on the unique transaction identifier.
[0062] Specifically, the server executes each operation statement in the distributed transaction normally and attempts to commit. If all sub-operations are successfully committed, the transaction is complete. If, due to network interruption, node failure, or concurrency conflicts, some operations succeed while others fail (i.e., the transaction is in a "half-commit" state), a consistency repair process is triggered. Based on the unique transaction identifier, the corresponding reverse operation instruction is retrieved from the blockchain network.
[0063] In other words, after completing the above preparations, the server can officially begin executing the distributed transaction. The execution of a distributed transaction involves the coordination and synchronization of multiple sub-operations. The server needs to execute each sub-operation sequentially according to the predetermined business logic and transaction order. During execution, the server can monitor the execution status of each sub-operation in real time. When a partial commit failure of the distributed transaction is detected, a rollback mechanism can be triggered immediately. Based on a pre-generated unique transaction identifier, a query request is initiated to the blockchain network to accurately extract the reverse operation instruction associated with that unique transaction identifier.
[0064] S206. Execute the reverse operation instruction to realize the rollback operation of the distributed transaction.
[0065] Specifically, before executing the reverse operation instruction, further pre-checks can be performed. For example, database snapshot comparison can be used to verify whether the current state of the target record meets the prerequisites for executing the reverse operation; blockchain notarization can be used to verify that the reverse operation instruction has not been tampered with; and a pre-check lock mechanism can be used to prevent multiple compensation tasks from concurrently operating on the same data.
[0066] Once the pre-check passes, the server can execute reverse operation instructions to precisely roll back the committed data changes to the state before the transaction, thereby restoring global consistency.
[0067] In other words, after successfully retrieving the reverse operation instructions from the blockchain network, the server can execute these instructions sequentially according to a predetermined order and logic. Executing the reverse operation instructions involves reversing the successfully committed sub-operations, restoring the system state to its state before the distributed transaction began. For example, in the distributed transaction mentioned earlier involving order creation, inventory deduction, and transaction processing, if the transaction processing sub-operation fails, the server can first execute the reverse operation instruction for transaction processing to issue a refund, then execute the reverse operation instruction for inventory deduction to increase the inventory quantity back, and finally execute the reverse operation instruction for order creation to delete the order record. By fully executing these reverse operation instructions, the server can ensure the atomicity of the distributed transaction, meaning that all operations either all succeed or all fail, thus effectively guaranteeing the consistency of the distributed transaction.
[0068] The distributed transaction consistency execution method of this application provides a reliable and efficient transaction consistency guarantee mechanism for distributed systems through a series of rigorous steps, starting from receiving transaction requests, generating unique transaction identifiers and reverse operation instructions, then associating and storing them in the blockchain network, and finally performing rollback operations when partial submissions fail. It can effectively cope with various complex situations in a distributed environment and ensure the stable operation of the distributed system and the accuracy of data.
[0069] This embodiment provides a distributed transaction consistency execution method, comprising: first, receiving a transaction request initiated by a user, the transaction request being used to request the execution of a distributed transaction; next, generating a unique transaction identifier to identify the distributed transaction based on the transaction request; then, generating a reverse operation instruction corresponding to the transaction operation of the distributed transaction based on the distributed transaction and the unique transaction identifier; subsequently, storing the unique transaction identifier and the reverse operation instruction together in a blockchain network; then, executing the distributed transaction, and when a partial commit of the distributed transaction fails, retrieving the reverse operation instruction associated with the unique transaction identifier from the blockchain network based on the unique transaction identifier; finally, executing the reverse operation instruction to realize the rollback operation of the distributed transaction.
[0070] The following technical effects are achieved: During the execution of a distributed transaction, if a partial commit fails, the reverse operation instructions associated with that unique transaction identifier are precisely extracted from the blockchain network. By executing these reverse operation instructions, the successfully committed operations are rolled back, restoring the entire distributed transaction to its state before the transaction began, thus achieving atomicity and consistency. This effectively ensures data consistency in complex environments while significantly reducing development complexity and maintenance costs, providing strong support for the stable operation of distributed systems. It effectively solves the data inconsistency problem caused by partial commit failures in distributed scenarios while reducing development complexity. By assigning a unique transaction identifier to each distributed transaction, which serves as a unique identity throughout the transaction's lifecycle, specific transactions can be accurately located and tracked. By associating the unique transaction identifier with the reverse operation instructions corresponding to the transaction operations of the distributed transaction and storing the associated information in the blockchain network, the integrity and reliability of the stored information are ensured, providing a solid data foundation for subsequent transaction rollback operations.
[0071] In one possible implementation, generating a unique transaction identifier for identifying a distributed transaction based on a transaction request includes: invoking a transaction identifier generator based on the transaction request, so that the transaction identifier generator generates a unique transaction identifier for identifying a distributed transaction according to a preset algorithm.
[0072] Specifically, in response to a received transaction request, the server can invoke the Transaction ID Generator. This Transaction ID Generator can be a centralized or distributed logical service module, deployed in a Trusted Execution Environment (TEE) or a highly available cluster to ensure its stability and security.
[0073] The transaction identifier generator can generate a unique transaction identifier (Transaction ID) that is globally unique, non-repeatable, and unpredictable throughout the entire lifecycle of the distributed system, based on a preset globally unique identifier generation algorithm and combined with multi-dimensional information of the transaction request.
[0074] The preset algorithm can adopt any one or a combination of the following methods:
[0075] For example, a structure similar to the Snowflake algorithm can be constructed using millisecond-level timestamps (such as 20251218142300), the unique machine ID of the current service node, such as the Media Access Control Address (MAC) address hash or configuration ID, and a locally incrementing sequence number.
[0076] It invokes the Cryptographically Secure Pseudorandom Number Generator (CSPRNG) provided by the operating system or hardware security module, such as the Trusted Platform Module (TPM) or Hardware Security Module (HSM), to generate a random identifier with 128 bits or higher entropy.
[0077] Hash key fields of the transaction request (such as user ID, transaction type, and initiation time) using hash operations (such as SHA-3, SHA-256, or SM3) and attach a salt value to avoid collisions.
[0078] Furthermore, the transaction identifier generator can also integrate a dynamic priority analysis module. This module analyzes the current transaction request in real time based on preset business rules (e.g., risk level of financial transactions, transaction amount threshold, customer credit rating, regulatory compliance requirements, etc.) and associates an execution priority tag with the generated unique transaction identifier. This priority tag can be passed along with the unique transaction identifier to the subsequent reverse operation scheduling stage. During anomaly recovery, the corresponding reverse operation instruction is executed based on the priority tag, ensuring that critical business operations can be responded to promptly.
[0079] The final generated transaction identifier can be in structured string format, containing semantic information such as time, node, sequence number, and priority, which facilitates log tracking and operation and maintenance analysis while ensuring global uniqueness.
[0080] By invoking a transaction identifier generator to generate a unique transaction identifier according to a preset algorithm, it is ensured that each distributed transaction has a unique identity from the source, providing a reliable foundation for subsequent reverse operation construction, blockchain notarization, and consistent rollback. From transaction request to final commit or rollback, this unique transaction identifier enables precise correlation and state tracking of transaction operations. When a partial commit of a distributed transaction fails and triggers a rollback, the unique transaction identifier allows for quick location and extraction of the corresponding reverse operation instruction, ensuring the accuracy and efficiency of the rollback operation. This fundamentally solves the problems of chaotic identifiers and difficult rollbacks in traditional distributed transaction management, providing solid technical support for building a highly reliable and easily maintainable distributed transaction system.
[0081] In one possible implementation, a distributed transaction includes at least two sub-transactions. Based on the distributed transaction and a unique transaction identifier, reverse operation instructions corresponding to the transaction operations of the distributed transaction are generated. This includes: parsing each sub-transaction in the distributed transaction to obtain the corresponding sub-operation statements; determining the reverse operation statements corresponding to each sub-operation statement based on a predefined rule engine or operation template library; and obtaining the reverse operation instructions corresponding to the transaction operations of the distributed transaction based on the unique transaction identifier and each reverse operation statement.
[0082] Specifically, firstly, the server can perform structured parsing of distributed transactions, identify the various sub-transactions contained within them, and extract standardized sub-operation statements. These sub-operation statements can be SQL statements or message queue instructions, etc. For standardized processing, all sub-operation statements can be converted into an intermediate representation format, containing metadata such as operation type, target resource, field change set, and preconditions.
[0083] Next, the server can invoke a pre-defined reverse operation generation unit, which can include two optional mechanisms: a predefined rule engine and an operation template library.
[0084] The rules engine supports condition matching and pattern derivation through a built-in set of formal compensation rules.
[0085] The operation template library predefines standard forward and reverse template pairs for various operations (e.g., payment template, account change template, status update template), and each template pair uses placeholders to achieve parameterized replacement.
[0086] The server can automatically match the corresponding rules or templates based on the type and semantic features of the sub-operation statement, and generate a syntactically correct and semantically symmetrical reverse operation statement.
[0087] The server can then strongly associate each of the generated reverse operation statements with a unique transaction identifier. Specifically, the transaction identifier is explicitly embedded as a filter field and audit mark in the conditional statement (such as the WHERE clause in SQL) and the data update statement (such as the SET clause).
[0088] Thus, all the reverse operation statements together constitute a complete reverse operation instruction set, which corresponds to the initial distributed transaction and can be accurately retrieved and executed through a unique transaction identifier.
[0089] By using a predefined rule engine or operation template library, the system enables automated, structured, and verifiable generation of reverse operation instructions for heterogeneous, multi-step distributed transactions. This provides a reliable foundation for subsequent blockchain-based evidence storage and exception rollback, significantly reducing the complexity of manually writing compensation logic.
[0090] In one possible implementation, after generating the reverse operation instruction corresponding to the transaction operation of the distributed transaction based on the distributed transaction and the unique transaction identifier, the method further includes: verifying the reverse operation instruction by simulating execution in an isolated environment to obtain a verification result; if the verification result indicates that the verification failed, returning to the step of generating the reverse operation instruction corresponding to the transaction operation of the distributed transaction based on the distributed transaction and the unique transaction identifier, so as to regenerate a new reverse operation instruction based on the corrected transaction operation, and simulating the execution of the new reverse operation instruction for verification, until the verification result indicates that the verification passed or the preset number of retries is reached.
[0091] Specifically, the server can submit the generated reverse operation instructions to an isolated verification environment for simulated execution. This isolated environment can be implemented using any one or a combination of the following methods:
[0092] For example, a shadow database built from a read-only snapshot of a production database preserves the data state at the time of the transaction. A sandboxed execution engine simulates the data table structure and constraints in memory but does not actually modify persistent storage. A trusted execution environment (TEE) ensures that the verification process is free from external interference.
[0093] In an isolated environment, reverse operation instructions can be executed in their entirety, and the execution process and results can be monitored.
[0094] The server can analyze the simulation execution results according to preset verification rules and generate verification results. These verification rules include, but are not limited to: whether the reverse operation statement conforms to the syntax specifications of the target database or service; whether the data can be restored to its initial distributed transaction state after the reverse operation instruction is executed (e.g., matching of key values such as balance and status fields); whether the target record actually exists (to prevent rollback of deleted or never-existent data); and whether multiple executions of the reverse operation instruction produce the same result to avoid new anomalies caused by compensation operations.
[0095] If all verification items pass, the reverse operation instruction verification is successful, and the process can proceed to the subsequent on-chain evidence storage stage; otherwise, the reverse operation instruction verification is failed, and a detailed reason for the failure is recorded (such as "target account balance does not match" or "user status cannot be reversed").
[0096] When the verification result indicates verification failure, the server can choose not to discard the reverse operation instruction directly, but instead automatically return to the reverse operation instruction generation step and initiate the intelligent correction process. Based on the failure cause analysis module, it identifies non-standard syntax, missing fields, or business logic conflicts in the initial transaction operation; it performs structured corrections on the original sub-operation statements (e.g., completing the transaction identifier field in the WHERE condition, adjusting the state mapping relationship, adding version number control, etc.); using the updated transaction operation and the unique transaction identifier, it regenerates a new reverse operation instruction; and then simulates and verifies the newly generated reverse operation instruction again in an isolated environment.
[0097] This iterative process continues until the generated reverse operation command passes all verification items or reaches the preset number of retries (e.g., 3 times). If it still fails at this point, a manual intervention alarm can be triggered, and the unique transaction identifier, the original operation, the failure log, and the suggested correction plan will be pushed to the operation and maintenance platform.
[0098] Through a closed-loop mechanism of generation, verification, correction, and re-verification, invalid rollbacks or secondary anomalies caused by logical errors in reverse operation instructions, environmental changes, or data drift are effectively avoided. This significantly improves the reliability, self-healing ability, and automation level of the distributed transaction compensation mechanism, making it particularly suitable for scenarios with extremely high data consistency requirements, such as finance and regulation.
[0099] In one possible implementation, the unique transaction identifier is associated with the reverse operation instruction and stored in the blockchain network, including: encapsulating the reverse operation instruction into blockchain transaction data; embedding the unique transaction identifier in the blockchain transaction data as an index field; verifying the blockchain transaction data through consensus nodes; and writing the blockchain transaction data into the distributed ledger of the blockchain network after successful verification, so that the reverse operation instruction and the unique transaction identifier are persistently bound and stored on the blockchain network.
[0100] Specifically, firstly, the server can serialize the reverse operation instructions into a standardized data payload and encapsulate it into blockchain transaction data according to the transaction format requirements of the target blockchain platform. This blockchain transaction data can use compact encoding formats such as Lightweight Data Interchange Format (JavaScriptObject Notation, JSON), Protocol Buffers, or Concise Binary Object Representation (CBOR), and includes metadata such as operation type, target table / service, field mapping relationships, and execution conditions.
[0101] Next, the server can explicitly embed a unique transaction identifier in key field areas of the blockchain transaction data (such as transaction metadata or smart contract parameters) as a global index field and transaction association key for the blockchain transaction data. This unique transaction identifier can not only be used for subsequent fast retrieval, but also serve as an input parameter during smart contract execution, ensuring that rollback operations are strictly limited to the corresponding distributed transaction.
[0102] The server can then send the packaged blockchain transaction data to a blockchain network comprised of financial institutions, regulatory agencies, or trusted third parties. Consensus nodes within the blockchain network can perform multi-dimensional verification of the blockchain transaction data based on pre-defined access policies and verification rules. This includes: compliance and uniqueness of the unique transaction identifier format; syntactic compliance of reverse operation instructions (e.g., whether they conform to pre-registered operation templates); identity authentication and authorization of the submitter, such as verification via digital certificates or decentralized identifiers (DIDs); and data integrity (e.g., tamper-proofing through SHA-256 or SM3 hash verification).
[0103] Finally, once the blockchain transaction data reaches a consensus through the consensus mechanism, it can be formally packaged and included in a new block, and written immutably into the distributed ledger of the blockchain network. This ensures that the reverse operation instruction and the unique transaction identifier form a strongly bound, traceable, and persistent storage record on the blockchain.
[0104] Furthermore, in some embodiments, the blockchain transaction data can also trigger an Attestation Smart Contract, which automatically records audit information such as operation timestamps, submitting node identities, and verification results, thereby further enhancing regulatory transparency.
[0105] By storing the reverse operation instructions and unique transaction identifiers on the blockchain, the decentralized trust, immutability, and verifiability of blockchain are utilized to solve the problem that the reverse logic in traditional compensation mechanisms is easily tampered with and lost. This provides a reliable, transparent, and auditable technical foundation for the consistent rollback of distributed transactions.
[0106] In one possible implementation, executing the reverse operation instruction includes: obtaining the execution priority of the distributed transaction according to preset business rules, wherein the business rules include at least one of financial transaction security level, transaction amount threshold, customer credit rating or regulatory compliance requirements; obtaining the execution order of the reverse operation instructions according to the execution priority; and executing the corresponding reverse operation instructions according to the execution order.
[0107] In this embodiment of the application, the steps of executing the reverse operation instruction may not be simply executed in the order of generation. A smart scheduling mechanism based on business semantics may also be introduced to ensure that the abnormal recovery of critical business can be given priority.
[0108] Specifically, firstly, the server can call the preset business rule engine to perform importance analysis on the distributed transactions that are currently pending rollback and output an execution priority.
[0109] The business rules include, but are not limited to, at least one of the following:
[0110] Financial transaction security levels. For example, transactions involving cross-border transactions, large-scale clearing, and other sensitive operations can be marked as high priority.
[0111] Transaction amount threshold. For example, when the transaction amount exceeds a preset threshold (such as 1 million yuan), the priority is automatically increased.
[0112] Customer credit rating. For example, distributed transactions of Very Important Person (VIP) clients, institutional clients, or high-net-worth clients may be given higher recovery priority.
[0113] Regulatory compliance requirements. Transactions that comply with mandatory compliance requirements can prioritize ensuring data consistency.
[0114] Impact on business continuity. For example, if a distributed transaction failure would cause a disruption to core business operations (such as a blocked transaction channel), its priority can be increased.
[0115] In some embodiments, the priority can also be dynamically adjusted in conjunction with real-time system load, transaction wait time, or number of failures to achieve more granular resource scheduling.
[0116] Next, the server can place all pending reverse operation instructions (such as those from multiple concurrently failed distributed transactions) into a priority queue or scheduling buffer. Then, the reverse operation instructions can be sorted according to the execution priority of the distributed transactions associated with each instruction to obtain the execution order of the reverse operation instructions, and an execution order list can be formed.
[0117] For example, all first-priority reverse operation instructions are queued first and executed in ascending order of commit time. Reverse operation instructions of the same priority can be further sorted by the timestamp of a unique transaction identifier or the severity of failure. Preemptive scheduling can be supported; for example, if a newly arriving distributed transaction has a higher priority than a queued reverse operation instruction, it can be inserted at the head of the queue.
[0118] Finally, the server can execute the reverse operation instructions in the order of execution, taking the highest priority reverse operation instruction from the head of the queue. Before execution, a lightweight pre-check can be performed (such as whether the target data has been overwritten or the lock has been occupied). After confirming that there is no conflict, the server calls the corresponding database or service interface to execute the reverse operation instruction.
[0119] During execution, operation logs, execution time, and result status can be recorded, and successfully rolled-back transactions can be removed from the pending list. If a specific reverse operation instruction fails to execute (e.g., because the data has been overwritten by subsequent business processes), an alarm is triggered and the process is downgraded to manual intervention. At the same time, the next high-priority instruction continues to be processed to avoid low-priority tasks blocking critical recovery operations.
[0120] By introducing a business-driven priority scheduling mechanism, distributed system resources can be intelligently allocated in distributed transaction anomaly recovery scenarios, prioritizing the consistency repair of critical business or heavily regulated distributed transactions. This significantly improves the business resilience, compliance capabilities, and user experience of financial-grade systems, while avoiding the problem of critical transaction recovery delays caused by low-priority compensation tasks occupying resources for extended periods.
[0121] Figure 3 This is a schematic diagram of the structure of a distributed transaction consistency execution device provided in an embodiment of this application. Figure 3 As shown, the distributed transaction consistency execution device includes: a receiving module 310, a generating module 320, a storage module 330, and an execution module 340.
[0122] The receiving module 310 is used to receive transaction requests initiated by users, which are used to request the execution of distributed transactions.
[0123] The generation module 320 is used to generate a unique transaction identifier for identifying a distributed transaction based on the transaction request.
[0124] The generation module 320 is also used to generate reverse operation instructions corresponding to the transaction operations of the distributed transaction based on the distributed transaction and the unique transaction identifier.
[0125] Storage module 330 is used to associate a unique transaction identifier with a reverse operation instruction and store it in the blockchain network.
[0126] The execution module 340 is used to execute distributed transactions and, when a partial commit of a distributed transaction fails, extracts a reverse operation instruction associated with the unique transaction identifier from the blockchain network.
[0127] The execution module 340 is also used to execute reverse operation instructions to implement the rollback operation of distributed transactions.
[0128] In one possible implementation, the generation module 320 is further configured to invoke the transaction identifier generator according to the transaction request, so that the transaction identifier generator generates a unique transaction identifier for identifying the distributed transaction according to a preset algorithm.
[0129] In one possible implementation, the distributed transaction includes at least two sub-transactions. The generation module 320 is also used to parse each sub-transaction in the distributed transaction to obtain the corresponding sub-operation statements.
[0130] The generation module 320 is also used to determine the reverse operation statement corresponding to each sub-operation statement based on a predefined rule engine or operation template library.
[0131] The generation module 320 is also used to obtain the reverse operation instructions corresponding to the transaction operations of the distributed transaction based on the unique transaction identifier and each reverse operation statement.
[0132] In one possible implementation, the generation module 320 is also used to obtain a verification result by simulating the execution of the reverse operation instruction in an isolated environment.
[0133] The generation module 320 is also used to return the step of generating a reverse operation instruction corresponding to the transaction operation of the distributed transaction based on the distributed transaction and the unique transaction identifier when the verification result indicates that the verification failed, so as to regenerate a new reverse operation instruction based on the corrected transaction operation, and to verify the new reverse operation instruction by simulating the execution until the verification result indicates that the verification passed or the preset number of retries is reached.
[0134] In one possible implementation, the storage module 330 is also used to encapsulate the reverse operation instructions into blockchain transaction data.
[0135] Storage module 330 is also used to embed a unique transaction identifier in blockchain transaction data as an index field.
[0136] Storage module 330 is also used to verify blockchain transaction data through consensus nodes.
[0137] Storage module 330 is also used to write blockchain transaction data into the distributed ledger of the blockchain network after verification, so that the reverse operation instruction and the unique transaction identifier are persistently bound and stored on the blockchain network.
[0138] In one possible implementation, the execution module 340 is further configured to obtain the execution priority of the distributed transaction according to preset business rules, wherein the business rules include at least one of financial transaction security level, transaction amount threshold, customer credit rating or regulatory compliance requirements.
[0139] The execution module 340 is also used to determine the execution order of the reverse operation instructions based on the execution priority.
[0140] The execution module 340 is also used to execute the corresponding reverse operation instructions according to the execution order.
[0141] This embodiment provides a distributed transaction consistency execution device that can execute a distributed transaction consistency execution method of the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.
[0142] In the aforementioned specific implementation of a distributed transaction consistency execution device, each module and unit can be implemented as a processor. The processor can execute computer execution instructions stored in the memory, thereby enabling the processor to execute the aforementioned distributed transaction consistency execution method.
[0143] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device includes at least one processor 410 and a memory 420. The electronic device also includes a communication component 430. The processor 410, memory 420, and communication component 430 are connected via a bus 440.
[0144] In the specific implementation process, at least one processor 410 executes computer execution instructions stored in memory 420, causing at least one processor 410 to execute a distributed transaction consistency execution method as executed on the electronic device side as described above.
[0145] The specific implementation process of processor 410 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.
[0146] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.
[0147] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage.
[0148] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0149] The above description of the functions implemented by electronic devices and main control devices has introduced the solutions provided by the embodiments of the present invention. It is understood that, in order to implement the above functions, the electronic device or main control device includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments of the present invention, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of the present invention.
[0150] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the distributed transaction consistency execution method described above.
[0151] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.
[0152] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in an electronic device or a host device.
[0153] This application also provides a computer program product, which includes a computer program stored in a readable storage medium. At least one processor of an electronic device can read the computer program from the readable storage medium, and the at least one processor executes the computer program to cause the electronic device to perform the solution provided in the above embodiments.
[0154] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.
[0155] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A distributed transaction consistency execution method, characterized in that, include: Receive a transaction request initiated by a user, the transaction request being used to request the execution of a distributed transaction; Based on the transaction request, a unique transaction identifier is generated to identify the distributed transaction; Based on the distributed transaction and the unique transaction identifier, generate a reverse operation instruction corresponding to the transaction operation of the distributed transaction; The unique transaction identifier is associated with the reverse operation instruction and stored in the blockchain network; The distributed transaction is executed, and if the distributed transaction fails to commit partially, a reverse operation instruction associated with the unique transaction identifier is extracted from the blockchain network based on the unique transaction identifier. Execute the reverse operation instruction to implement the rollback operation of the distributed transaction.
2. The method according to claim 1, characterized in that, The step of generating a unique transaction identifier for identifying the distributed transaction based on the transaction request includes: Based on the transaction request, a transaction identifier generator is invoked so that the transaction identifier generator generates a unique transaction identifier to identify the distributed transaction according to a preset algorithm.
3. The method according to claim 1, characterized in that, The distributed transaction includes at least two sub-transactions; The step of generating a reverse operation instruction corresponding to the transaction operation of the distributed transaction based on the distributed transaction and the unique transaction identifier includes: Parse each sub-transaction in the distributed transaction to obtain the corresponding sub-operation statements; Based on the predefined rule engine or operation template library, determine the reverse operation statement corresponding to each sub-operation statement; Based on the unique transaction identifier and each reverse operation statement, the reverse operation instructions corresponding to the transaction operation of the distributed transaction are obtained.
4. The method according to claim 1, characterized in that, After generating the reverse operation instruction corresponding to the transaction operation of the distributed transaction based on the distributed transaction and the unique transaction identifier, the method further includes: The verification results were obtained by simulating the execution of the reverse operation command in an isolated environment. When the verification result indicates that the verification failed, the process returns to the step of generating a reverse operation instruction corresponding to the transaction operation of the distributed transaction based on the distributed transaction and the unique transaction identifier, so as to regenerate a new reverse operation instruction based on the corrected transaction operation, and simulate the execution of the new reverse operation instruction for verification, until the verification result indicates that the verification passed or the preset number of retries is reached.
5. The method according to claim 1, characterized in that, The step of associating the unique transaction identifier with the reverse operation instruction and storing it in the blockchain network includes: The reverse operation instruction is encapsulated as blockchain transaction data; The unique transaction identifier is embedded in the blockchain transaction data as an index field; The blockchain transaction data is verified through consensus nodes; After successful verification, the blockchain transaction data is written into the distributed ledger of the blockchain network, so that the reverse operation instruction and the unique transaction identifier are persistently bound and stored on the blockchain network.
6. The method according to any one of claims 1 to 5, characterized in that, The execution of the reverse operation instruction includes: The execution priority of the distributed transaction is obtained according to the preset business rules, wherein the business rules include at least one of the following: financial transaction security level, transaction amount threshold, customer credit rating, or regulatory compliance requirements. The execution order of the reverse operation instructions is obtained based on the execution priority. Execute the corresponding reverse operation instructions according to the execution order.
7. A distributed transaction consistency execution device, characterized in that, include: A receiving module is used to receive transaction requests initiated by users, wherein the transaction requests are used to request the execution of distributed transactions; The generation module is used to generate a unique transaction identifier for identifying the distributed transaction based on the transaction request. The generation module is further configured to generate a reverse operation instruction corresponding to the transaction operation of the distributed transaction based on the distributed transaction and the unique transaction identifier; A storage module is used to associate the unique transaction identifier with the reverse operation instruction and store it in the blockchain network; An execution module is used to execute the distributed transaction and, when a portion of the distributed transaction fails to commit, extract a reverse operation instruction associated with the unique transaction identifier from the blockchain network. The execution module is also used to execute the reverse operation instruction to realize the rollback operation of the distributed transaction.
8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.