A database-based distributed transaction fuse recovery method, device and medium

Abstract

The embodiment of the specification discloses a database-based distributed transaction fuse recovery method and device and medium, relates to the technical field of fuse decision-making, and is used for solving the problem of high false fuse rate and poor breakpoint continuation of existing breakpoint continuation. The method comprises the following steps: receiving a current intercepted SQL statement, generating a transaction fingerprint according to the current intercepted SQL statement; querying a preset Nacos configuration center for a fuse rule corresponding to the transaction fingerprint, and determining whether to trigger the fuse rule according to a transaction execution index corresponding to the current database transaction; if yes, writing the intermediate state of the current database transaction into a message queue data structure of a Redis database, and obtaining a corresponding identifier; adding the transaction fingerprint and the identifier into a fuse event corresponding to the fuse rule, so that a postgreSql database listens to the fuse event, and reads the Redis database intermediate state according to the transaction fingerprint and the identifier to perform breakpoint execution.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of distributed transaction fusing, and particularly relates to a database-based distributed transaction fusing recovery method, device and medium. BACKGROUND

[0002] In today's distributed system, especially the microservice architecture has become mainstream. A business request often needs to cross multiple services and multiple database instances to complete, which inevitably uses distributed transactions to ensure data consistency. However, the database resources in the distributed environment become shared and limited resources. At this time, when a target database has an exception, a slow response or resource exhaustion, in order to release the database resources, distributed transaction fusing is very important to ensure system availability and flexibility.

[0003] In the distributed transaction fusing scenario, the prior art has the problems of insufficient fusing precision, frequent reconstruction of database connections, waste of server resources, and impact on system throughput. Moreover, after fusing, the transaction breakpoint state cannot be accurately restored. At the same time, if the system is restarted during the fusing process, the transaction execution position before fusing cannot be quickly and accurately located. Because the fusing strategy only depends on the system load threshold, it cannot identify the specific SQL transaction characteristics, so it cannot distinguish between key transactions and non-key transactions, resulting in a high false fusing rate and affecting the continuity of core business. Moreover, because the transaction state is not stored across components, the system state cannot be traced after a system crash, and the transaction compensation operation needs to be completely re-executed. SUMMARY

[0004] To solve the above technical problems, one or more embodiments of the present specification provide a database-based distributed transaction fusing recovery method, device and medium.

[0005] One or more embodiments of the present specification adopt the following technical solutions:

[0006] One or more embodiments of the present specification provide a database-based distributed transaction fusing recovery method, which specifically includes:

[0007] The transaction fingerprint engine receives a current intercepted SQL statement to generate a transaction fingerprint according to the current intercepted SQL statement; wherein the current intercepted SQL statement is obtained by intercepting during the execution of the current database transaction by pre-setting AOP programming;

[0008] Query the fusing rule corresponding to the transaction fingerprint in the pre-set Nacos configuration center, and determine whether to trigger the fusing rule according to the transaction execution index corresponding to the current database transaction;

[0009] If yes, a message queue data structure corresponding to an intermediate state of the current database transaction is obtained from a Redis database, and an identifier corresponding to the message queue data structure is determined;

[0010] The transaction fingerprint and the identifier are added to a fuse event corresponding to the fuse rule, so that a postgreSql database listens to the fuse event, reads the Redis database intermediate state according to the transaction fingerprint and the identifier, and performs breakpoint execution based on the intermediate state.

[0011] Optionally, in one or more embodiments of the present specification, a current intercepted SQL statement is received by a preset transaction fingerprint engine to generate a transaction fingerprint according to the current intercepted SQL statement, specifically comprising:

[0012] A current intercepted SQL statement is received by a preset transaction fingerprint engine to perform standardization processing on the current intercepted SQL statement, and key elements of the current intercepted SQL statement are obtained; wherein the key elements include an operation type and a target table name;

[0013] The key elements are hashed to obtain corresponding hash values, and the corresponding hash values are truncated based on a preset data length to obtain digest data;

[0014] The key elements and the digest data are combined to obtain a transaction fingerprint generated by the current intercepted SQL statement.

[0015] Optionally, in one or more embodiments of the present specification, before the current intercepted SQL statement is received by the preset transaction fingerprint engine to generate the transaction fingerprint according to the current intercepted SQL statement, the method further comprises:

[0016] According to a preset fuse rule, an exception interception component corresponding to each fuse rule is obtained;

[0017] Real-time monitoring of SQL statements determines whether the SQL statements correspond to database operations;

[0018] If yes, the exception return of the database operation is captured based on the exception interception component, and the SQL statement corresponding to the exception return is obtained as a current intercepted SQL statement.

[0019] Optionally, in one or more embodiments of the present specification, the fuse rule corresponding to the transaction fingerprint in the preset Nacos configuration center is queried, and whether the fuse rule is triggered is determined according to a transaction execution index corresponding to the current database transaction, specifically comprising:

[0020] determining a SQL operation type of the current intercepted SQL statement according to the transaction fingerprint, to determine a configuration storage area corresponding to the SQL operation type in a preset Nacos configuration center;

[0021] querying a local cache area corresponding to the Nacos configuration center, to determine whether a corresponding fuse rule exists for the transaction fingerprint;

[0022] If not, querying the configuration storage area for the corresponding fuse rule for the transaction fingerprint;

[0023] analyzing the corresponding fuse rule, to determine a decision parameter threshold corresponding to the corresponding fuse rule;

[0024] comparing a transaction execution index corresponding to the current database transaction with the decision parameter threshold, to determine whether to trigger the fuse rule for fusing.

[0025] Optionally, in one or more embodiments of the present specification, the method further comprises:

[0026] obtaining an executed SQL sequence corresponding to the current database transaction, and sequentially organizing the executed SQL sequence to obtain an executed SQL list;

[0027] obtaining a parameter value of each SQL statement in the executed SQL sequence and a breakpoint index position of the current intercepted SQL statement in the executed SQL sequence;

[0028] determining an intermediate state corresponding to the current database transaction according to the executed SQL list, the parameter value, and the breakpoint index position;

[0029] writing the intermediate state into a message queue data structure of a Redis database based on a preset addition command, to obtain an identifier corresponding to the message queue data structure returned by the preset addition command; wherein the intermediate states corresponding to the same type of current database transaction correspond to the same message queue data structure.

[0030] Optionally, in one or more embodiments of the present specification, after the method further comprises:

[0031] sending the transaction fingerprint and the identifier to the postgreSql database through an asynchronous event notification, so that the postgreSql database disconnects a database connection resource corresponding to the current database transaction according to the transaction fingerprint and the identifier.

[0032] Optionally, in one or more embodiments of the present specification, the transaction fingerprint and the identifier are added to a fuse event corresponding to the fuse rule, so that the postgreSql database listens to the fuse event and reads an intermediate state of the Redis database according to the transaction fingerprint and the identifier, and performs breakpoint execution based on the intermediate state, specifically including:

[0033] adding the transaction fingerprint and the identifier to a fuse event corresponding to the fuse rule, so as to listen to a specified notification channel of the postgreSql database through a preset event listening component;

[0034] If the postgreSql database listens to the fuse event, the fuse event is parsed based on the preset event listening component to obtain the transaction fingerprint and the identifier corresponding to the fuse event;

[0035] reading an intermediate state of the Redis database according to the transaction fingerprint and the identifier, so as to perform breakpoint execution according to parameter values of the SQL statement at the breakpoint index position to complete breakpoint resumption.

[0036] Optionally, in one or more embodiments of the present specification, after reading the intermediate state of the Redis database according to the transaction fingerprint and the identifier and performing breakpoint execution based on the intermediate state, the method further includes:

[0037] scanning a message queue data structure of the Redis database through a preset period to obtain completed database transactions and survival durations of each database transaction;

[0038] comparing the survival durations of each database transaction with a preset cleaning duration to determine a database transaction to be cleaned;

[0039] cleaning and deleting the intermediate state corresponding to the completed database transaction and the database transaction to be cleaned.

[0040] One or more embodiments of the present specification provide a database-based distributed transaction fuse recovery device, which includes:

[0041] at least one processor; and

[0042] a memory in communication connection with the at least one processor; wherein

[0043] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform any of the methods described above.

[0044] The one or more embodiments of the specification provide a non-volatile computer storage medium storing computer executable instructions configured to enable the execution of any of the methods described above.

[0045] The above at least one technical solution adopted by the embodiments of the specification can achieve the following beneficial effects:

[0046] By presetting the transaction fingerprint engine to process the intercepted SQL statement to generate a unique transaction fingerprint, the characteristics of different SQL transactions can be accurately distinguished. In combination with the fuse rule bound with the transaction fingerprint in the Nacos configuration center, the one-size-fits-all problem caused by the traditional technology of relying only on the system load threshold is avoided, ensuring that only specific transactions that meet the rules trigger the fuse, reducing the false fuse of the core business, and thus ensuring the continuity of the core business. The transaction intermediate state is stored in the message queue data structure of the Redis database, and the postgreSQL database directly listens to the fuse event, reads the intermediate state to perform breakpoint execution, so that the fuse recovery process can recover the transaction without rebuilding the connection, reducing the resource consumption of connection rebuilding. Moreover, the transaction intermediate state is stored in Redis, and the transaction fingerprint and the intermediate state identifier are associated through the fuse event and are listened to by the database, realizing the cross-component storage of the transaction state. BRIEF DESCRIPTION OF DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the specification or the prior art, the drawings needed to be used in the embodiment or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments described in the specification, and those skilled in the art can also obtain other drawings according to these drawings without creative labor. In the drawings:

[0048] Figure 1 A flowchart of a database-based distributed transaction fuse recovery method provided by the embodiments of the specification is shown in the figure;

[0049] Figure 2 A flowchart of a database-based distributed transaction fuse recovery method provided by the embodiments of the specification is shown in the figure;

[0050] Figure 3 A flowchart of a database-based distributed transaction fuse recovery method provided by the embodiments of the specification is shown in the figure;

[0051] Figure 4 This is a timing diagram illustrating a transaction fingerprint recognition application scenario provided in an embodiment of this specification.

[0052] Figure 5 A schematic diagram illustrating breakpoint continuation in a distributed transaction circuit breaker under an application scenario provided in this specification embodiment;

[0053] Figure 6 This is a schematic diagram illustrating the state of a cleanup mechanism in an application scenario provided by an embodiment of this specification.

[0054] Figure 7 A schematic diagram of a database-based distributed transaction circuit breaker recovery device provided in the embodiments of this specification;

[0055] Figure 8 This is a schematic diagram of the structure of a non-volatile storage medium provided in the embodiments of this specification. Detailed Implementation

[0056] This specification provides a database-based distributed transaction circuit breaker recovery method, device, and medium.

[0057] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0058] like Figure 1 As shown in the diagram, this specification provides a flowchart illustrating a database-based distributed transaction circuit breaker recovery method. Figure 1 As can be seen, in one or more embodiments of this specification, a database-based distributed transaction circuit breaker recovery method specifically includes the following steps:

[0059] S101: Receive the currently intercepted SQL statement through the pre-configured transaction fingerprint engine, and generate a transaction fingerprint based on the currently intercepted SQL statement; wherein, the currently intercepted SQL statement is intercepted by the pre-configured AOP programming during the execution of the current database transaction.

[0060] To achieve precise circuit breaker recovery and provide a foundation for transaction tracing in distributed systems or complex business scenarios, this specification's embodiments utilize a pre-configured transaction fingerprint engine to receive the currently intercepted SQL statement and generate a transaction fingerprint based on it. For example... Figure 3As shown, the current intercepted SQL statement is obtained by presetting AOP programming to intercept during execution of the current database transaction.

[0061] Further, in one or more embodiments of the present specification, before receiving the current intercepted SQL statement by the preset transaction fingerprint engine to generate a transaction fingerprint according to the current intercepted SQL statement, the method further comprises:

[0062] According to the preset fuse rule such as a specific error type, a high-frequency failure threshold, a performance timeout threshold, etc., an exception interception component corresponding to each fuse rule is obtained. That is, each fuse rule is bound to a corresponding exception interception component for capturing and processing a specific type of exception, such as a special network exception interception component bound to a fuse rule for connection timeout, and a transaction conflict interception component bound to a rule for deadlock. Then, the SQL statement is monitored in real time, so as to determine whether the SQL statement corresponds to a database operation through syntax analysis or context analysis of the monitored SQL statement. If it corresponds to a database operation, then the exception interception component captures the exception return of the database operation, such as: execution failure, dampness, and lock conflict, etc. Further, the SQL statement corresponding to the exception return is obtained as the current intercepted SQL statement.

[0063] In this process, the exception SQL that triggers the fuse rule is intercepted, so that the transaction fingerprint engine focuses more on the database operation that may have risks, providing a precise analysis object for subsequent exception diagnosis and transaction optimization. Moreover, by identifying the database operation type, the database SQL or invalid instruction is obtained, reducing the effect of irrelevant data entering the fingerprint engine and reducing the computing resources. At the same time, the combination of exception interception and preset fuse rule can achieve precise capture at the initial stage of transaction execution, providing a basis for subsequent fuse processing, and avoiding the spread of exceptions.

[0064] Specifically, in one or more embodiments of the present specification, the current intercepted SQL statement is received by the preset transaction fingerprint engine to generate a transaction fingerprint according to the current intercepted SQL statement, specifically comprising:

[0065] The current intercepted SQL statement is received by the preset transaction fingerprint engine to perform standardized processing on the current intercepted SQL statement to remove redundant spaces, comments, dynamic parameter values, and other non-key information, and to obtain key elements of the current intercepted SQL statement; wherein the key elements include: operation type and target table name. Among them, for example, Figure 4The illustrated standardization processing can be processed by the code "UPDATE accounts SET balance=100 WHERE id=1→UPDATE accounts SETbalance=? WHERE id=?" to remove variables and spaces. Then, the key elements are hashed to obtain the corresponding hash value, and the corresponding hash value is truncated according to the preset data length to obtain the digest data. That is, the key elements obtained after standardization are MD5 hashed to obtain the corresponding hash value, and the first four bits of the corresponding hash value are taken to obtain the digest data such as 8a3f. The key elements and the digest data obtained are combined to obtain the transaction fingerprint of the current intercepted SQL statement. That is, a unique identifier is generated in the operation type_table name_digest format, for example, UPDATE_accounts_8a3f, as the transaction fingerprint of the current intercepted SQL statement.

[0066] The transaction fingerprint generated in this way contains both the key elements and the hash digest, which retains the intuitive transaction nature and ensures uniqueness through the digest, and takes into account readability and identification. Only the core elements of the SQL statement are hashed, which greatly reduces the computational load, and further truncating the digest by fixed length avoids the increase in storage and transmission costs caused by too long fingerprint data.

[0067] S102: Query the preset Nacos configuration center for the corresponding breaking rule of the transaction fingerprint, and determine whether to trigger the breaking rule according to the transaction execution index corresponding to the current database transaction.

[0068] In order to be able to release database resources actively in the case of abnormality, slow response or resource exhaustion, the preset Nacos configuration center is queried for the breaking rule corresponding to the transaction fingerprint, so as to determine whether to trigger the breaking rule according to the transaction execution index corresponding to the current database transaction. Specifically, in one or more embodiments of the present specification, the preset Nacos configuration center is queried for the breaking rule corresponding to the transaction fingerprint, and whether to trigger the breaking rule is determined according to the transaction execution index corresponding to the current database transaction, specifically including the following processes:

[0069] The transaction fingerprint generated according to the above step S101 determines the SQL operation type of the current intercepted SQL statement, thereby determining the configuration storage area corresponding to the SQL operation type in the preset Nacos configuration center. Then, the local cache area corresponding to the Nacos configuration center is queried to determine whether the corresponding fuse rule of the transaction fingerprint exists. If not, the fuse rule corresponding to the transaction fingerprint is queried in the configuration storage area. That is, the corresponding fuse rule is parsed to determine the decision parameter threshold corresponding to the corresponding fuse rule. The transaction execution index corresponding to the current database transaction is compared with the decision parameter threshold to determine whether the fuse rule is triggered to be fused. In this process, the two-level cache mechanism of local cache priority and Nacos center query is adopted, which reduces the frequent access to the remote configuration center, reduces the network delay and the pressure of the Nacos server, and improves the rule query efficiency. First, the configuration storage area is located through the SQL operation type, and then the rule is accurately matched based on the transaction fingerprint, which avoids the inefficient operation of full-scan configuration center, so that the scene with a large number of rules can be efficiently implemented.

[0070] S103: If yes, the intermediate state corresponding to the current database transaction is written into the message queue data structure of the Redis database, and the identifier corresponding to the message queue data structure is determined.

[0071] If it is determined that the fuse rule is triggered, the intermediate state corresponding to the current database transaction is written into the message queue data structure of the Redis database, i.e. the Redis Stream data structure, and the identifier Redis Stream ID corresponding to the message queue data structure is determined. Specifically, in one or more embodiments of the present specification, the intermediate state corresponding to the current database transaction is written into the message queue data structure of the Redis database, and the identifier corresponding to the message queue data structure is determined, specifically including:

[0072] The executed SQL sequence corresponding to the current database transaction is obtained, and the executed SQL sequence is sequentially organized to obtain an executed SQL list. The parameter values of the current intercepted SQL statement and each SQL statement in the executed SQL sequence triggering the fuse rule, and the breakpoint index position of the current intercepted SQL statement in the executed SQL sequence are obtained. Thus, according to the executed SQL list, the parameter values and the breakpoint index position, the intermediate state corresponding to the current database transaction is determined. That is, as Figure 4As shown, the intermediate state contains three original fields: sql_sequence is a JSON array corresponding to the executed SQL list, param_snapshot is a Base64 encoded parameter, and breakpoint is an integer breakpoint position. Then, the intermediate state is written into the message queue data structure of the Redis database based on the preset addition command, so as to obtain the message queue data structure corresponding to the identification Redis Stream ID returned by the preset addition command. Among them, the intermediate states corresponding to the same type of current database transaction correspond to the same message queue data structure. In this process, by obtaining the intermediate state corresponding to the current database transaction, complete basis is provided for retry, rollback or compensation after transaction breaking, and the recoverability of the business is ensured.

[0073] Further, since the transaction is broken and the database connection is not released in time, the connection pool resource may be exhausted, so in one or more embodiments of the present specification, after the intermediate state corresponding to the current database transaction is written into the message queue data structure of the Redis database and the identification corresponding to the message queue data structure is determined, the method further includes the following process:

[0074] Extract the transaction fingerprint of the current transaction and the unique identification of the Redis message queue, and pack the two types of information as event notification content. Send to the postgreSql database through the asynchronous event mechanism, so that the postgreSql database receives the event notification, matches the corresponding database connection according to the transaction fingerprint, and then verifies that the intermediate state of the transaction has been correctly stored in combination with the Redis identification, and then disconnects the database connection resource corresponding to the current database transaction, and realizes the release of the connection resource. Adopting the asynchronous event notification mechanism avoids blocking the main business process of the operation of releasing the connection. And triggering the release of the connection through asynchronous notification ensures that the idle connection is quickly recycled, and the availability of the database connection pool is guaranteed. The intermediate state has been stored through the Redis identification before the release of the connection, which not only ensures the recycling of resources, but also retains complete state data for subsequent retry or rollback of the transaction.

[0075] S104: The transaction fingerprint and the identification are added to the breaking event corresponding to the breaking rule, so that the postgreSql database listens to the breaking event, reads the Redis database intermediate state according to the transaction fingerprint and the identification, and performs breakpoint execution based on the intermediate state.

[0076] In order to utilize the uniqueness of the transaction fingerprint and the persistence characteristics of the Redis streaming storage, the precise breakpoint recovery is realized to reduce the mis-fusing rate under the premise of ensuring the consistency of the transaction. In the embodiments of the present specification, the transaction fingerprint and the identifier are added to the fuse event corresponding to the fuse rule, so as to facilitate the postgreSql database to listen to the fuse event, and read the intermediate state in the Redis database according to the transaction fingerprint and the identifier, and perform the breakpoint based on the intermediate state. In this process, since the intermediate state is stored in Redis, the transaction fingerprint and the intermediate state identifier are associated through the fuse event and are listened to by the database, realizing the cross-component storage of the transaction state. Even if the system is restarted after a system crash, the postgreSQL database can read the intermediate state from Redis through the transaction fingerprint and the identifier, quickly locate the transaction execution position before the fuse, and does not need to completely re-execute the transaction compensation operation as in the traditional technology, thereby reducing the resource consumption caused by invalid operations.

[0077] Specifically, as shown in the present specification one or more embodiments, the transaction fingerprint and the identifier are added to the fuse event corresponding to the fuse rule, so as to facilitate the postgreSql database to listen to the fuse event, and read the intermediate state in the Redis database according to the transaction fingerprint and the identifier, and perform the breakpoint based on the intermediate state. In this process, since the intermediate state is stored in Redis, the transaction fingerprint and the intermediate state identifier are associated through the fuse event and are listened to by the database, realizing the cross-component storage of the transaction state. Even if the system is restarted after a system crash, the postgreSQL database can read the intermediate state from Redis through the transaction fingerprint and the identifier, quickly locate the transaction execution position before the fuse, and does not need to completely re-execute the transaction compensation operation as in the traditional technology, thereby reducing the resource consumption caused by invalid operations. Figure 2

[0078] As shown in Figure 2 and Figure 3 , first, the transaction fingerprint and the identifier are added to the fuse event corresponding to the fuse rule, so as to listen to the specified notification channel of the postgreSql database through the preset event listening component. That is, the transaction fingerprint and the Redis message queue identifier are encapsulated into the fuse event corresponding to the current fuse rule. At the same time, the system continuously listens to the specified notification channel of the PostgreSQL database through the preset event listening component, and waits for the trigger signal of the fuse event. If the postgreSql database listens to the fuse event, the event processing process will be triggered as shown in Figure 5 , at this time, the fuse event is parsed according to the preset event listening component, and the transaction fingerprint and the identifier corresponding to the fuse event are obtained. Then, the intermediate state in the Redis database is read according to the transaction fingerprint and the identifier, so as to perform the breakpoint execution according to the parameter value of the SQL statement at the breakpoint index position, and make the transaction recover from the fuse interruption state to the normal execution state.

[0079] As shown in Figure 5 ​As shown in the application scenario, the system receives a string containing a transaction fingerprint and a Redis Stream ID separated by a colon. The transaction fingerprint is used to uniquely identify the transaction, and the Stream ID is used to locate the transaction state stored in Redis. According to the transaction fingerprint and the Stream ID, the intermediate state data of the transaction is queried from Redis. These data include the list of SQL statements that have been executed, parameter snapshots, and the breakpoint position at which execution was interrupted. Starting from the recorded breakpoint position, the remaining SQL statements are executed in sequence to complete the previously interrupted transaction. The previously saved parameter snapshots are directly used during execution to ensure that the transaction can be correctly restored. The key to the entire process is to quickly locate the transaction fingerprint, use the intermediate state saved by Redis persistence, achieve accurate recovery, and avoid the need to rebuild the transaction context in traditional solutions. The recovery process is fully automated, without human intervention and high efficiency.

[0080] Further, as Figure 6 shown in one or more embodiments of the present specification, after reading the Redis database intermediate state according to the transaction fingerprint and the identification, and based on the intermediate state after breakpoint execution, the method further comprises:

[0081] Since the intermediate state data is stored for a long time, it will occupy the Redis memory space, especially in the high-frequency transaction scenario, which may cause memory overflow. Therefore, in order to release the storage space and avoid resource waste, the message queue data structure of the Redis database is periodically scanned every 24 hours as Figure 6 shown, the completed database transactions and the survival time of each database transaction are obtained. By comparing the survival time of each database transaction with the preset cleaning time, such as Figure 6 24 hours as shown, the database transactions to be cleaned are determined, that is, the database transactions whose survival time exceeds the preset cleaning time are determined as the database transactions to be cleaned. The intermediate states corresponding to the completed database transactions and the database transactions to be cleaned are cleaned and deleted. After removing the completed or expired intermediate states, the amount of data in the Redis message queue is reduced, the scanning and matching speed when reading the effective intermediate state is faster, and the overall performance of the system is improved. And only cleaning completed transactions and overdue transactions, retaining effective intermediate states that may still need to be resumed, balances cleaning efficiency and business availability.

[0082] As Figure 7 shown, the present specification provides a structural diagram of a database-based distributed transaction fuse recovery device. As Figure 7 can be seen, in one or more embodiments of the present specification, a database-based distributed transaction fuse recovery device, the device comprises:

[0083] at least one processor; and

[0084] a memory communicatively connected with the at least one processor; wherein

[0085] the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform any of the methods described above.

[0086] As shown in Figure 8 the present specification provides a structural schematic diagram of a non-volatile storage medium. It can be known from Figure 8 in one or more embodiments of the present specification, a non-volatile storage medium stores computer executable instructions 801, and the computer executable instructions 801 can perform any of the methods described above.

[0087] Each of the embodiments in the present specification is described in a progressive manner, and the same or similar parts between each embodiment can be referred to each other. Each embodiment focuses on the difference from other embodiments. In particular, for the device, equipment and non-volatile computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiment.

[0088] The above describes a specific embodiment of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different than the order in the embodiments and still achieve the desired result. In addition, the processes depicted in the figures do not necessarily require the particular order shown or sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous or possible.

[0089] The above only describes one or more embodiments of the present specification and does not limit the present specification. For those skilled in the art, one or more embodiments of the present specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. within the spirit and principles of one or more embodiments of the present specification shall be included in the scope of claims of the present specification.

Claims

1. A database-based distributed transaction circuit breaking recovery method, characterized in that, The method includes: The system receives the currently intercepted SQL statement through a pre-configured transaction fingerprint engine, and generates a transaction fingerprint based on the currently intercepted SQL statement; wherein the currently intercepted SQL statement is obtained by pre-configured AOP programming during the execution of the current database transaction; Query the circuit breaker rules corresponding to the transaction fingerprint in the preset Nacos configuration center, and determine whether to trigger the circuit breaker rules based on the transaction execution indicators corresponding to the current database transaction; If so, the intermediate state corresponding to the current database transaction is obtained and written into the message queue data structure of the Redis database, and the identifier corresponding to the message queue data structure is determined. The transaction fingerprint and identifier are added to the circuit breaker event corresponding to the circuit breaker rule, so that the PostgreSQL database can listen to the circuit breaker event, read the intermediate state of the Redis database according to the transaction fingerprint and the identifier, and perform breakpoint execution based on the intermediate state; Obtaining the intermediate state corresponding to the current database transaction includes: Obtain the executed SQL sequence corresponding to the current database transaction, and organize the executed SQL sequence sequentially to obtain an executed SQL list; Obtain the parameter values ​​of the currently intercepted SQL statement that triggered the circuit breaker rule and each SQL statement in the executed SQL sequence, as well as the breakpoint index position of the currently intercepted SQL statement in the executed SQL sequence; Based on the list of executed SQL statements, the parameter values, and the breakpoint index positions, the intermediate state corresponding to the current database transaction is determined.

2. The database-based distributed transaction break recovery method according to claim 1, characterized in that, The system receives the currently intercepted SQL statement through a pre-configured transaction fingerprint engine, and generates a transaction fingerprint based on the currently intercepted SQL statement, specifically including: The intercepted SQL statement is received through a pre-configured transaction fingerprint engine, and the intercepted SQL statement is standardized to obtain the key elements of the intercepted SQL statement; wherein, the key elements include: operation type and target table name; The key elements are hashed to obtain corresponding hash values, and the corresponding hash values ​​are truncated based on a preset data length to obtain summary data; Based on the combination of the key elements and the summary data, the transaction fingerprint of the currently intercepted SQL statement is obtained.

3. The database-based distributed transaction circuit breaker recovery method of claim 1, wherein, Before receiving the currently intercepted SQL statement through a pre-configured transaction fingerprint engine and generating a transaction fingerprint based on the currently intercepted SQL statement, the method further includes: Based on the preset circuit breaker rules, obtain the exception interception components corresponding to each circuit breaker rule; Real-time monitoring of SQL statements to determine whether the SQL statement corresponds to a database operation; If so, the exception return of the database operation is captured based on the exception interception component, and the SQL statement corresponding to the exception return is obtained as the current intercepted SQL statement.

4. The database-based distributed transaction circuit breaker recovery method of claim 1, wherein, Query the circuit breaker rules corresponding to the transaction fingerprint in the preset Nacos configuration center, and determine whether to trigger the circuit breaker rule based on the transaction execution metrics corresponding to the current database transaction. Specifically, this includes: determining a SQL operation type of the current intercepted SQL statement according to the transaction fingerprint, to determine a configuration storage area corresponding to the SQL operation type in a preset Nacos configuration center; querying a local cache area corresponding to the preset Nacos configuration center, to determine whether there is a corresponding breaking rule corresponding to the transaction fingerprint; if not, querying the breaking rule corresponding to the transaction fingerprint in the configuration storage area; analyzing the corresponding breaking rule to determine a decision parameter threshold corresponding to the corresponding breaking rule; comparing a transaction execution index corresponding to the current database transaction with the decision parameter threshold, to determine whether to trigger the breaking rule to break.

5. The database-based distributed transaction circuit breaker recovery method of claim 1, wherein, acquiring an intermediate state corresponding to the current database transaction and writing the intermediate state into a message queue data structure of a Redis database, and determining an identifier corresponding to the message queue data structure, specifically comprising: writing the intermediate state into the message queue data structure of the Redis database based on a preset addition command, and obtaining an identifier corresponding to the message queue data structure returned by the preset addition command; wherein the intermediate states corresponding to the same type of current database transaction correspond to the same message queue data structure.

6. The database-based distributed transaction circuit breaker recovery method of claim 1, wherein, After acquiring the intermediate state corresponding to the current database transaction and writing the intermediate state into the message queue data structure of the Redis database, and determining the identifier corresponding to the message queue data structure, the method further comprises: sending the transaction fingerprint and the identifier to the postgreSql database through an asynchronous event notification, so that the postgreSql database disconnects a database connection resource corresponding to the current database transaction according to the transaction fingerprint and the identifier.

7. The database-based distributed transaction circuit breaker recovery method of claim 5, wherein, adding the transaction fingerprint and the identifier to a breaking event corresponding to the breaking rule, so that the postgreSql database listens to the breaking event, reads the Redis database intermediate state according to the transaction fingerprint and the identifier, and performs breakpoint execution based on the intermediate state, specifically comprising: adding the transaction fingerprint and the identifier to the breaking event corresponding to the breaking rule, to listen to a specified notification channel of the postgreSql database through a preset event listening component; if the postgreSql database listens to the breaking event, analyzing the breaking event based on the preset event listening component to obtain the transaction fingerprint and the identifier corresponding to the breaking event; reading the Redis database intermediate state according to the transaction fingerprint and the identifier, to perform breakpoint execution according to the parameter value of the SQL statement at the breakpoint index position to complete breakpoint continuation.

8. The database-based distributed transaction circuit breaker recovery method of claim 1, wherein, After reading the Redis database intermediate state according to the transaction fingerprint and the identifier, and performing breakpoint execution based on the intermediate state, the method further comprises: scanning the message queue data structure of the Redis database through a preset period, to obtain completed database transactions and survival time lengths of each database transaction; Compare the survival time length of each database transaction with the preset cleaning time length to determine the database transactions to be cleaned; Clean and delete the intermediate states corresponding to the completed database transactions and the database transactions to be cleaned.

9. A database-based distributed transaction circuit breaker recovery apparatus, characterized by, The device comprises: at least one processor; and a memory connected to the at least one processor in communication; wherein The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

10. A non-transitory storage medium storing computer-executable instructions, the computer-executable instructions comprising: The computer executable instructions can perform the method of any one of claims 1-8.

Images