A compensation transaction implementation method for a distributed database

Abstract

The application discloses a kind of compensation transaction implementation methods for distributed database, belong to distributed database technical field, it specifically includes: client initiates transaction request, whether transaction SQL exceeds limit by executing directory judgment, coordinating node is allocated a time stamp for the transaction of step S1 client initiation, while the related operation of this transaction is sent to data node, after data node receives transaction request, it is judged that transaction commits or transaction rollback, and execution result is returned to coordinating node to confirm and verify, if verification fails, coordinating node notifies the data node and carries out compensation operation, operation is completed, coordinating node submits the transaction, and carries out timing cleaning, execution result is returned to client, guarantee the consistency of data under distributed environment, reduce the complexity of transaction processing process.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of distributed databases, and particularly relates to a compensation transaction implementation method for a distributed database. BACKGROUND

[0002] Distributed systems have become a central part of modern software architecture, which can provide high availability, scalability and fault recovery capabilities, and in these systems, business operations across multiple services need to be handled, which leads to the demand for distributed transactions. Distributed transactions refer to participants of transactions and servers supporting transactions, and currently, distributed transactions mainly have the following modes: AT mode, Saga mode, TCC mode, XA mode and compensation transaction mode. The AT mode is a non-invasive distributed transaction solution with zero learning cost, but SQL is hosted and uniformly executed by the framework, which may cause dirty write problems; the Saga mode is a long transaction solution, which operates DB in the first phase, and may cause dirty read problems; the TCC mode is suitable for core systems and other scenarios with high performance requirements, and transaction execution is too long to lock rows, which avoids dirty read; the XA mode is a strong consistency solution, but has low performance and is less used; and the core idea of the compensation transaction is to undo completed business operations by executing a series of reverse operations, which are called "compensation operations", which can ensure that the system can recover to a consistent state in the event of errors or abnormal conditions, and has the advantages of decoupling, fault tolerance and flexibility.

[0003] A distributed database and a method for realizing cross-node transaction strong consistency thereof are disclosed in Chinese Patent Application Publication No. CN112182103A, and the feature is that the distributed database adopts a storage and computing separation architecture, including three types of nodes: coordination nodes, data nodes and catalog nodes, each type of node can be horizontally expanded, the coordination nodes are responsible for distributing requests to data nodes that need to participate, the data nodes are responsible for data access and storage, the catalog nodes store system metadata and partition-related information, a transaction is initiated via the coordination nodes and is issued to one or more data node groups for operation, the distributed database introduces a transaction negotiation and transaction compensation mechanism between data nodes as participants, when a local system failure causes participants to fail to normally receive transaction control messages from coordination nodes as coordinators, the participants confirm each other's states, so as to determine whether the transaction should be committed or rolled back, to avoid data inconsistency problems.

[0004] A distributed database data processing method, device, storage medium and electronic device are disclosed in Chinese Patent No. CN110019469B. The present application comprises: after receiving an export request for exporting data in a distributed database, the database import and export management node obtains the active transaction list and the export table distribution information at the current time; the database import and export management node notifies the corresponding database to perform data export operation according to the export table distribution information; the database import and export management node sends the active transaction list to the database agent node of the corresponding database after determining that the corresponding database has completed the data export operation; after receiving the data consistency reverse compensation statement returned by the database agent node, the database import and export management node imports the data exported by the corresponding database into the predetermined database, and instructs the predetermined database to execute the data consistency reverse compensation statement.

[0005] The above prior art has the following problems: 1) complex implementation, large impact on database performance, not suitable for high concurrency and high performance scenarios; 2) compensation task is lost after node restart. SUMMARY

[0006] In view of the deficiencies of the prior art, the present application proposes a compensation transaction implementation method for distributed databases, which specifically comprises: a client initiates a transaction request, executes a directory to determine whether the transaction SQL exceeds a limit value, a data node receives the transaction request, determines whether it is a transaction submission or a transaction rollback, and returns the execution result to the coordination node for confirmation and verification, the operation is completed, the coordination node submits the transaction and performs timed cleaning, and the result is returned to the client, thereby ensuring the consistency of data in a distributed environment and reducing the complexity of the transaction processing process.

[0007] To achieve the above purpose, the present application provides the following technical solutions:

[0008] A compensation transaction implementation method for distributed databases, comprising:

[0009] Step S1: the client initiates a transaction request, determines whether the transaction SQL exceeds a limit value by executing a directory, and if it exceeds, the backend database returns an error, and the transaction information is stored in the transaction SQL mapping module;

[0010] Step S2: the coordination node allocates a timestamp for the transaction initiated by the client in step S1, and sends the operation of the transaction to the data node;

[0011] Step S3: after the data node receives the transaction request, it determines whether it is a transaction submission or a transaction rollback, and returns the execution result to the coordination node for confirmation and verification, if the verification fails, the coordination node notifies the data node and performs compensation operation;

[0012] Step S4: operation is completed, the coordination node commits the transaction, and carries out timing clean-up, and the execution result is returned to the client.

[0013] Specifically, the specific steps of the step S1 include:

[0014] Step S101: determine the directory path of transaction execution and read the contained SQL script file;

[0015] Step S102: analyze the content of the SQL script file to determine whether there is a SQL statement or operation that may cause the transaction to exceed the limit value, and output the analysis result, according to the analysis result, determine whether the SQL statement of the transaction exceeds the predetermined limit value;

[0016] Step S103: start the transaction and monitor its execution, if the transaction exceeds the limit value during execution, the backend database responds and returns an error immediately;

[0017] Step S104: receive the error and process it, if the transaction is executed successfully, continue to process other transactions or close the connection.

[0018] Specifically, the specific steps of the step S2 include:

[0019] Step S201: the client sends a transaction request to the coordination node, and the coordination node receives the transaction request and parses and processes it;

[0020] Step S202: the coordination node generates a globally unique timestamp according to the compensation rule, and assigns the generated timestamp to the transaction initiated by the client in step S1;

[0021] Step S203: the coordination node forwards the generated timestamp to the relevant data node together with the transaction request.

[0022] Specifically, the timestamp in the step S202 specifically includes: transaction start time, transaction commit time and transaction rollback time.

[0023] Specifically, the specific steps of the step S3 include:

[0024] Step S301: the data node receives the transaction request forwarded by the coordination node, sorts and executes according to the timestamp, and judges whether to read, write or other operation;

[0025] Step S302: according to the judgment result, the data node carries out reading or modifying operation on the local data, and judges the state of the transaction;

[0026] Step S303: The data node judges whether the transaction can be committed, and if yes, the operation result is persisted into the database, and an acknowledgement message is returned to the coordination node; if not, the related operations performed before are revoked, the database is restored to the state before the transaction starts, and an acknowledgement message is returned to the coordination node;

[0027] Step S304: After receiving the acknowledgement message from the data node, the coordination node verifies the operation result by using the three-phase commit strategy, and if the verification is passed, it indicates that the operation of the data node is successfully completed, and if the verification fails, rollback needs to be performed.

[0028] Specifically, the three-phase commit strategy in step S304 specifically includes: a pre-commit phase is added between the preparation phase and the commit phase, so that the coordination node sends a pre-commit request to all participating nodes, and judges the commit or rollback operation according to the response of the participating nodes.

[0029] Specifically, the specific steps of the compensation operation in step S304 include:

[0030] Step S3041: Determine the transaction that needs to be compensated, and define the compensation rule;

[0031] Step S3042: According to the compensation rule, map the operation in the distributed transaction to the compensation operation through the transaction compensation mapping;

[0032] Step S3043: Map the compensation execution state of each operation through the compensation execution flag;

[0033] Step S3044: If the compensation operation is successfully executed, commit the database, and record the commit state of each operation through the commit success mapping.

[0034] Specifically, the compensation rule in step S3041 includes: reverse operation, data repair, transaction rollback, state recovery, sequential execution, repeatability and consistency guarantee.

[0035] Specifically, the specific steps of step S4 include:

[0036] Step S401: After receiving the responses of all participating nodes, the coordination node confirms that all operations have been completed;

[0037] Step S402: The coordination node commits the transaction to the database or the distributed transaction manager, and records the commit state by using the commit success mapping;

[0038] Step S403: After confirming the success of the transaction commit, the coordination node performs the operation of cleaning up historical data and releasing resources at regular intervals;

[0039] Step S404: The result of the transaction processing is returned to the client.

[0040] A compensation transaction implementation system for a distributed database comprises a transaction SQL mapping module, a transaction commit success mapping module, a transaction rollback mapping module, a compensation Tmp mapping module, a compensation mapping module, and a compensation execution flag mapping module,

[0041] The transaction SQL mapping module is configured to determine whether a transaction SQL exceeds an upper limit or a commit limit value.

[0042] The transaction commit success mapping module is configured to record transaction mapping of a distributed transaction that is successfully committed and clean up data when there is a timing task.

[0043] The transaction rollback mapping module is configured to record a rolled back distributed transaction and clean up data in the transaction when there is a timing task.

[0044] The compensation Tmp mapping module is configured to record a temporary node transaction that needs to be compensated.

[0045] The compensation mapping module is configured to record a node transaction that needs to be compensated.

[0046] The compensation execution flag mapping module is configured to mark a node that is executing a compensation transaction.

[0047] Compared with the prior art, the present application has the following advantages:

[0048] 1. The present application proposes a compensation transaction implementation system for a distributed database, and optimizes and improves the architecture, operation steps and flow, and the system has the advantages of simple flow, low investment and operation cost, and low production cost, and realizes a compensation transaction scheme that does not affect data on the basis of guaranteeing perfect function, unchanged request mode and slight performance loss.

[0049] 2. The present application proposes a compensation transaction implementation method for a distributed database, and records the state of each node transaction and the SQL condition through a local file in the data aspect, which can guarantee the SQL compensation efficiency and realize that the compensation transaction is not lost after node restart; in the function aspect, only the directory level is locked after entering the compensation transaction, the influence on the business is minimized, the compensation task is automatically performed by a timing thread, and the lock is released after successful compensation, and the business is not aware of this process.

[0050] 3. The present application proposes a compensation transaction implementation method for a distributed database, and records the transaction that needs to be compensated by using the combination of memory and local file, which can guarantee the efficiency and ensure that the compensation task is not lost after restart, realizes a compensation transaction scheme that does not affect data on the basis of guaranteeing perfect function, unchanged request mode and slight performance loss. BRIEF DESCRIPTION OF DRAWINGS

[0051] Figure 1 A flow chart of a compensation transaction implementation method for a distributed database according to the present application;

[0052] Figure 2 A system analysis flow chart of a compensation transaction implementation method for a distributed database according to the present application;

[0053] Figure 3 A three-phase commit coordinator state transition flow chart of a compensation transaction implementation method for a distributed database according to the present application;

[0054] Figure 4 A three-phase commit participant state transition flow chart of a compensation transaction implementation method for a distributed database according to the present application;

[0055] Figure 5 A system architecture diagram of a compensation transaction implementation system for a distributed database according to the present application. DETAILED DESCRIPTION

[0056] In order to make the technical means, creative features, purposes and effects achieved by the present application easy to understand, in the description of the present application, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and therefore cannot be understood as indicating or implying that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application. In addition, the terms "No. 1", "No. 2", "No. 3" are only for the purpose of description, and cannot be understood as indicating or implying relative importance. The present application will be further described below in conjunction with the specific embodiments.

[0057] Embodiment 1

[0058] Please refer to Figures 1-4 The present application provides an embodiment: a compensation transaction implementation method for a distributed database, comprising the following steps:

[0059] Step S1: The client initiates a transaction request, determines whether the transaction SQL exceeds the limit value by executing the directory, and if it does, the backend database returns an error, and the transaction information is stored in the transaction SQL mapping module;

[0060] The four characteristics of a transaction include atomicity, consistency, isolation, and durability.

[0061] The predetermined limit values of the SQL statements of the transaction include: (1) execution time: the maximum execution time of the transaction is set, if the time exceeds, the transaction is considered to fail to complete within the limited time, which may return an error or roll back the transaction; (2) resource usage: the maximum limit of the resources used by the transaction during execution can be set; (3) data size; (4) concurrent access quantity.

[0062] The advantages of setting limit values for transaction SQL include: (1) the transaction can be ensured not to be disturbed by other transactions during execution, maintaining data consistency; (2) when an error occurs during transaction execution, the transaction can be rolled back to undo the executed operations, avoiding data inconsistency; (3) by setting the lock level and concurrent control mode of the transaction, the transaction isolation level and lock competition during concurrent access can be controlled, improving the performance and response time of the system; (4) data consistency can be restored by rolling back and committing the transaction; (5) the logical flow of the program can be controlled by setting the transaction.

[0063] Step S2: The coordination node assigns a timestamp to the transaction initiated by the client in step S1, and sends the operation of the transaction to the data node;

[0064] In a distributed database, the coordination node is a special node used to coordinate search and aggregation operations of shards. When a client sends a search request, the coordination node forwards the request to the data node storing the relevant shard and returns the result to the client. The coordination node does not store data and does not participate in data search.

[0065] Step S3: After receiving the transaction request, the data node determines whether to commit or roll back the transaction, and returns the execution result to the coordination node for confirmation and verification. If the verification fails, the coordination node notifies the data node and performs compensation operations;

[0066] Transaction rollback refers to undoing the update operation of the database that has been completed by the transaction. In a transaction, each correct atom is executed sequentially until an error occurs in the atomic operation.

[0067] Step S4: After the operation is completed, the coordination node commits the transaction and performs timed cleaning, returning the execution result to the client.

[0068] The steps of the timed cleaning performed by the coordination node are as follows:

[0069] (1) The coordination node first receives a query request and broadcasts the request to each data node. Each shard of the data node processes the query request, performs data query, and places the data meeting the conditions in a priority queue;

[0070] (2) Each shard returns the document ID, node information, and shard information to the coordination node after querying the data, and the coordination node aggregates all the results and performs global sorting;

[0071] (3) The coordination node sends a get request to the shard containing the document ID, and the corresponding shard returns the document data to the coordination node;

[0072] (4) Finally, the coordination node returns the data to the client.

[0073] The specific steps of step S1 include:

[0074] Step S101: Determine the directory path of the transaction execution and read the contained SQL script file;

[0075] Step S102: Analyze the content of the SQL script file to determine whether there is a SQL statement or operation that may cause the transaction to exceed the limit value and output the analysis result, according to which it is determined whether the SQL statement of the transaction exceeds the predetermined limit value;

[0076] Step S103: Start the transaction and monitor its execution, and if the transaction exceeds the limit value during execution, the backend database responds and returns an error immediately;

[0077] Step S104: Receive and process the error, and if the transaction is executed successfully, continue to process other transactions or close the connection.

[0078] The specific steps of step S2 include:

[0079] Step S201: The client sends a transaction request to the coordination node, and the coordination node receives and parses and processes the transaction request;

[0080] The specific steps include: (1) The coordination node first needs to parse the transaction request and extract the operation to be executed and the related parameters; (2) After parsing the transaction request, the coordination node needs to verify the legality of the operation; (3) Once the operation is verified as legal, the coordination node needs to assign the operation to the appropriate transaction participant node; (4) After assigning the operation to the participant, the coordination node needs to monitor the execution process of the transaction.

[0081] Step S202: The coordination node generates a globally unique timestamp according to the compensation rule and assigns the generated timestamp to the transaction initiated by the client in step S1;

[0082] Step S203: The coordination node forwards the generated timestamp to the relevant data node together with the transaction request.

[0083] The timestamp in step S202 specifically includes: transaction start time, transaction commit time and transaction rollback time.

[0084] In a distributed database, the generation and distribution of timestamps need to ensure global uniqueness and consistency to avoid conflicts and data inconsistency. Common timestamp generation methods include using physical clocks, distributed clock servers or generating pseudo-clocks through algorithms.

[0085] The specific steps of step S3 include:

[0086] Step S301: The data node receives the transaction request forwarded by the coordination node, sorts and executes according to the timestamp, and judges whether to read, write or other operation;

[0087] When executing timestamp sorting, the data to be sorted and the corresponding timestamp need to be passed to the sorting function, and the sorting function will arrange the data according to the ascending or descending order of the timestamp

[0088] Step S302: According to the judgment result, the data node reads or modifies the local data, and judges the state of the transaction;

[0089] Step S303: The data node judges that the transaction can be committed, then the operation result is persisted to the database, and the confirmation message is returned to the coordination node, if the transaction needs to be rolled back, the related operations executed before are cancelled, and the database is restored to the state before the transaction starts, then the confirmation message is returned to the coordination node;

[0090] Among them, the transaction commit and rollback transaction are stored in the corresponding transaction commit success mapping and transaction rollback mapping module. The transaction commit success mapping means mapping the result of the successful transaction commit to an object or system, and the specific steps include: determining the mapping object, defining the mapping rule, executing the mapping operation, verifying the mapping result and recording the mapping log; The transaction rollback mapping is a mechanism in the database management system, which is used to restore the database state to the state before the transaction starts when an error or exception occurs during transaction execution, and the specific steps include: error detection, rollback preparation, rollback log generation, rollback execution and transaction commit.

[0091] Step S304: After receiving the confirmation message of the data node, the coordination node verifies the operation result by using the three-phase commit strategy, and if the verification is passed, it means that the operation of the data node is successfully completed, and if the verification fails, it needs to be rolled back.

[0092] The three-phase commit strategy in step S304 is: a pre-commit phase is added between the preparation phase and the commit phase, so that the coordination node sends a pre-commit request to all participating nodes, and judges the commit or rollback operation according to the response of the participating nodes.

[0093] In the distributed database, common strategies include two-phase commit and three-phase commit. The present application selects the three-phase commit strategy, which can reduce the blocking problem caused by waiting for responses from all participating nodes. The three-phase commit includes:

[0094] (1) Preparation phase: the coordination node sends a ready request to all participating nodes and waits for responses from the participating nodes;

[0095] (2) Pre-commit phase: during the waiting process for responses from all participating nodes, the coordination node decides whether to perform a pre-commit operation according to the responses from the participating nodes. If all participating nodes return an "agree" response, the coordination node enters the commit phase; otherwise, the coordination node enters the rollback phase;

[0096] (3) Commit phase: after the pre-commit phase, if all participating nodes return an "agree" response, the coordination node sends a commit request to all participating nodes; after receiving the commit request, the participating nodes perform related operations and persist the results in the database; the coordination node waits for all participating nodes to complete the operations and return confirmation messages; after all participating nodes complete the operations and are confirmed and verified by the coordination node, the coordination node commits the transaction and returns a success result to the client.

[0097] The specific steps of the compensation operation in step S304 include:

[0098] Step S3041: determining the transaction that needs to be compensated and defining the compensation rule;

[0099] The transaction compensation rule includes: 1) determining the compensation point: determining the steps and states that need to be compensated during the transaction execution process, thereby determining the rollback range; 2) determining the rollback range; 3) generating the corresponding rollback command according to the rollback range and the compensation point; 4) executing the corresponding rollback operation according to the generated rollback command; 5) recording the information of the compensation operation to the compensation log; 6) checking whether the compensation result meets the expectation after executing the compensation operation; 7) notifying the related user or system of the result of the compensation operation.

[0100] Step S3042: according to the compensation rule, mapping the operation in the distributed transaction to the compensation operation through the transaction compensation mapping;

[0101] The compensation mapping refers to restoring the data to the state before the transaction starts by executing the compensation operation when the transaction fails or an abnormal situation occurs, so as to ensure the consistency and integrity of the data.

[0102] Step S3043: mapping the compensation execution state of each operation through the compensation execution flag;

[0103] The compensation execution flag mapping has the advantages that it can accurately record the result and state of each operation, so that the undo or recovery operation can be accurately performed when the transaction fails, ensuring the consistency of data, and by establishing the mapping relationship between the operation result and the execution flag, the compensation execution state is recorded by the compensation execution flag mapping.

[0104] The implementation of the compensation execution flag mapping comprises the following steps:

[0105] (1) generating a unique execution flag for each operation;

[0106] (2) establishing a mapping relationship between the execution flag and the operation result;

[0107] (3) recording the execution flag and the operation result during the transaction execution process;

[0108] (4) if a certain operation fails, the corresponding mapping relationship is found according to the execution flag, and then the completed operation is undone or recovered according to the mapping relationship;

[0109] (5) all operations are successfully completed, or the compensation operation has been performed, the transaction is ended and the client is notified.

[0110] Step S3044: if the compensation operation is successfully executed, the database is committed, and the commit state of each operation is recorded by the commit success mapping.

[0111] The compensation rules in step S3041 include: reverse operation, data repair, transaction rollback, state recovery, sequential execution, repeatability and consistency guarantee.

[0112] The commit mode of the compensation operation includes: direct commit, asynchronous commit and timing commit.

[0113] The specific steps of step S4 include:

[0114] Step S401: after receiving the responses of all participating nodes, the coordinator node confirms that all operations have been completed;

[0115] Step S402: the coordinator node commits the transaction to the database or the distributed transaction manager, and records the commit state by the commit success mapping;

[0116] Step S403: after confirming the successful transaction commit, the coordinator node performs the operation of cleaning up historical data and releasing resources at a timing;

[0117] Step S404: the result of the transaction processing is returned to the client.

[0118] Embodiment 2

[0119] Please refer to Figure 5In another embodiment, the application provides a distributed database-oriented compensation transaction implementation system, comprising:

[0120] a transaction SQL mapping module, a transaction commit success mapping module, a transaction rollback mapping module, a compensation Tmp mapping module, a compensation mapping module, and a compensation execution flag mapping module,

[0121] The transaction SQL mapping module is configured to determine whether the transaction SQL exceeds an upper limit or a commit limit value.

[0122] The transaction commit success mapping module is configured to record the transaction mapping of the distributed transaction commit success, and clean up the data when there is a timing task.

[0123] The transaction rollback mapping module is configured to record the rollback distributed transaction, and clean up the data therein when there is a timing task.

[0124] The compensation Tmp mapping module is configured to record the temporary node transaction to be compensated.

[0125] The compensation mapping module is configured to record the node transaction to be compensated.

[0126] The compensation execution flag mapping module is configured to mark that a certain node is compensating a transaction.

[0127] The embodiments of the application are described above with reference to the drawings, but the application is not limited to the above-described specific embodiments, which are merely illustrative rather than restrictive, and those of ordinary skill in the art can make many forms under the inspiration of the application without departing from the purpose of the application and the scope protected by the claims.

Claims

1. A method for compensating transaction implementation for a distributed database, characterized in that, The application comprises the following steps: Step S1: the client initiates a transaction request, determines whether the transaction SQL exceeds the limit value by executing a directory, and if so, the backend database returns an error, while the transaction information is stored in the transaction SQL mapping module; Step S2: the coordination node allocates a timestamp for the transaction initiated by the client in step S1, and sends the operation of the transaction to the data node; Step S3: the data node receives the transaction request, determines whether to submit or rollback the transaction, and returns the execution result to the coordination node for confirmation and verification, if the verification fails, the coordination node notifies the data node and performs a compensation operation; Step S4: after the operation is completed, the coordination node submits the transaction and performs a timing cleanup, and returns the execution result to the client; The specific steps of step S2 comprise: Step S201: the client sends a transaction request to the coordination node, and the coordination node receives the transaction request and parses and processes it; Step S202: the coordination node generates a globally unique timestamp according to the compensation rule, and allocates the generated timestamp to the transaction initiated by the client in step S1; Step S203: the coordination node forwards the generated timestamp to the relevant data node together with the transaction request; The specific steps of step S3 comprise: Step S301: the data node receives the transaction request forwarded by the coordination node, sorts and executes according to the timestamp, and determines whether to read, write or perform other operations; Step S302: according to the determination result, the data node reads or modifies the local data, and determines the state of the transaction; Step S303: the data node determines that the transaction can be submitted, then the operation result is persisted to the database, and an acknowledgement message is returned to the coordination node, if the transaction needs to be rolled back, the related operations performed before are cancelled, and the database is restored to the state before the transaction starts, then an acknowledgement message is returned to the coordination node; Step S304: after receiving the acknowledgement message from the data node, the coordination node verifies the operation result by using the three-phase commit strategy, if the verification is passed, it means that the operation of the data node is successfully completed, if the verification fails, it needs to be rolled back.

2. The method of claim 1, wherein the method further comprises: receiving a request to perform a compensating transaction; and performing the compensating transaction. The specific steps of step S1 comprise: Step S101: determine the directory path of the transaction execution and read the SQL script file contained; Step S102: analyze the content of the SQL script file to determine whether there is a SQL statement or operation that may cause the transaction to exceed the limit value and output the analysis result, according to the analysis result, determine whether the SQL statement of the transaction exceeds the predetermined limit value; Step S103: start the transaction and monitor its execution, if the transaction exceeds the limit value during execution, the backend database responds and returns an error immediately; Step S104: receive the error and process it, if the transaction is executed successfully, continue to process other transactions or close the connection.

3. The method for compensating transaction implementation oriented to distributed database according to claim 2, characterized in that, The timestamp in step S202 specifically comprises: transaction start time, transaction commit time and transaction rollback time.

4. The method of claim 3, wherein, The three-phase commit strategy in the step S304 is specifically: a pre-commit phase is added between the preparation phase and the commit phase, so that the coordination node sends a pre-commit request to all participating nodes, and judges the commit or rollback operation according to the response of the participating nodes.

5. The compensation transaction implementation method for distributed databases as described in claim 4, characterized in that, The specific steps of the compensation operation in the step S3 include: Step S3041: determining the transaction that needs to be compensated, and defining a compensation rule; Step S3042: according to the compensation rule, mapping the operation in the distributed transaction to a compensation operation through a transaction compensation mapping; Step S3043: recording the compensation execution state of each operation through a compensation execution flag mapping; Step S3044: if the compensation operation is executed successfully, committing the database, and recording the commit state of each operation through a commit success mapping.

6. The method of claim 5, wherein the method further comprises: The compensation rule in the step S3041 includes: reverse operation, data repair, transaction rollback, state recovery, sequential execution, repeatability and consistency guarantee.

7. The compensation transaction implementation method for distributed databases as described in claim 6, characterized in that, The specific steps of the step S4 include: Step S401: after the coordination node receives the responses of all participating nodes, confirming that all operations have been completed; Step S402: the coordination node commits the transaction to the database or the distributed transaction manager, and records the commit state through a commit success mapping; Step S403: after confirming the success of the transaction commit, the coordination node performs a resource release operation by cleaning up historical data at a regular time; Step S404: returning the result of the transaction processing to the client.

8. The method of claim 7, wherein, It includes: a transaction SQL mapping module, a transaction commit success mapping module, a transaction rollback mapping module, a compensation Tmp mapping module, a compensation mapping module, and a compensation execution flag mapping module, The transaction SQL mapping module is used to judge whether the transaction SQL exceeds the upper limit or the commit limit value; The transaction commit success mapping module is used to record the transaction mapping of the successful distributed transaction commit, and clean up the data when there is a timing task; The transaction rollback mapping module is used to record the rolled back distributed transaction, and clean up the data therein when there is a timing task; The compensation Tmp mapping module is used to record the temporary node transaction to be compensated; The compensation mapping module is used to record the node transaction to be compensated; The compensation execution flag mapping module is used to mark that a node is compensating a transaction.

Images