Method and system for transparent access and traffic management of heterogeneous databases in a xinchuang environment

Abstract

The application discloses a method and system for transparent access and traffic management of heterogeneous databases in a Xinchuang environment. The method intercepts database access requests initiated by applications through an intelligent proxy gateway, identifies the underlying communication protocol type, extracts business feature information and encapsulates it as a unified request context. According to the unified request context and the preset routing strategy and traffic management strategy, the processing action decision for the request is determined, including allowing forwarding, flow limiting or fusing. According to the processing action decision, the corresponding processing is performed. The traffic management strategy further introduces the calculation of request semantic density, database transient pressure index and dynamic fuse offset factor, realizing adaptive flow limiting and smooth fuse based on semantic complexity and backend pressure. The application realizes unified access, dynamic routing and fine traffic management of domestic heterogeneous databases without modifying the application, improving the stability and scalability of the database system in the Xinchuang environment.

Description

Technical Field

[0001] This invention relates to the field of information technology innovation, and in particular to a method and system for transparent access and traffic management of heterogeneous databases in an information technology innovation environment. Background Technology

[0002] Currently, various domestically developed heterogeneous databases, such as DM, Kingbase, OceanBase, and TiDB, are deployed in the information technology application innovation environment. These databases typically use their own proprietary communication protocols, making them incompatible with each other. In actual business systems, applications need to access multiple databases simultaneously, but existing technical solutions usually employ the following methods: One approach is for the application to directly connect to each database instance via a database driver. In this approach, the application itself needs to implement connection management, rate limiting, circuit breaking, and other traffic governance capabilities for each database, resulting in strong coupling between the application code and the governance logic of specific databases. When it's necessary to adjust rate limiting thresholds or add circuit breaking policies, the application code must be modified and redeployed, leading to high operational costs.

[0003] Another approach is to configure parameters such as connection limits or query timeouts on the database instance side. However, this method only provides coarse-grained protection for a single database instance and cannot achieve unified traffic scheduling across databases. For example, when a database instance is overloaded, requests cannot be dynamically routed to other homogeneous instances; and when multiple databases face sudden traffic surges simultaneously, there is a lack of a global perspective for rate limiting and circuit breaking coordination mechanisms.

[0004] Furthermore, existing technologies lack a transparent proxy solution that can shield the differences between various domestic database protocols. Database access requests initiated by applications use different underlying protocols, making it difficult to implement a unified traffic management logic. Developing separate management functions for each protocol results in poor system scalability; a new management module needs to be developed for each new database.

[0005] In summary, existing technologies for accessing and managing traffic in heterogeneous databases under a domestically developed IT environment suffer from the following technical problems: strong coupling between application and database protocols makes it difficult to deploy governance logic uniformly; traffic governance strategies such as rate limiting, circuit breaking, and routing cannot be dynamically executed across database instances; and the lack of a protocol-independent unified request context makes it difficult to extend governance functions. These problems make database system operation and maintenance complex and unstable under a domestically developed IT environment, making it difficult to achieve efficient overload protection and fault isolation. Summary of the Invention

[0006] To address at least one of the above technical problems, embodiments of the present invention provide a method and system for transparent access and traffic management of heterogeneous databases in a domestic IT innovation environment.

[0007] On one hand, embodiments of the present invention provide a method for transparent access and traffic management of heterogeneous databases in a domestically developed information technology innovation environment, applicable to domestically produced heterogeneous databases in such environments. The method includes the following steps: Step 1: Intercept database access requests initiated by applications through a smart proxy gateway; identify the underlying communication protocol type of the database access request, including the native protocol of domestic databases; extract business feature information from the database access request according to the underlying communication protocol type, and encapsulate the extracted business feature information into a unified request context; Step 2: Based on the unified request context and the preset routing and traffic management policies, determine the processing action decision for the database access request. The processing action decision includes allowing forwarding, rate limiting, or circuit breaking. Step 3: Based on the decision of the processing action for the database access request, process the database access request accordingly.

[0008] In one embodiment, step 1, extracting business feature information from the database access request based on the underlying communication protocol type, includes: The corresponding protocol parser is invoked based on the identified protocol type to extract business feature information from the request. The business feature information includes the SQL statement, operation type, client IP address, table name operated on by the SQL statement, and target logical library name. The extracted business feature information is encapsulated into a unified request context; the unified request context is a standardized data structure used to shield the differences between different domestic database protocols.

[0009] In one embodiment, step 2 includes: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, the preset route mapping table is queried to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Check the circuit breaker status of the target database instance using the target database instance identifier as the query key: If the instance is in the circuit breaker enabled state, then generate a circuit breaker action decision; If the instance is not in a circuit breaker enabled state, a rate limiting check is performed: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, the number of requests within the current sliding time window is counted. If the number of requests exceeds the preset QPS threshold, a rate limiting action decision is generated; if the number of requests does not exceed the preset QPS threshold, a forwarding action decision is generated, and the connection pool identifier corresponding to the target database instance is determined as the target database instance connection pool identifier.

[0010] In one embodiment, step 3 includes: Step 31: If the processing action decision is to allow forwarding, then execute steps 32 to 34; if the processing action decision is to rate limit, then execute step 35; if the processing action decision is to circuit breaker, then execute step 36. Step 32: Based on the target database instance connection pool identifier, obtain an available connection from the pre-established connection pool of the corresponding domestic heterogeneous database; Step 33: Based on the database type corresponding to the target database instance connection pool, call the corresponding syntax conversion module to convert the SQL statement in the unified request context into the syntax supported by that database type; Step 34: Send the transformed SQL statement to the target database instance through the available connection, receive the result set returned by the target database instance, and return the result set to the application that initiated the request in a format that matches the underlying communication protocol when the application initiated the request; Step 35: Return a rate-limiting error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database; Step 36: Return a circuit breaker error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database.

[0011] In one embodiment, step 2, which determines the processing action decision for the database access request based on the unified request context and preset routing and traffic governance strategies, specifically includes: Step 21: Determine the request semantic density (SDR) based on the number of SQL syntax tree nodes in the current database access request, the historical average number of SQL syntax tree nodes of the same type, the actual Shannon entropy of the token sequence of the current SQL, the maximum possible entropy, the character category frequency distribution of the current SQL string, the historical baseline character category frequency distribution, the character length of the current SQL statement, the historical average SQL length, the number of JOIN keywords in the current SQL, and the number of keywords appearing in the current SQL. Step 22: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, query the preset routing mapping table to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Step 23: Determine the database instantaneous stress index (IPI) of the target database instance based on its current actual request rate, nominal secure QPS threshold, current average response time, worker thread pool size, current active connections, maximum number of connections, rate of change of QPS ratio within the time window, sample standard deviation of response time within the current window, and baseline response time. Step 24: Check the circuit breaker status of the target database instance based on the target database instance identifier: if the instance is in the circuit breaker enabled state, generate a circuit breaker processing action decision; if the instance is not in the circuit breaker enabled state, proceed to step 25. Step 25: Determine the dynamic circuit breaker offset factor DCBO based on the instantaneous pressure index (IPI) of the target database instance and the request error rate within the current sliding window of the instance. Step 26: If DCBO is greater than the preset threshold Then, a decision on the circuit breaker action is generated; Otherwise, perform a rate limiting check: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, calculate the sum of the SDRs of all requests within the current sliding time window. And calculate the dynamic current limiting threshold. ,in The duration of the sliding window is in seconds; if If so, a rate-limiting action decision is generated; if If so, a decision is made to allow forwarding, and the connection pool identifier corresponding to the target database instance is determined as the connection pool identifier of the target database instance.

[0012] On the other hand, embodiments of the present invention provide a transparent access and traffic management system for heterogeneous databases in a domestic IT innovation environment, applicable to domestically produced heterogeneous databases in such an environment, including: The request encapsulation module is used to intercept database access requests initiated by applications through a smart proxy gateway; identify the underlying communication protocol type of the database access request, the underlying communication protocol including the native protocol of domestic databases; extract business feature information from the database access request according to the underlying communication protocol type, and encapsulate the extracted business feature information into a unified request context; The decision-making module is used to determine the processing action decision for the database access request based on the unified request context and preset routing and traffic management policies. The processing action decision includes allowing forwarding, rate limiting, or circuit breaking. The request processing module is used to process the database access request accordingly based on the processing action decision for the database access request.

[0013] In one embodiment, the request encapsulation module is further configured to: The corresponding protocol parser is invoked based on the identified protocol type to extract business feature information from the request. The business feature information includes the SQL statement, operation type, client IP address, table name operated on by the SQL statement, and target logical library name. The extracted business feature information is encapsulated into a unified request context; the unified request context is a standardized data structure used to shield the differences between different domestic database protocols.

[0014] In one embodiment, the decision-making module is further configured to: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, the preset route mapping table is queried to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Check the circuit breaker status of the target database instance using the target database instance identifier as the query key: If the instance is in the circuit breaker enabled state, then generate a circuit breaker action decision; If the instance is not in a circuit breaker enabled state, a rate limiting check is performed: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, the number of requests within the current sliding time window is counted. If the number of requests exceeds the preset QPS threshold, a rate limiting action decision is generated; if the number of requests does not exceed the preset QPS threshold, a forwarding action decision is generated, and the connection pool identifier corresponding to the target database instance is determined as the target database instance connection pool identifier.

[0015] In one embodiment, the request processing module is further configured to perform the following steps: Step 31: If the processing action decision is to allow forwarding, then execute steps 32 to 34; if the processing action decision is to rate limit, then execute step 35; if the processing action decision is to circuit breaker, then execute step 36. Step 32: Based on the target database instance connection pool identifier, obtain an available connection from the pre-established connection pool of the corresponding domestic heterogeneous database; Step 33: Based on the database type corresponding to the target database instance connection pool, call the corresponding syntax conversion module to convert the SQL statement in the unified request context into the syntax supported by that database type; Step 34: Send the transformed SQL statement to the target database instance through the available connection, receive the result set returned by the target database instance, and return the result set to the application that initiated the request in a format that matches the underlying communication protocol when the application initiated the request; Step 35: Return a rate-limiting error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database; Step 36: Return a circuit breaker error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database.

[0016] In one embodiment, the decision-making module is further configured to perform the following steps: Step 21: Determine the request semantic density (SDR) based on the number of SQL syntax tree nodes in the current database access request, the historical average number of SQL syntax tree nodes of the same type, the actual Shannon entropy of the token sequence of the current SQL, the maximum possible entropy, the character category frequency distribution of the current SQL string, the historical baseline character category frequency distribution, the character length of the current SQL statement, the historical average SQL length, the number of JOIN keywords in the current SQL, and the number of keywords appearing in the current SQL. Step 22: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, query the preset routing mapping table to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Step 23: Determine the database instantaneous stress index (IPI) of the target database instance based on its current actual request rate, nominal secure QPS threshold, current average response time, worker thread pool size, current active connections, maximum number of connections, rate of change of QPS ratio within the time window, sample standard deviation of response time within the current window, and baseline response time. Step 24: Check the circuit breaker status of the target database instance based on the target database instance identifier: if the instance is in the circuit breaker enabled state, generate a circuit breaker processing action decision; if the instance is not in the circuit breaker enabled state, proceed to step 25. Step 25: Determine the dynamic circuit breaker offset factor DCBO based on the instantaneous pressure index (IPI) of the target database instance and the request error rate within the current sliding window of the instance. Step 26: If DCBO is greater than the preset threshold Then, a decision on the circuit breaker action is generated; Otherwise, perform a rate limiting check: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, calculate the sum of the SDRs of all requests within the current sliding time window. And calculate the dynamic current limiting threshold. ,in The duration of the sliding window is in seconds; if If so, a rate-limiting action decision is generated; if If so, a decision is made to allow forwarding, and the connection pool identifier corresponding to the target database instance is determined as the connection pool identifier of the target database instance.

[0017] The beneficial effects of the above-mentioned technical solutions provided in the embodiments of the present invention include at least the following: This approach enables applications to obtain unified traffic governance capabilities, including dynamic routing, overload protection, and fault isolation, without requiring code modification. The unified request context decouples business information from the underlying protocol, allowing subsequent governance logic to be extended independently of the database protocol. In a domestically developed IT environment, this method reduces operational complexity when multiple databases coexist, and improves system observability and stability.

[0018] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0019] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0020] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a method for transparent access and traffic management of heterogeneous databases in a domestic IT innovation environment, provided in an embodiment of the present invention. Detailed Implementation

[0021] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0022] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," "outer," "far," "near," "front," and "rear," etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the accompanying drawings and are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0023] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0024] This invention provides a method for transparent access and traffic management of heterogeneous databases in a domestic IT innovation environment, such as... Figure 1 As shown, the method for using domestically produced heterogeneous databases in a domestic IT innovation environment includes the following steps: Step 1: Intercept database access requests initiated by applications through a smart proxy gateway; identify the underlying communication protocol type of the database access request, including the native protocol of domestic databases; extract business feature information from the database access request according to the underlying communication protocol type, and encapsulate the extracted business feature information into a unified request context; Step 2: Based on the unified request context and the preset routing and traffic management policies, determine the processing action decision for the database access request. The processing action decision includes allowing forwarding, rate limiting, or circuit breaking. Step 3: Based on the decision of the processing action for the database access request, process the database access request accordingly.

[0025] The above technical solution deploys an intelligent proxy gateway between the application and the database. This gateway intercepts all database access requests, identifies the underlying communication protocol type (including the native protocols of various domestic databases), extracts business characteristic information from the requests, and encapsulates it into a unified request context independent of specific protocols. Based on this context and preset routing and traffic management policies, it makes a decision on whether to allow forwarding, rate limiting, or circuit breaking for the current request. Finally, it executes the corresponding processing based on the decision result: if forwarding is allowed, the request is sent to the target database; if rate limiting or circuit breaking is applied, a protocol-level error response is returned directly to the application, and the request is no longer forwarded to the backend.

[0026] The above technical solution enables applications to obtain unified traffic governance capabilities, including dynamic routing, overload protection, and fault isolation, without modifying the code. The unified request context decouples business information from the underlying protocol, allowing subsequent governance logic to be extended independently of the database protocol. In a domestically developed IT environment, this method can reduce the operational complexity of multiple databases coexisting and improve system observability and stability.

[0027] In one embodiment, step 1, extracting business feature information from the database access request based on the underlying communication protocol type, includes: The corresponding protocol parser is invoked based on the identified protocol type to extract business feature information from the request. The business feature information includes the SQL statement, operation type, client IP address, table name operated on by the SQL statement, and target logical library name. The extracted business feature information is encapsulated into a unified request context; the unified request context is a standardized data structure used to shield the differences between different domestic database protocols.

[0028] The above technical solution, after identifying the underlying communication protocol of the request, involves the proxy gateway invoking a parser matching that protocol to extract the SQL statement, operation type, client IP address, table name, and target database name from the protocol message. This information is then organized into a unified request context. This context employs a standardized data structure, masking the differences between various domestic databases in terms of protocol field positions, encoding methods, and data type representations.

[0029] The above technical solution, through the combination of a protocol parser and a standardized context, allows subsequent routing and traffic management modules to completely ignore underlying protocol differences. When a new domestic database needs to be integrated, only the corresponding protocol parser needs to be added, while routing policies, rate limiting thresholds, circuit breaker logic, etc., remain unchanged. This design improves system scalability and reduces development and maintenance costs in multi-protocol environments.

[0030] In one embodiment, step 2 includes: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, the preset route mapping table is queried to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Check the circuit breaker status of the target database instance using the target database instance identifier as the query key: If the instance is in the circuit breaker enabled state, then generate a circuit breaker action decision; If the instance is not in a circuit breaker enabled state, a rate limiting check is performed: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, the number of requests within the current sliding time window is counted. If the number of requests exceeds the preset QPS threshold, a rate limiting action decision is generated; if the number of requests does not exceed the preset QPS threshold, a forwarding action decision is generated, and the connection pool identifier corresponding to the target database instance is determined as the target database instance connection pool identifier.

[0031] The above technical solution first uses the target database name and the name of the table being operated on in the unified request context as the query key to look up the preset routing mapping table and obtain the corresponding target database instance identifier and its associated connection pool identifier. Then, it checks the circuit breaker status of the instance: if it is in the circuit breaker enabled state, a circuit breaker decision is directly generated; otherwise, a rate limiting check is performed. The rate limiting check uses the combination of the client IP address, the target database name, and the name of the table being operated on as the query key, counts the number of requests within the current sliding time window, and compares it with a preset QPS threshold. If the threshold is exceeded, a rate limiting decision is generated; otherwise, a decision to allow forwarding is generated, and the target connection pool identifier is recorded.

[0032] The above technical solution links routing, circuit breaking, and rate limiting into a clear decision chain. Circuit breaking takes precedence over rate limiting checks, ensuring that backend instances do not receive any requests during a failure. Rate limiting checks use sliding window statistics to smoothly handle sudden traffic surges. Using a combination of client IP, logical database name, and table name as the rate limiting key enables fine-grained traffic control; for example, precise limits can be applied to the same table or the same client, avoiding the unfairness issues caused by global rate limiting.

[0033] In one embodiment, step 3 includes: Step 31: If the processing action decision is to allow forwarding, then execute steps 32 to 34; if the processing action decision is to rate limit, then execute step 35; if the processing action decision is to circuit breaker, then execute step 36. Step 32: Based on the target database instance connection pool identifier, obtain an available connection from the pre-established connection pool of the corresponding domestic heterogeneous database; Step 33: Based on the database type corresponding to the target database instance connection pool, call the corresponding syntax conversion module to convert the SQL statement in the unified request context into the syntax supported by that database type; Step 34: Send the transformed SQL statement to the target database instance through the available connection, receive the result set returned by the target database instance, and return the result set to the application that initiated the request in a format that matches the underlying communication protocol when the application initiated the request; Step 35: Return a rate-limiting error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database; Step 36: Return a circuit breaker error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database.

[0034] In the above technical solution, when the decision is to allow forwarding, an available connection is obtained from the pre-established connection pool of the corresponding domestic heterogeneous database based on the determined target database instance connection pool identifier. Then, according to the type of the target database instance, the corresponding syntax conversion module is invoked to convert the SQL statement in the unified request context into a dialect supported by the database. Next, the converted SQL is sent to the target database instance through the available connection, the returned result set is received, and the result set is returned to the application in a format that matches the underlying communication protocol when the application initiated the request. When the decision is to rate limit or circuit breaker, the proxy gateway directly returns a rate limit or circuit breaker error response at the database protocol level to the application, without forwarding the request to the backend.

[0035] The above technical solutions ensure the integrity of the transparent proxy: the requests initiated by the application and the responses received are unaware of the existence of the intermediate layer at the protocol level. The syntax conversion module resolves the SQL dialect differences between heterogeneous databases, enabling applications to access different types of domestic databases using a unified SQL style. The connection pooling mechanism avoids the overhead of frequent connection establishment and termination, improving system throughput. Error responses for rate limiting and circuit breaking adopt the native error format of the database protocol, allowing the application-layer database driver to handle them like ordinary database errors, without special adaptation.

[0036] As an optional embodiment, step 2, which determines the processing action decision for the database access request based on the unified request context and preset routing and traffic management strategies, can also be implemented as follows: Step 21: Determine the request semantic density (SDR) based on the number of SQL syntax tree nodes in the current database access request, the historical average number of SQL syntax tree nodes of the same type, the actual Shannon entropy of the token sequence of the current SQL, the maximum possible entropy, the character category frequency distribution of the current SQL string, the historical baseline character category frequency distribution, the character length of the current SQL statement, the historical average SQL length, the number of JOIN keywords in the current SQL, and the number of keywords appearing in the current SQL. Specifically, the request semantic density is used to quantify the potential resource consumption intensity of a single SQL request on the backend database, and its calculation formula is as follows: ; in, This represents the number of nodes (depth) in the current SQL syntax tree. It is an integer not less than 1, and is obtained by the SQL parser built into the proxy gateway after performing syntax analysis on the current request. The historical average number of syntax tree nodes for the same type of SQL is a real number greater than 0. The historical statistics of the sliding window maintained by the proxy gateway are stored separately according to the target logical library and the operation type. This represents the actual Shannon entropy of the token sequence in the current SQL statement, calculated using the following formula: ,in The frequency of the i-th token type (including keywords, identifiers, constants, operators, etc.), with a value range of 1. After parsing the SQL to obtain the token sequence, the probability distribution is calculated and then the entropy is obtained. Represents the maximum possible entropy. , It is a set of token types, which are real numbers greater than 0, and are determined by the total number of token types predefined by the system; This represents a predefined set of character categories (including lowercase letters, uppercase letters, numbers, operators, separators, etc.), which are predefined by the system. This indicates the category in the current SQL string. Character frequency, value range Furthermore, the sum of the frequencies of all categories is 1. This is obtained by iterating through each character of the SQL string and counting the occurrences of each type of character, divided by the total number of characters. hour, The value is 0; This represents the historical baseline character category frequency distribution, with a value range of... The sum is 1, calculated offline or smoothly updated online by the proxy gateway when there is no significant pressure. To avoid division by zero, for each Add minimal smoothing term ; Indicates the character length of the current SQL statement, which is an integer not less than 1. The length of the requested byte stream is read directly. This represents the historical average SQL length, a real number greater than 0, obtained by the proxy gateway from the average length of all SQL statements within the current sliding window. This represents the length modulation sensitivity parameter, which is a positive real number and can be preset according to needs or actual conditions. The preferred value is 0.8. This indicates the number of JOIN keywords in the current SQL statement. It is an integer not less than 0 and is obtained through SQL parsing or regular expression matching. This indicates the number of keywords appearing in the current SQL statement. It is an integer not less than 0 and is obtained through SQL parsing or matching a predefined keyword table. This represents the weight of the coupling term, a positive real number, which can be preset according to needs or actual conditions, with a preferred value of 0.5; This represents the steepness of the logistic curve, and is a positive real number. It can be preset according to needs or actual conditions, with a preferred value of 1.2. This indicates the keyword threshold offset, and is a positive real number. It can be preset according to needs or actual conditions, with a preferred value of 3. Step 22: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, query the preset routing mapping table to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Step 23: Determine the database instantaneous stress index (IPI) of the target database instance based on its current actual request rate, nominal secure QPS threshold, current average response time, worker thread pool size, current active connections, maximum number of connections, rate of change of QPS ratio within the time window, sample standard deviation of response time within the current window, and baseline response time. Specifically, the instantaneous database stress index is used to assess the overload level of the target database instance in real time, and its calculation formula can be as follows: ; in, This represents the average utilization of each worker thread in the target database instance, with a value range of [value range missing]. The upper limit for the project is set to 0.99. If the calculation result is ≥1, it will be forcibly set to 0.99. This represents the actual request rate of the target database instance within the current sliding time window, i.e., queries per second (QPS). It is a real number greater than 0, obtained by the monitoring module of the proxy gateway by counting the number of requests forwarded to the instance in a fixed window. This represents the average response time of the target database instance within the current window, in seconds. It is a real number greater than 0, obtained by the proxy gateway recording the time taken from sending a request to receiving a response and calculating the arithmetic average within the window. This represents the size of the worker thread pool for the target database instance. It is a positive integer and can be obtained by querying the database system table or management interface. This represents the current number of active connections to the target database instance. It is an integer not less than 0 and is obtained in real time from the connection pool monitoring module of the proxy gateway. This indicates the maximum number of connections allowed for the target database instance. It is a positive integer and can be obtained through database configuration parameters or system table queries. This represents the connection number sensitivity parameter, which is a positive real number and can be preset according to needs or actual conditions. The preferred value is 2.0. This represents the threshold offset for the number of connections. It is a real number and can be preset as needed or based on actual conditions. The preferred value is 0.7. This indicates that the target database instance is within the time window. The rate of change of the internal QPS ratio, i.e., the numerical derivative, is obtained by storing the previous window. Difference between the value and the current value divided by get, Take 1 second; This represents the nominal secure QPS threshold of the target database instance, and is a real number greater than 0, set through load testing or a value recommended by the database vendor. This represents the response time amplification factor, which is a positive real number and can be preset according to needs or actual conditions. The preferred value is 1.5. The weight of the acceleration term is represented by a positive real number, which can be preset according to needs or actual conditions, with a preferred value of 0.2. This represents the sample standard deviation of the response time within the current window of the target database instance. It is a real number not less than 0 and is obtained by calculating the standard deviation after the monitoring module records the response time of each request. This represents the baseline response time of the target database instance, in seconds. It is a real number greater than 0, obtained through load testing during system startup or maintenance, and can be updated periodically. This represents the weight of the jitter term, and is a positive real number. It can be preset according to needs or actual conditions, with a preferred value of 0.3. This represents the steepness of the logic curve for the jitter term. It is a positive real number and can be preset as needed or based on actual conditions. The preferred value is 2.0. This indicates the threshold offset of the jitter term, and is a positive real number. It can be preset according to needs or actual conditions, with a preferred value of 1.2. If the IPI calculation result exceeds a preset upper limit, such as 1000, it will be truncated to that preset upper limit. Step 24: Check the circuit breaker status of the target database instance based on the target database instance identifier: if the instance is in the circuit breaker enabled state, generate a circuit breaker processing action decision; if the instance is not in the circuit breaker enabled state, proceed to step 25. Step 25: Determine the dynamic circuit breaker offset factor DCBO based on the instantaneous pressure index (IPI) of the target database instance and the request error rate within the current sliding window of the instance. Specifically, the dynamic circuit breaker offset factor is used to guide circuit breaker decisions, and its calculation formula is as follows: ; in, The instantaneous stress index of the target database instance calculated in step 23; This represents the request error rate within the current sliding window of the target database instance, defined as the number of erroneous requests divided by the total number of requests, with a value range of... The percentage of requests forwarded to this instance by the proxy gateway that return errors (including timeouts, connection errors, and database errors) is obtained. This represents the Sigmoid curve (i.e. The steepness of the slope is a positive real number, which can be preset according to needs or actual conditions, with a preferred value of 2.0; This represents the offset threshold, which makes When the Sigmoid function is active, it outputs 0.5, taking a real number. This value can be preset according to needs or actual conditions, with 0.7 being the preferred value. The error rate amplification factor is a positive real number, which can be preset according to needs or actual conditions, with a preferred value of 1.5; the DCBO value is a dimensionless real number, between between; Step 26: If DCBO is greater than the preset threshold Then, a decision on the circuit breaker action is generated; Otherwise, perform a rate limiting check: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, calculate the sum of the SDRs of all requests within the current sliding time window. And calculate the dynamic current limiting threshold. ,in The duration of the sliding window is in seconds; if If so, a rate-limiting action decision is generated; if If so, a decision is made to allow forwarding, and the connection pool identifier corresponding to the target database instance is determined as the connection pool identifier of the target database instance.

[0037] The principles behind the above technical solution are explained below: Explanation of the principles behind Request Semantic Density (SDR): The purpose of the SDR calculation formula described above is to quantify the complexity of SQL statements into a comparable value, so that requests with higher semantic density are expected to consume more resources from the backend database. The formula consists of three sub-items with clear physical meaning.

[0038] First item It integrates the structural depth and information entropy of SQL. Among them, This reflects the depth of the current SQL syntax tree relative to its historical average. A greater depth typically indicates more nested subqueries or complex expressions, resulting in higher parsing and execution overhead. (Exponential term) The Shannon entropy of the token sequence is exponentially amplified: higher entropy indicates a richer variety and more even distribution of token types used in the SQL, often corresponding to more complex semantics (e.g., a mixture of numerous fields, functions, and conditions). Multiplying the two and adding 1 results in a higher base density for requests with complex structures and rich information.

[0039] Second item Relative entropy (KL divergence) is used to characterize the deviation of the current SQL character category distribution relative to the historical baseline. Relative entropy is essentially an information-theoretic metric that measures the difference between two probability distributions: when the current SQL character category ratio is consistent with normal conditions, this term is close to 0; once an abnormal distribution occurs (e.g., a sudden increase in numbers, operators, or special symbols), the relative entropy becomes positive. Multiplied by a length modulation factor... This further amplifies the distribution offset of long SQL queries, as anomalous patterns appearing in long SQL queries are more likely to represent high load or malicious behavior. This sub-item enables the proxy gateway to identify high-risk requests that are "structurally normal but contain anomalous characters."

[0040] Third item The coupling effect between the number of connections and the number of keywords is smoothly modeled using the logistic function. The number of joins directly reflects the complexity of multi-table joins. (Number of keywords) reflects the number of operation segments in the query. When the number of keywords... Exceeding the threshold When the logistic function output approaches 1, the term is approximately equal to 1. That is, the more JOINs, the higher the density; when Less than When the output is close to 0, this contribution is suppressed. This smooth design avoids the decision jitter caused by hard thresholds, allowing semantic density to increase smoothly with the number of keywords.

[0041] In summary, SDR comprehensively quantifies the potential resource consumption of a SQL request through four dimensions: structural depth, information entropy, distribution offset, and connection and keyword coupling, providing a more scientific basis for subsequent rate limiting than simple counting.

[0042] Explanation of the principle behind the Instantaneous Pressure Index (IPI) for databases: IPI is used to assess the overload of a target database instance in real time. Its calculation formula draws on classic models from queuing theory, control theory, and statistics. It consists of three sub-items, which reflect steady-state queue pressure, load change trend, and response time jitter, respectively.

[0043] First item Based on the M / M / 1 queuing model. It is the average utilization of each worker thread, according to Little's Law. It equals the average number of waiting requests in the system (queue length). When When the value approaches 1, the queue length tends towards infinity, indicating that the database is about to become or has already become overloaded. Simultaneously, the connection percentage... Pressure is modulated using the hyperbolic tangent function: when the number of connections exceeds a threshold. hour, When the output value approaches 1, the overall pressure is amplified; conversely, when it is less than the threshold, the output value approaches -1, and the pressure is reduced. This reflects the physical fact that "high connection count exacerbates queue congestion".

[0044] Second item The concept of load acceleration is introduced. Among them... This is the numerical derivative of the QPS ratio; a positive value indicates that the load is rising rapidly. Even if the current QPS is still within a safe range, a rapidly rising load can easily lead to overshoot, so this term is multiplied by an exponential amplification factor. When the average response time deviates from the baseline, the amplification effect is stronger, enabling IPI to provide early warnings of sudden traffic surges. This is similar to the "feedforward" concept in control engineering.

[0045] Third item Using the standard deviation of response time This is used to quantify service jitter. In database systems, fluctuations in response time often reflect unstable overload conditions (such as lock contention and resource contention) better than the average. This sub-item first calculates the normalized jitter. Then, the region with high average response time is weighted using the logistic function: when Exceeding the threshold When the logistic output is close to 1, the impact of jitter is fully accounted for; otherwise, the output is close to 0, ignoring slight jitter. This design ensures that jitter only significantly increases the stress index when the database slows down considerably.

[0046] By weighting and summing the above three factors, IPI can comprehensively represent the three dimensions of steady state, transient state, and randomness, accurately depicting the real-time pressure on database instances and providing a reliable triggering basis for circuit breaking and rate limiting.

[0047] Explanation of the principle of Dynamic Circuit Breaker Offset Factor (DCBO): DCBO is used to combine the database instantaneous stress index (IPI) and request error rate (...). The smooth mapping is the offset factor for the circuit breaker decision. Its formula is the product of two parts.

[0048] Part One It is the standard sigmoid function. This function has the following ideal property: when IPI is much smaller than a threshold... When the IPI is much greater than 0, the output approaches 0; when the IPI is much greater than 0, the output approaches When the output approaches 1; Nearby, the output transitions smoothly. Parameters Controlling the steepness of the transition curve: The larger the value, the more drastic the jump from 0 to 1; The smaller the value, the smoother the transition. This design avoids frequent switching of the fuse state due to small fluctuations in IPI when using a hard threshold, while retaining the sensitivity to trigger rapidly when the pressure exceeds the safe range.

[0049] Part Two It is an error rate amplification factor. When the request error rate... When the value is 0, the factor is 1, which does not change the output of Sigmoid. As the error rate increases, the factor increases linearly, causing the final DCBO to exceed the output value of Sigmoid. The error rate is direct evidence that the database instance has failed (such as timeouts, connection errors, SQL execution errors), so it is necessary to amplify the circuit breaker offset to make the system enter the circuit breaker state more quickly to protect the backend.

[0050] After multiplying the two parts to obtain DCBO, the system compares it with a preset threshold. (e.g., 0.85) Comparison: If DCBO is greater than the threshold, the circuit breaker is triggered; otherwise, the circuit breaker can enter a half-open state or remain closed based on the value of DCBO. This decision based on continuous values ​​has better smoothness and anti-jitter capability than traditional binary circuit breakers (based solely on error counts), making it particularly suitable for scenarios with large fluctuations in database load under the domestic IT innovation environment.

[0051] In the above technical solution, after route mapping and basic circuit breaker checks, the proxy gateway first calculates the semantic density (SDR) of the current request to measure the resource consumption potential of the SQL statement on the backend database. Simultaneously, it calculates the instantaneous pressure index (IPI) of the target database instance in real time, comprehensively reflecting the instance's load level, response jitter, and pressure change trend. Based on the IPI and the request error rate within the current window, it further calculates the dynamic circuit breaker offset factor (DCBO) as a continuous basis for circuit breaker decisions.

[0052] In the rate limiting check, a fixed QPS threshold is no longer used. Instead, the sum of the SDRs of all requests within the sliding window is added to the dynamic rate limiting threshold. The comparison is performed. If the cumulative sum exceeds the dynamic threshold, rate limiting is triggered; otherwise, forwarding is allowed. The circuit breaker check determines whether to trigger the circuit breaker by comparing the DCBO with a preset threshold.

[0053] The above technical solution refines the rate limiting granularity from the number of requests to the semantic density of the requests, enabling the differentiation between lightweight and complex queries and avoiding omissions in rate limiting for high-overhead requests. The dynamic rate limiting threshold automatically adjusts according to the instantaneous pressure (IPI) of the database instance: the higher the pressure, the lower the threshold, achieving adaptive overload protection. The circuit breaker decision introduces a continuous DCBO value, avoiding the state jitter caused by hard thresholds in traditional circuit breakers, while accelerating the isolation of faulty instances through an error rate amplification factor. Overall, this makes traffic management more precise and smooth, better adapting to the dynamic changes in database load under the domestic IT innovation environment.

[0054] This invention provides a transparent access and traffic management system for heterogeneous databases in a domestic IT innovation environment, applicable to domestically produced heterogeneous databases in such environments, including: The request encapsulation module is used to intercept database access requests initiated by applications through a smart proxy gateway; identify the underlying communication protocol type of the database access request, the underlying communication protocol including the native protocol of domestic databases; extract business feature information from the database access request according to the underlying communication protocol type, and encapsulate the extracted business feature information into a unified request context; The decision-making module is used to determine the processing action decision for the database access request based on the unified request context and preset routing and traffic management policies. The processing action decision includes allowing forwarding, rate limiting, or circuit breaking. The request processing module is used to process the database access request accordingly based on the processing action decision for the database access request.

[0055] In one embodiment, the request encapsulation module is further configured to: The corresponding protocol parser is invoked based on the identified protocol type to extract business feature information from the request. The business feature information includes the SQL statement, operation type, client IP address, table name operated on by the SQL statement, and target logical library name. The extracted business feature information is encapsulated into a unified request context; the unified request context is a standardized data structure used to shield the differences between different domestic database protocols.

[0056] In one embodiment, the decision-making module is further configured to: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, the preset route mapping table is queried to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Check the circuit breaker status of the target database instance using the target database instance identifier as the query key: If the instance is in the circuit breaker enabled state, then generate a circuit breaker action decision; If the instance is not in a circuit breaker enabled state, a rate limiting check is performed: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, the number of requests within the current sliding time window is counted. If the number of requests exceeds the preset QPS threshold, a rate limiting action decision is generated; if the number of requests does not exceed the preset QPS threshold, a forwarding action decision is generated, and the connection pool identifier corresponding to the target database instance is determined as the target database instance connection pool identifier.

[0057] In one embodiment, the request processing module is further configured to perform the following steps: Step 31: If the processing action decision is to allow forwarding, then execute steps 32 to 34; if the processing action decision is to rate limit, then execute step 35; if the processing action decision is to circuit breaker, then execute step 36. Step 32: Based on the target database instance connection pool identifier, obtain an available connection from the pre-established connection pool of the corresponding domestic heterogeneous database; Step 33: Based on the database type corresponding to the target database instance connection pool, call the corresponding syntax conversion module to convert the SQL statement in the unified request context into the syntax supported by that database type; Step 34: Send the transformed SQL statement to the target database instance through the available connection, receive the result set returned by the target database instance, and return the result set to the application that initiated the request in a format that matches the underlying communication protocol when the application initiated the request; Step 35: Return a rate-limiting error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database; Step 36: Return a circuit breaker error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database.

[0058] In one embodiment, the decision-making module is further configured to perform the following steps: Step 21: Determine the request semantic density (SDR) based on the number of SQL syntax tree nodes in the current database access request, the historical average number of SQL syntax tree nodes of the same type, the actual Shannon entropy of the token sequence of the current SQL, the maximum possible entropy, the character category frequency distribution of the current SQL string, the historical baseline character category frequency distribution, the character length of the current SQL statement, the historical average SQL length, the number of JOIN keywords in the current SQL, and the number of keywords appearing in the current SQL. Step 22: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, query the preset routing mapping table to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Step 23: Determine the database instantaneous stress index (IPI) of the target database instance based on its current actual request rate, nominal secure QPS threshold, current average response time, worker thread pool size, current active connections, maximum number of connections, rate of change of QPS ratio within the time window, sample standard deviation of response time within the current window, and baseline response time. Step 24: Check the circuit breaker status of the target database instance based on the target database instance identifier: if the instance is in the circuit breaker enabled state, generate a circuit breaker processing action decision; if the instance is not in the circuit breaker enabled state, proceed to step 25. Step 25: Determine the dynamic circuit breaker offset factor DCBO based on the instantaneous pressure index (IPI) of the target database instance and the request error rate within the current sliding window of the instance. Step 26: If DCBO is greater than the preset threshold Then, a decision on the circuit breaker action is generated; Otherwise, perform a rate limiting check: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, calculate the sum of the SDRs of all requests within the current sliding time window. And calculate the dynamic current limiting threshold. ,in The duration of the sliding window is in seconds; if If so, a rate-limiting action decision is generated; if If so, a decision is made to allow forwarding, and the connection pool identifier corresponding to the target database instance is determined as the connection pool identifier of the target database instance.

[0059] This invention provides a method and system for transparent access and traffic management of heterogeneous databases in a domestic IT innovation environment. By deploying an intelligent proxy gateway, it achieves unified interception and protocol parsing of access requests to domestic heterogeneous databases, constructing a unified request context decoupled from the underlying protocol. Based on this, the invention integrates a traffic management mechanism of dynamic routing, adaptive rate limiting, and smooth circuit breaking: On the one hand, the dynamic rate limiting strategy based on request semantic density (SDR) and database instantaneous pressure index (IPI) can distinguish between lightweight and complex queries and automatically adjust the rate limiting threshold according to the real-time pressure of backend instances, avoiding the insensitivity problem of traditional fixed threshold rate limiting; on the other hand, the circuit breaking decision based on dynamic circuit breaker offset factor (DCBO) introduces continuous value judgment and error rate amplification factor, reducing the jitter of circuit breaker state switching and accelerating the isolation speed of faulty instances. Simultaneously, this invention supports automatic SQL syntax conversion and connection pool reuse for heterogeneous databases, enabling applications to transparently access different domestic databases without any modification and obtain unified rate limiting, circuit breaking, and routing capabilities. In the context of multi-database hybrid deployment in a domestically developed IT environment, this invention can reduce the risk of system crashes caused by sudden traffic surges or single points of failure, improve overall throughput, and shorten fault recovery time. Therefore, this invention enhances the stability, scalability, and ease of operation and maintenance of heterogeneous database systems in a domestically developed IT environment.

[0060] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. This disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims. Thus, if these modifications and variations of the invention fall within the scope of the claims of the invention and their equivalents, the invention is also intended to include these modifications and variations.

Claims

1. A method for transparent access and traffic management of heterogeneous databases in a domestic IT innovation environment, characterized in that, The method for using domestically produced heterogeneous databases in a domestic IT innovation environment includes the following steps: Step 1: Intercept database access requests initiated by applications through a smart proxy gateway; identify the underlying communication protocol type of the database access request, including the native protocol of domestic databases; extract business feature information from the database access request according to the underlying communication protocol type, and encapsulate the extracted business feature information into a unified request context; Step 2: Based on the unified request context and the preset routing and traffic management policies, determine the processing action decision for the database access request. The processing action decision includes allowing forwarding, rate limiting, or circuit breaking. Step 3: Based on the decision of the processing action for the database access request, process the database access request accordingly.

2. The method as described in claim 1, characterized in that, Step 1, which involves extracting business feature information from the database access request based on the underlying communication protocol type, includes: The corresponding protocol parser is invoked based on the identified protocol type to extract business feature information from the request. The business feature information includes the SQL statement, operation type, client IP address, table name operated on by the SQL statement, and target logical library name. The extracted business feature information is encapsulated into a unified request context; the unified request context is a standardized data structure used to shield the differences between different domestic database protocols.

3. The method as described in claim 2, characterized in that, Step 2 includes: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, the preset route mapping table is queried to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Check the circuit breaker status of the target database instance using the target database instance identifier as the query key: If the instance is in the circuit breaker enabled state, then generate a circuit breaker action decision; If the instance is not in a circuit breaker enabled state, a rate limiting check is performed: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, the number of requests within the current sliding time window is counted. If the number of requests exceeds the preset QPS threshold, a rate limiting action decision is generated; if the number of requests does not exceed the preset QPS threshold, a forwarding action decision is generated, and the connection pool identifier corresponding to the target database instance is determined as the target database instance connection pool identifier.

4. The method according to claim 1, characterized in that, Step 3 includes: Step 31: If the processing action decision is to allow forwarding, then execute steps 32 to 34; if the processing action decision is to rate limit, then execute step 35; if the processing action decision is to circuit breaker, then execute step 36. Step 32: Based on the target database instance connection pool identifier, obtain an available connection from the pre-established connection pool of the corresponding domestic heterogeneous database; Step 33: Based on the database type corresponding to the target database instance connection pool, call the corresponding syntax conversion module to convert the SQL statement in the unified request context into the syntax supported by that database type; Step 34: Send the transformed SQL statement to the target database instance through the available connection, receive the result set returned by the target database instance, and return the result set to the application that initiated the request in a format that matches the underlying communication protocol when the application initiated the request; Step 35: Return a rate-limiting error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database; Step 36: Return a circuit breaker error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database.

5. The method as described in claim 1, characterized in that, Step 2, based on the unified request context and preset routing and traffic management strategies, determines the processing action for the database access request, specifically including: Step 21: Determine the request semantic density (SDR) based on the number of SQL syntax tree nodes in the current database access request, the historical average number of SQL syntax tree nodes of the same type, the actual Shannon entropy of the token sequence of the current SQL, the maximum possible entropy, the character category frequency distribution of the current SQL string, the historical baseline character category frequency distribution, the character length of the current SQL statement, the historical average SQL length, the number of JOIN keywords in the current SQL, and the number of keywords appearing in the current SQL. Step 22: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, query the preset routing mapping table to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Step 23: Determine the database instantaneous stress index (IPI) of the target database instance based on its current actual request rate, nominal secure QPS threshold, current average response time, worker thread pool size, current active connections, maximum number of connections, rate of change of QPS ratio within the time window, sample standard deviation of response time within the current window, and baseline response time. Step 24: Check the circuit breaker status of the target database instance based on the target database instance identifier: If the instance is in the circuit breaker enabled state, generate a circuit breaker processing action decision; if the instance is not in the circuit breaker enabled state, proceed to step 25. Step 25: Determine the dynamic circuit breaker offset factor DCBO based on the instantaneous pressure index (IPI) of the target database instance and the request error rate within the current sliding window of the instance. Step 26: If DCBO is greater than the preset threshold Then, a decision on the circuit breaker action is generated; Otherwise, perform a rate limiting check: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, calculate the sum of the SDRs of all requests within the current sliding time window. And calculate the dynamic current limiting threshold. ,in The duration of the sliding window is in seconds; if If so, a rate-limiting action decision is generated; if If so, a decision is made to allow forwarding, and the connection pool identifier corresponding to the target database instance is determined as the connection pool identifier of the target database instance.

6. A transparent access and traffic management system for heterogeneous databases in a domestic IT innovation environment, characterized in that, Domestically developed heterogeneous databases applied in the information technology innovation environment include: The request encapsulation module is used to intercept database access requests initiated by applications through a smart proxy gateway; identify the underlying communication protocol type of the database access request, the underlying communication protocol including the native protocol of domestic databases; extract business feature information from the database access request according to the underlying communication protocol type, and encapsulate the extracted business feature information into a unified request context; The decision-making module is used to determine the processing action decision for the database access request based on the unified request context and preset routing and traffic management policies. The processing action decision includes allowing forwarding, rate limiting, or circuit breaking. The request processing module is used to process the database access request accordingly based on the processing action decision for the database access request.

7. The system as described in claim 6, characterized in that, The request encapsulation module is further configured to: The corresponding protocol parser is invoked based on the identified protocol type to extract business feature information from the request. The business feature information includes the SQL statement, operation type, client IP address, table name operated on by the SQL statement, and target logical library name. The extracted business feature information is encapsulated into a unified request context; the unified request context is a standardized data structure used to shield the differences between different domestic database protocols.

8. The system as described in claim 7, characterized in that, The decision-making module is also used for: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, the preset route mapping table is queried to obtain the corresponding target database instance identifier; each target database instance corresponds to a unique connection pool identifier; Check the circuit breaker status of the target database instance using the target database instance identifier as the query key: If the instance is in the circuit breaker enabled state, then generate a circuit breaker action decision; If the instance is not in a circuit breaker enabled state, a rate limiting check is performed: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, the number of requests within the current sliding time window is counted. If the number of requests exceeds the preset QPS threshold, a rate limiting action decision is generated; if the number of requests does not exceed the preset QPS threshold, a forwarding action decision is generated, and the connection pool identifier corresponding to the target database instance is determined as the target database instance connection pool identifier.

9. The system according to claim 6, characterized in that, The request processing module is also configured to perform the following steps: Step 31: If the processing action decision is to allow forwarding, then execute steps 32 to 34; if the processing action decision is to rate limit, then execute step 35; if the processing action decision is to circuit breaker, then execute step 36. Step 32: Based on the target database instance connection pool identifier, obtain an available connection from the pre-established connection pool of the corresponding domestic heterogeneous database; Step 33: Based on the database type corresponding to the target database instance connection pool, call the corresponding syntax conversion module to convert the SQL statement in the unified request context into the syntax supported by that database type; Step 34: Send the transformed SQL statement to the target database instance through the available connection, receive the result set returned by the target database instance, and return the result set to the application that initiated the request in a format that matches the underlying communication protocol when the application initiated the request; Step 35: Return a rate-limiting error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database; Step 36: Return a circuit breaker error response at the database protocol level to the application that initiated the request, and do not forward the request to the backend database.

10. The system as described in claim 6, characterized in that, The decision-making module is also used to perform the following steps: Step 21: Determine the request semantic density (SDR) based on the number of SQL syntax tree nodes in the current database access request, the historical average number of SQL syntax tree nodes of the same type, the actual Shannon entropy of the token sequence of the current SQL, the maximum possible entropy, the character category frequency distribution of the current SQL string, the historical baseline character category frequency distribution, the character length of the current SQL statement, the historical average SQL length, the number of JOIN keywords in the current SQL, and the number of keywords appearing in the current SQL. Step 22: Using the target logical library name in the unified request context and the table name operated on by the SQL statement as the query key, query the preset routing mapping table to obtain the corresponding target database instance identifier; Each target database instance corresponds to a unique connection pool identifier; Step 23: Determine the database instantaneous stress index (IPI) of the target database instance based on its current actual request rate, nominal secure QPS threshold, current average response time, worker thread pool size, current active connections, maximum number of connections, rate of change of QPS ratio within the time window, sample standard deviation of response time within the current window, and baseline response time. Step 24: Check the circuit breaker status of the target database instance based on the target database instance identifier: If the instance is in the circuit breaker enabled state, generate a circuit breaker processing action decision; if the instance is not in the circuit breaker enabled state, proceed to step 25. Step 25: Determine the dynamic circuit breaker offset factor DCBO based on the instantaneous pressure index (IPI) of the target database instance and the request error rate within the current sliding window of the instance. Step 26: If DCBO is greater than the preset threshold Then, a decision on the circuit breaker action is generated; Otherwise, perform a rate limiting check: using the combination of the client IP address, the target logical database name, and the table name operated on by the SQL statement as the query key, calculate the sum of the SDRs of all requests within the current sliding time window. And calculate the dynamic current limiting threshold. ,in The duration of the sliding window is in seconds; if If so, a rate-limiting action decision is generated; if If so, a decision is made to allow forwarding, and the connection pool identifier corresponding to the target database instance is determined as the connection pool identifier of the target database instance.

Images