Database flow limiting method and device, computer device and storage medium

Abstract

This invention relates to a database rate limiting method, apparatus, computer device, and storage medium. It acquires the number of queries per second (MS / MS) of the primary database in a database cluster within a preset sampling period, as well as the operating status of read-only nodes. Based on the operating status, it determines whether all read-only nodes are in a fault state. If so, and the MS / MS query count exceeds a preset threshold, a rate limiting strategy is executed for the primary database. The rate limiting strategy for the primary database is lifted when at least one read-only node is detected to have recovered from a fault state. Therefore, rate limiting control can be performed based on the current operating status of read-only nodes and the MS / MS query count, ensuring business continuity in fault scenarios while avoiding overload and resource exhaustion caused by a large influx of read requests into the primary database. Simultaneously, it achieves adaptive protection and recovery of the primary database load, improving the stability and availability of the database cluster in abnormal scenarios.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of database technology, and in particular to a database rate limiting method, apparatus, computer equipment, and storage medium. Background Technology

[0002] With the continuous expansion of internet business, database systems commonly adopt a master-slave architecture combined with read-write separation mechanisms to improve overall throughput and system availability. In this architecture, write requests are typically routed to the master database for execution, while read requests are preferentially distributed to read-only nodes, thereby reducing the load on the master database and improving concurrency processing capabilities. To achieve these capabilities, database proxy components are often introduced to uniformly access, route, and forward requests.

[0003] In existing technologies, database proxies typically possess fault detection and failover capabilities. When a read-only node fails, becomes unreachable, or the master-slave replication link malfunctions, read requests that should have been handled by the read-only node are automatically routed to the master database for execution, ensuring business continuity. However, in scenarios where all read-only nodes fail, a large number of read requests flooding the master database in a short period can easily exhaust the master's processing capacity, leading to performance degradation, connection exhaustion, or even cascading failures, impacting overall system stability.

[0004] In the aforementioned failover scenarios, existing database proxies typically lack fine-grained control measures for sudden loads on the primary database. They are unable to effectively limit abnormal read requests concentrated on the primary database based on the status of read-only nodes and the real-time load of the primary database. As a result, it is difficult to avoid the primary database overload problem caused by read requests failover to the primary database when all read-only nodes fail. Summary of the Invention

[0005] In view of this, in order to solve the above-mentioned technical problems or some of the technical problems, embodiments of the present invention provide a database rate limiting method, apparatus, computer equipment and storage medium.

[0006] In a first aspect, embodiments of the present invention provide a database rate limiting method, comprising: The system obtains the number of queries per second in the master database of the database cluster within a preset sampling period, as well as the running status of the read-only nodes in the database cluster. Determine whether all read-only nodes are in a fault state based on the operating status; If it is determined that all read-only nodes are in a fault state and the number of queries per second is greater than a preset threshold, a rate limiting policy is executed for the master database. The rate limiting policy is used to control the flow of target requests routed to the master database. The target request represents a read request routed to the master database due to the failure of the read-only nodes. If at least one of the read-only nodes is detected to have recovered from a faulty state to a normal state, the rate limiting policy of the master database is lifted.

[0007] In one possible implementation, executing the rate limiting policy for the master database includes: Determine whether the target request has already obtained a connection to the main database; If the target request has already obtained a master database connection, the master database connection is returned to the connection pool, the target request is rejected, and an error message is returned to the client. If the target request fails to obtain a connection to the master database, the target request will be rejected and an error message will be returned to the client.

[0008] In one possible implementation, obtaining the number of queries per second in the master database of the database cluster within a preset sampling period includes: An independent monitoring thread periodically collects the number of queries in the main database according to a preset time granularity, and writes the number of queries into a circular buffer; If the circular buffer is not full, the number of queries per second is calculated based on the cumulative number of queries collected from the main database, after normalization according to a preset sampling period. When the circular buffer is full and a rolling update occurs, calculate the difference between the cumulative number of queries corresponding to the latest time granularity and the cumulative number of queries corresponding to the earliest time granularity in the circular buffer. Divide the difference by the preset sampling period duration to obtain the number of queries per second.

[0009] In one possible implementation, before executing the rate limiting policy for the master database, the method further includes: Determine whether the master database is configured to participate in load balancing for read requests; If the primary database does not participate in read request load balancing, and all read-only nodes are detected to be in a fault state, then read requests originally routed to the read-only nodes will be failover and routed to the primary database. If the number of queries per second of the primary database exceeds the preset threshold, the rate limiting policy will be triggered for the primary database. When the primary database participates in read request load balancing, if all the read-only nodes are detected to be in a fault state, the read requests will be routed to the primary database in the read node group, and when the number of queries per second of the primary database in the read node group exceeds the preset threshold, a rate limiting policy will be triggered for the primary database in the read node group.

[0010] In one possible implementation, where the primary database participates in read request load balancing, the method further includes: If all the read-only nodes are detected to be in a fault state, the read request will be routed to the master database in the read node group. If the number of queries per second of the master database in the read node group is greater than the preset threshold, the read request will be routed to the master database that is not participating in read request load balancing. When the number of queries per second of the master database that does not participate in read request load balancing exceeds the preset threshold, a rate limiting policy is triggered for the master database in the read node group, and a rate limiting policy is also triggered for the master database that does not participate in read request load balancing.

[0011] In one possible implementation, the method further includes: When the primary database participates in read request load balancing, if the number of queries per second of the primary database in the read node group is less than or equal to the preset threshold, or if the number of read-only nodes that recover from a fault state to a normal state is greater than the number threshold, the rate limiting policy of the primary database in the read node group is lifted. If the number of queries per second in the primary database of the read node group is greater than the preset threshold, and the number of read-only nodes that recover from a fault state to a normal state is greater than the number threshold, then the read requests processed by the primary database in the read node group will be routed to the read-only nodes in a normal state.

[0012] In one possible implementation, before obtaining the number of queries per second in the master database of the database cluster within a preset sampling period, the method further includes: In the case that any request is routed to the master database, determine the reason why the request was routed to the master database; If the reason is that the request fails to acquire a connection to the read-only node and is forcibly routed to the primary database, the step of obtaining the number of queries per second of the primary database in the database cluster within a preset sampling period is executed.

[0013] Secondly, embodiments of the present invention provide a database rate limiting device, comprising: The acquisition module is used to acquire the number of queries per second of the master database in the database cluster within a preset sampling period, as well as the running status of the read-only nodes in the database cluster. The judgment module is used to determine whether all the read-only nodes are in a fault state based on the operating status. The control module is used to execute a rate limiting policy for the master database if it is determined that all the read-only nodes are in a fault state and the number of queries per second is greater than a preset threshold. The rate limiting policy is used to control the flow of target requests routed to the master database. The target request represents a read request routed to the master database due to the fault of the read-only nodes. The control module is also used to remove the rate limiting policy of the master database when it is detected that at least one of the read-only nodes has recovered from a fault state to a normal state.

[0014] Thirdly, embodiments of the present invention provide a computer device, including: a processor and a memory, wherein the processor is configured to execute a database rate limiting program stored in the memory to implement the database rate limiting method described in any one of the first aspects above.

[0015] Fourthly, embodiments of the present invention provide a storage medium storing one or more programs, which can be executed by one or more processors to implement the database rate limiting method described in any one of the first aspects.

[0016] The database rate limiting scheme provided in this invention obtains the number of queries per second (MS / S) of the master database in the database cluster within a preset sampling period, and obtains the operating status of the read-only nodes in the database cluster. Based on the operating status, it determines whether all read-only nodes are in a fault state. If it is determined that all read-only nodes are in a fault state and the number of queries per second exceeds a preset threshold, a rate limiting strategy is executed for the master database. The rate limiting strategy is used to control the flow of target requests routed to the master database. The target request represents a read request routed to the master database due to a read-only node failure. When at least one read-only node is detected to have recovered from a fault state, the rate limiting strategy for the master database is lifted. Therefore, even when all read-only nodes are faulty and the master database query load exceeds a preset threshold, rate limiting control can be implemented on read requests routed to the master database due to failover. This ensures business continuity in fault scenarios while avoiding overload and resource exhaustion caused by a large influx of read requests into the master database. Furthermore, the rate limiting is lifted promptly after at least one read-only node is detected to have recovered, achieving adaptive protection and recovery of the master database load, and improving the stability and availability of the database cluster in abnormal scenarios. Attached Figure Description

[0017] Figure 1 A flowchart illustrating a database rate limiting method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating another database rate limiting method provided in an embodiment of the present invention; Figure 3 A flowchart illustrating another database rate limiting method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a database rate limiting system provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a database rate limiting device provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] To facilitate understanding of the embodiments of the present invention, further explanations and descriptions will be provided below with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0020] Figure 1 This is a flowchart illustrating a database rate limiting method provided in an embodiment of the present invention, as shown below. Figure 1 As shown, the method specifically includes: S11. Obtain the number of queries per second in the master database of the database cluster within the preset sampling period, and obtain the running status of the read-only nodes in the database cluster.

[0021] The database rate limiting method provided in this invention is applicable to database cluster operation scenarios employing a master-slave architecture and supporting read-write separation, and is particularly suitable for business systems with high requirements for database availability and stability under high-concurrency access conditions. In this scenario, when a read-only node in the database cluster cannot provide normal service due to faults, network anomalies, or replication anomalies, read requests originally routed to the read-only node will failover and be centrally routed to the master database for execution, which can easily cause a risk of instantaneous overload to the master database. Specifically applied to computer equipment, it can be a computing module deployed in the access link of the database cluster (e.g., the database management system MySQL), used to access, monitor, and control database requests. The computer equipment is used to obtain the number of queries per second of the master database in the database cluster within a preset sampling period, as well as the running status of the read-only nodes, and to execute or lift the rate limiting policy for the master database based on the query load of the master database and the running status of the read-only nodes.

[0022] Computer equipment can also be database proxy servers, load balancers, database access gateways, virtual machines or containerized instances in cloud environments, or computing nodes with integrated database request forwarding and control functions, running program instructions for collecting primary database traffic, detecting read-only node status, and making rate-limiting decisions. By collecting primary database query load information and detecting the running status of read-only nodes through monitoring threads, and dynamically executing or lifting primary database rate-limiting policies based on the detection results, intelligent control of primary database access traffic under abnormal failure scenarios can be achieved.

[0023] In this embodiment, a database cluster refers to a database system consisting of at least one master database node and one or more read-only nodes, used to provide data read and write services to the outside world. The master database refers to the database node in the database cluster that handles write requests and maintains data consistency, while also handling read requests in specific failure scenarios. A read-only node refers to a database node in the database cluster that keeps data synchronized with the master database and handles read requests. The preset sampling period refers to the length of the time window used to statistically analyze the query load of the master database. The time window is pre-configured by the system to limit the time range for query count statistics. Queries Per Second (QPS) refers to the query load per unit time, calculated by converting the number of database query requests received and executed by the master database within the preset sampling period according to the time dimension. The running status refers to the status information of whether the database node is currently able to provide services normally, including whether the node is connectable and whether it is in a read-only or faulty state.

[0024] In practical implementation, computer devices deployed in the database cluster access chain periodically collect statistics on query requests to the primary database to obtain the number of queries per second (ms) within a preset sampling period. Specifically, the computer devices monitor the number of query requests processed by the primary database within the sampling period and normalize the number of query requests based on the duration of the sampling period, thereby obtaining the query load of the primary database per unit time. Simultaneously, the computer devices acquire the operational status of each read-only node in the database cluster through a preset monitoring mechanism. This operational status information indicates whether the corresponding read-only node can establish a connection and provide read services normally. By summarizing and analyzing the operational status of each read-only node, the computer devices obtain the overall operational status of the read-only nodes in the database cluster, providing a basis for subsequent judgment on whether all read-only nodes are in a faulty state.

[0025] In one possible implementation, obtaining the number of queries per second in the master database of the database cluster within a preset sampling period includes: An independent monitoring thread periodically collects the query count from the main database according to a preset time granularity and writes the query count into a circular buffer. When the circular buffer is not full, the cumulative query count from the main database is normalized according to a preset sampling period and the number of queries per second is calculated. When the circular buffer is full and a rolling update occurs, the difference between the cumulative query count corresponding to the latest time granularity and the cumulative query count corresponding to the earliest time granularity in the circular buffer is calculated. The difference is divided by the preset sampling period to obtain the number of queries per second.

[0026] In this embodiment, the monitoring thread refers to a background execution thread created and run independently by a computer device, used to periodically collect and statistically analyze the main database's operational data without affecting the normal processing of database requests. The preset time granularity refers to the minimum time interval for the monitoring thread to collect data, used to limit the time length between two adjacent query count collections. The query count refers to the cumulative number of database query requests actually received and executed by the main database within the corresponding time granularity. The circular buffer refers to a data storage structure with its ends connected, used to store query count data corresponding to different time granularities in chronological order; after the storage space is full, newly written data overwrites the oldest written data. The preset sampling period duration refers to the length of the time window used to calculate the number of queries per second in the main database; the sampling period consists of multiple consecutive time granularities.

[0027] In the specific implementation, a separate monitoring thread is first created. The monitoring thread periodically performs query count collection operations according to a preset time granularity. During each collection, the monitoring thread obtains the cumulative query count of the main database at the end of the current time granularity and writes the corresponding query count into the circular buffer at the storage location corresponding to the current time granularity.

[0028] When the circular buffer is not full, it indicates that the number of time granularities collected so far has not yet covered the complete preset sampling period. At this time, the monitoring thread normalizes the cumulative query count of the main database based on the cumulative query count collected in the circular buffer, according to the preset sampling period duration, to uniformly convert it into the number of queries per unit time, thus obtaining the query count per second of the main database. In this way, even if the collection time is less than the complete sampling period, a query load metric with the same caliber as the complete sampling period can be obtained (e.g., less than 1 second is calculated as 1 second).

[0029] When the circular buffer is full and a rolling update occurs, the data stored in the circular buffer corresponds to a complete preset sampling period. At this time, the monitoring thread obtains the cumulative query count corresponding to the latest time granularity and the cumulative query count corresponding to the earliest time granularity in the circular buffer, and calculates the difference between the two to represent the number of new query requests added to the main database within the sampling period. Subsequently, the difference is divided by the preset sampling period duration to obtain the number of queries per second in the main database within the current sampling period.

[0030] In this way, regardless of whether the circular buffer is full, the number of queries per second in the main database can be calculated based on a uniform sampling period, thereby providing stable, continuous and comparable query load data support for subsequent rate limiting judgments.

[0031] In one possible implementation, before obtaining the number of queries per second (SPS) of the master database in the database cluster within a preset sampling period, the method further includes: If any request is routed to the primary database, determine the reason why the request was routed to the primary database; if the reason is that the request failed due to the failure to obtain a connection to the read-only node and was forcibly routed to the primary database, execute the step of obtaining the number of queries per second of the primary database in the database cluster within the preset sampling period.

[0032] In this embodiment, before obtaining the number of queries per second of the master database in the database cluster within a preset sampling period, the routing reason for any request routed to the master database is determined to distinguish the request type under different routing scenarios.

[0033] When a request is detected to be routed to the primary database, the reason for the request being routed to the primary database is identified based on the routing decision information in the database broker. The routing reason is used to characterize whether the request was routed to the primary database due to preset routing rules, effective forced routing instructions, transaction state restrictions, or a failover caused by a failure to acquire a read-only node connection.

[0034] If the determination result indicates that the request is due to a failure to obtain a connection to the read-only node and a failover has occurred, and the request is forcibly routed to the primary database, then the request is marked as a failover read request. The step of obtaining the number of queries per second of the primary database in the database cluster within a preset sampling period is then executed to include the query load corresponding to the request in the primary database load statistics.

[0035] When a request is routed to the primary database not due to failover, the computer device does not trigger the query count per second operation to avoid including requests in non-failover scenarios in the rate limiting judgment, thereby ensuring that the primary database query load statistics only reflect the actual read traffic pressure caused by the failure of read-only nodes.

[0036] S12. Determine whether all read-only nodes are in a fault state based on the operating status.

[0037] In this embodiment, based on the obtained running status of each read-only node in the database cluster, it is determined whether all read-only nodes are in a fault state.

[0038] The system periodically acquires the running status identifier of each read-only node and compares the running status of each read-only node with a preset normal status. If the running status of any read-only node does not meet the normal status, the read-only node is determined to be in a fault state; if the running status meets the normal status, the read-only node is determined to be in an available state.

[0039] Based on this, the running status of all read-only nodes in the database cluster is summarized and analyzed. When the judgment result is that all read-only nodes are determined to be in a fault state, it is determined that all read-only nodes are in a fault state; when at least one read-only node is determined to be in an available state, it is determined that not all read-only nodes are in a fault state.

[0040] S13. If it is determined that all read-only nodes are in a fault state and the number of queries per second is greater than the preset threshold, execute the rate limiting policy for the primary database. The rate limiting policy is used to control the flow of target requests routed to the primary database. The target request represents the read request routed to the primary database due to the failure of the read-only nodes.

[0041] In this embodiment, during the database proxy's routing decision for requests, before the request obtains a connection to the primary database and enters the actual execution phase, the reason for routing the current request to the primary database is identified. This is used to determine whether the request is a read request that has been migrated to the primary database due to a read-only node failure. If so, the request is determined to be the target request. When the identification result indicates that the current request is the target request, the request is marked as a request object controlled by the flow restriction policy.

[0042] After the rate limiting policy is triggered, if it is determined that all read-only nodes are in a faulty state, flow control processing is performed on target requests based on the current query load of the primary database. When the number of queries per second on the primary database continues to exceed a preset threshold, the computer device directly rejects newly arriving target requests and returns preset abnormal response information to the corresponding client to prevent the target requests from continuing to occupy the connection and computing resources of the primary database.

[0043] Meanwhile, for database requests that are not part of the target request, the normal processing flow remains unchanged to ensure that write requests and read requests not generated during failover are not affected by the rate limiting policy. Through this method, fine-grained rate limiting control is achieved only for read requests routed to the primary database due to read-only node failures. This effectively prevents the primary database from being overwhelmed by sudden read traffic surges when all read-only nodes fail and the primary database is under excessive load.

[0044] In one possible implementation, a rate limiting policy is executed for the master database, including: Determine whether the target request has already obtained a connection to the master database. If the target request has already obtained a connection to the master database, return the master database connection to the connection pool, refuse to execute the target request, and return an error message to the client. If the target request has not obtained a connection to the master database, refuse to execute the target request directly and return an error message to the client.

[0045] In this embodiment, after the rate limiting policy for the master database is triggered, the computer device first determines whether the target request has already obtained a connection to the master database during the process of processing the target request, so as to avoid connection resource leakage or protocol status abnormality during the rate limiting process.

[0046] Specifically, in the database proxy's request processing flow, based on the current processing status of the target request, it is determined whether the target request has successfully obtained a backend connection from the master database connection pool. If the determination result is that the target request has not yet obtained a master database connection, the target request is directly rejected, and a preset error message is returned to the corresponding client, thereby preventing the target request from continuing to enter the master database execution flow.

[0047] If the determination result indicates that the target request has already obtained a connection to the master database, before rejecting the execution of the target request, the obtained master database connection is returned to the master database connection pool according to the connection pool management rules, so that the master database connection can be reused by subsequent requests. After completing the connection return operation, the computer device terminates the subsequent execution process of the target request and returns a preset error message to the corresponding client.

[0048] By using the differentiated processing method based on connection acquisition status, the problem of wasting connection resources or inconsistent protocol states caused by directly interrupting requests that have already acquired connections is avoided while implementing rate limiting strategies. This achieves the safe release and stable reuse of master database connection resources.

[0049] In one possible implementation, the method further includes the following steps before executing the rate limiting policy for the master database: Determine whether the primary database is configured to participate in load balancing for read requests; If all read-only nodes are detected to be in a fault state when the primary database is not involved in read request load balancing, read requests originally routed to read-only nodes will be failover and routed to the primary database. If the number of queries per second on the primary database exceeds a preset threshold, a rate limiting policy will be triggered for the primary database. When the primary database participates in read request load balancing, if all read-only nodes are detected to be in a faulty state, read requests will be routed to the primary database in the read node group. When the number of queries per second of the primary database in the read node group exceeds a preset threshold, a rate limiting policy will be triggered for the primary database in the read node group.

[0050] In this embodiment, before executing the rate limiting policy for the master database, it is determined whether the master database participates in read request load balancing, so as to distinguish the rate limiting triggering logic under different read traffic carrying modes.

[0051] Specifically, the computer equipment pre-obtains the routing configuration status of the primary database to determine whether the primary database is configured to participate in read request load balancing. Participating in read request load balancing means that the primary database is included in the read node group, used to share read requests with read-only nodes.

[0052] When the primary database does not participate in read request load balancing, it is only used to process write requests. When all read-only nodes in the database cluster are detected to be in a faulty state, read requests that should have been routed to the read-only nodes undergo failover and are rerouted to the primary database for execution. At this time, the number of queries per second on the primary database is continuously monitored within a preset sampling period. When the number of queries per second on the primary database is detected to be greater than a preset threshold, a rate limiting policy for the primary database is triggered to control the flow of read requests that are concentrated on the primary database due to failover.

[0053] When the primary database participates in read request load balancing, it is configured as a node in the read node group, handling read requests alongside read-only nodes. When all read-only nodes are detected to be in a faulty state, read requests are routed to the primary database in the read node group. At this time, the computer monitors the number of queries per second (QPS) of the primary database within a preset sampling period. When the QPS exceeds a preset threshold, a rate-limiting policy is triggered for the primary database in the read node group to prevent further concentration of read requests to it.

[0054] By distinguishing whether the primary database participates in read request load balancing before the rate limiting policy is executed, and corresponding to different read request routes and rate limiting trigger conditions, fine-grained control of the primary database read load is achieved under various database deployment modes. This avoids the primary database being overwhelmed by abnormal read traffic due to differences in routing policies when all read-only nodes fail.

[0055] As an example, scenario one: the master node does not share read traffic, which means that when the user configures the MySQL node, all read requests are required to be routed to the slave node (read-only node), as follows: group1: master (primary database) group2: slave1 (read-only node 1), slave2 (read-only node 2), slave3 (read-only node 3)... At this point, write requests are routed to group1 by default; read requests are routed to group2 by default. The specific slave2 to which a request is routed is determined by a weighted random algorithm.

[0056] When all slave nodes (slave1, slave2, slave3, etc.) fail (become unavailable), the system will forcibly forward read requests to group1 (i.e., the master). A large number of read requests routed to group1 may cause the master node to become unavailable, or even cause the entire system to fail. Rate limiting is primarily designed to address this scenario. When the system detects that all slave nodes have failed, and the master has processed more requests in the last second than a given threshold, the additional read requests will be directly rejected (only requests transferred to the master due to slave node failures will be rejected; requests originally routed to the master will not be restricted) and will no longer be processed.

[0057] Scenario 2: Master-Server Read Traffic Distribution refers to the requirement that read requests can be partially routed to the master node when configuring MySQL nodes (the specific route is configured by the user through weight). The configuration is as follows: group1: master (primary database) group2: master (the primary database in the read node group), slave1, slave2, slave3... At this point, write requests are routed to group1 by default; read requests are routed to group2 by default. Read requests may be routed to the master or the slave, and a weighted random algorithm is used for random routing.

[0058] When all slave nodes (slave1, slave2, slave3, etc.) fail, read requests will be routed to the master node in group2. In this case, the system will not force read requests to be forwarded to group1. A large number of read requests routed to the master node in group2 may also cause the master node to become unavailable, or even cause the entire system to fail. In this situation, rate limiting is implemented for read requests routed to the master node in group2.

[0059] In one possible implementation, when the primary database participates in read request load balancing, the method further includes: If all read-only nodes are detected to be in a faulty state, read requests will be routed to the primary database in the read node group. If the number of queries per second in the primary database in the read node group exceeds a preset threshold, read requests will be routed to the primary database that is not participating in read request load balancing. When the number of queries per second in the primary database that is not participating in read request load balancing exceeds a preset threshold, a rate limiting policy will be triggered for the primary database in the read node group and for the primary database that is not participating in read request load balancing.

[0060] In this embodiment, when all read-only nodes in the database cluster are detected to be in a faulty state, the read requests are first routed to the master database in the read node group according to the preset read request routing rules to maintain the basic availability of read requests. The master database in the read node group is used to share read requests with the read-only nodes under normal circumstances and has the configuration attribute to participate in read request load balancing.

[0061] After a read request is routed to the primary database in the read node group, the number of queries per second (MS / s) of that primary database within a preset sampling period is continuously monitored. When the number of MS / s of the primary database in the read node group is detected to be greater than a preset threshold, it is determined that the current read load of that primary database has exceeded its capacity. At this time, subsequent read requests are rerouted to primary databases that are not participating in read request load balancing, so as to achieve distributed load balancing of read traffic.

[0062] Meanwhile, the computer equipment continuously monitors the number of queries per second (MS / MS) of primary databases that are not involved in read request load balancing within a preset sampling period. When it detects that the number of MS / MS of primary databases not involved in read request load balancing also exceeds a preset threshold, the computer equipment triggers rate limiting policies for both the primary databases in the read node group and the primary databases not involved in read request load balancing.

[0063] After the rate limiting policy is triggered, the computer device performs flow control processing on read requests routed to the master database in the read node group and read requests routed to the master database that does not participate in read request load sharing, according to the preset rate limiting processing flow. In this extreme scenario where all read-only nodes fail, the multi-master database collaborative bearing and joint rate limiting mechanism can prevent a single master database from being overloaded due to the concentration of read requests.

[0064] In one possible implementation, when the primary database participates in read request load balancing, if the number of queries per second of the primary database in the read node group is less than or equal to a preset threshold, or if the number of read-only nodes recovering from a fault state to a normal state is greater than a quantity threshold, the rate limiting policy of the primary database in the read node group is lifted; if the number of queries per second of the primary database in the read node group is greater than the preset threshold, and the number of read-only nodes recovering from a fault state to a normal state is greater than the quantity threshold, the read requests processed by the primary database in the read node group are routed to the read-only nodes in a normal state.

[0065] In this embodiment, when the primary database participates in read request load sharing, the number of queries per second of the primary database in the read node group within a preset sampling period is monitored, and the changes in the running status of read-only nodes in the database cluster are obtained synchronously.

[0066] The rate limiting policy for the primary database in the read node group will be lifted when either of the following conditions is met: First, if the number of queries per second (MS / S) of the primary database in the read node group is less than or equal to a preset threshold, it indicates that the current load of the primary database has recovered to a manageable level. Second, if the number of read-only nodes that have recovered from a faulty state to a normal state is greater than a preset threshold, it indicates that the read processing capacity of the database cluster has been effectively restored. Meeting either of these conditions ensures that rate limiting restrictions are released promptly after the primary database load decreases or the read-only nodes recover.

[0067] Furthermore, when the number of queries per second (CPS) of the primary database in the read node group is still greater than a preset threshold, and the number of read-only nodes that have recovered from a fault state to a normal state is also greater than the threshold, read requests originally processed by the primary database in the read node group are rerouted to the read-only nodes in a normal state for execution. This gradually migrates read traffic back and reduces the read load on the primary database. Through the above-mentioned coordinated control mechanism of rate limiting lifting and read request migration, the rate limiting status and read request routing strategy are dynamically adjusted according to changes in the primary database load and the recovery status of read-only nodes in scenarios where the primary database participates in read request load sharing. This ensures system stability while improving the resource utilization efficiency of the database cluster during the fault recovery phase.

[0068] S14. If at least one read-only node is detected to have recovered from a fault state to a normal state, the rate limiting policy of the master database is lifted.

[0069] In this embodiment, during the execution of the rate limiting policy for the primary database, the operating status of each read-only node in the database cluster is continuously monitored. When at least one read-only node is detected to have recovered from a faulty state to a normal state, it is determined that the database cluster is capable of handling read requests again. The rate limiting policy for the primary database is then lifted, and the normal request processing flow of the primary database is restored, allowing read requests that were originally controlled by the rate limiting policy to be routed again according to the preset read-write separation rules. By promptly lifting the rate limiting policy for the primary database after the read-only nodes become available, the rate limiting policy is prevented from remaining in effect after the fault is resolved, thereby achieving a smooth transition and performance recovery of the database cluster during the fault recovery phase.

[0070] The database rate limiting method provided in this invention identifies read requests that failover due to read-only node failures and dynamically controls whether rate limiting is triggered on the primary database and the timing of rate limiting release by combining the primary database's query count per second within a preset sampling period with the read-only node's operating status. This achieves fine-grained rate limiting management of primary database read traffic only in abnormal failure scenarios. By introducing connection-aware rate limiting processing, differentiating whether the primary database participates in read request load balancing across multiple scenarios, and automatically releasing rate limiting and migrating read requests back after the read-only node recovers, this effectively avoids primary database overload and cascading failures caused by centralized routing of read requests to the primary database when all read-only nodes fail. This improves the stability, availability, and resource utilization efficiency of the database cluster during the abnormal and recovery phases.

[0071] As an example Figure 2 This is a flowchart illustrating another database rate limiting method provided in an embodiment of the present invention, as shown below. Figure 2 As shown, the method specifically includes: 1. Rate Limiting Entry: All requests that need to be rate limited enter this process. First, perform pre-preparation operations, calculate the main database QPS within the sampling period (default 1 second) through the traffic collection module, and obtain the overall status of the read-only nodes through the RO node (read-only node) status detection module.

[0072] 2. First-level judgment: Is the main current limiting switch turned on? If not, the process will end directly, and the request will be routed normally according to the original rules without triggering rate limiting. If so, proceed to the second level of judgment.

[0073] 3. Second-level judgment: Are all read-only nodes faulty? If not, proceed to step 6; If so, proceed to the next level of judgment.

[0074] 4. Third-level judgment: Is the QPS of the main database greater than the rate limiting threshold? If not, the process ends and normal execution is requested; If so, proceed to the request scenario matching judgment, which requires that one of the following conditions be met: Condition A: The current request is a request "routed to the read group (the master database handles the read traffic)"; Condition B: The current request is a "failover request due to read-only node connection failure"; once any condition is met, proceed to connection status judgment.

[0075] 5. Connection status determination: Has the current request obtained a connection to the backend? If so, the connection is first returned to the connection pool for later reuse, and then an error is returned to the client; If not, an error is returned directly to the client, and the process ends.

[0076] 6. Fallback Decision (Scenarios where the master node shares read traffic) First-level judgment: Is the QPS of the main database greater than the rate limiting threshold? If not, the process ends and normal execution is requested; If so, proceed to the next level of judgment; The second layer of judgment: Should the current request be routed to the master node in the read group? If so, proceed to step 5 to perform connection status determination and corresponding processing; If not, the process ends and normal execution is requested.

[0077] ProxySQL is an open-source, high-performance proxy middleware designed specifically for relational databases such as MySQL. As the main executor of this solution, it operates as a non-blocking state machine. Therefore, when executing the rate-limiting decision module, it should avoid processing intermediate request states. That is, when checking whether a request needs rate limiting, the current request should be in an unexecuted state; otherwise, returned connections cannot be reused. An example is shown below: The PREPARE statement in the binary protocol has a five-state machine. During the execution of each state, if network I / O is not immediately completed, the function immediately exits and processing continues in the next query round. Suppose that during the execution of the ASYNC_STMT_EXECUTE_START state, the function exits because network I / O is not immediately completed (waiting for the backend connection to send packets to the client). In the next query round, rate limiting is triggered, forcibly putting the backend connection back into the connection pool and sending an error to the ProxySQL client. When a subsequent PREPARE statement obtains this connection, it will continue to send new requests to the backend (the client sends packets to the backend connection). At this point, an error will occur due to the inconsistency in the MySQL protocol; the connection expects the client to receive packets instead of sending new packets.

[0078] This embodiment can limit traffic only for failover traffic and read traffic shared by the master node, without affecting normal master database requests such as regular expression matching and hint forced routing. The core rate limiting logic must simultaneously meet the requirements of rate limiting switch being enabled, all read-only nodes failing, and QPS exceeding the threshold to avoid false rate limiting. The acquisition of connections is returned to the pool for reuse by judging the connection status, reducing resource waste. It covers the special scenario of read traffic shared by the master node to prevent uneven load from overwhelming the master database and ensure the comprehensiveness of the rate limiting logic.

[0079] As an example Figure 3 This is a flowchart illustrating another database rate limiting method provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the method specifically includes: In the state machine process of ProxySQL (database proxy) handling SQL requests, the difference between the two rate-limiting logics—one that doesn't check the intermediate request state and one that does—visually demonstrates how this invention solves the connection reuse anomaly problem in non-blocking I / O architectures. Figure 3 Assuming a single SQL request involves multiple query processes, if rate limiting and connection switching are triggered in the intermediate state of the SQL request (i.e., before all processing steps are completed and the request is in a certain execution phase), subsequent requests reusing the connection will encounter errors due to inconsistencies in the MySQL protocol. The left and right columns correspond to two different processing logics, with each process node revolving around the PREPARE statement state machine (the execution phase of the preprocessed statement, which is the core process of the MySQL binary protocol). This involves ProxySQL's non-blocking I / O characteristics (if network I / O does not immediately return a packet during the execution of each state, it returns, waiting for the next round of processing).

[0080] Figure 3 The left column shows the rate limiting logic without the added intermediate state check. The process has a risk of connection reuse anomalies. The steps and English terms are explained below: The state machine initialization (PREPARE statement phase) process begins with the PREPARE (preprocessed statement) state machine and includes three core execution phases (all of which are SQL request processing states, belonging to intermediate states): PROCESSING_STMT_PREPARE: the prepared statement compilation phase, where ProxySQL forwards the SQL template sent by the application to the MySQL backend for compilation; PROCESSING_STMT_EXECUTE: the prepared statement execution phase, where ProxySQL passes parameters to the compiled SQL template and initiates an execution request; PROCESSING_QUERY: the general query processing phase, covering the execution logic of ordinary SQL, running in parallel with the prepared statement process to cover all query scenarios.

[0081] Connection acquisition and rate limiting logic (no intermediate state check): When the process enters the connection acquisition step, ProxySQL requests a connection from the connection pool to the backend MySQL node (master or read-only node), and then executes the rate limiting logic. The rate limiting logic here is the original design without intermediate state check: it only checks the rate limiting switch, the read-only node status, and the QPS threshold, and does not check whether the current request is in an incomplete intermediate state such as PROCESSING_STMT_PREPARE.

[0082] The backend asynchronous state machine execution (non-blocking I / O) enters the backend asynchronous state machine (the underlying architecture of ProxySQL, based on non-blocking I / O design), which includes three key execution states: ASYNC_STMT_EXECUTE_START: Asynchronous preprocessing execution startup phase. ProxySQL sends a request to the backend master database to execute the preprocessed statement. If the network I / O does not immediately return a packet (e.g., the master database response is delayed), it returns immediately (marked "rc=1", indicating that the request is not yet complete), waiting for the next round of query process to continue processing; ASYNC_STMT_EXECUTE_STORE_RESULT_START: Asynchronous preprocessing result storage startup phase. After the master database returns the execution results, ProxySQL begins to receive and store the result set. ASYNC_STMT_EXECUTE_END: ​​The asynchronous preprocessing execution ends, the result is stored, and the request processing flow terminates (marked "end").

[0083] Core flaw: Intermediate state triggering rate limiting causes connection reuse error. If rate limiting is triggered in an intermediate state such as ASYNC_STMT_EXECUTE_START (request not completed), the process will force the current connection to be returned to the connection pool. When subsequent requests reuse the connection, a new SQL request will be sent to the backend, but the backend node still expects to receive the result of the previous request, ultimately resulting in an error due to MySQL protocol inconsistency.

[0084] Figure 3 The right column shows the rate limiting logic after the addition of intermediate state checks, which solves the connection reuse anomaly problem by supplementing the check steps.

[0085] The state machine initialization is the same as in the left column, starting with the PREPARE state machine, which includes three intermediate states: PROCESSING_STMT_PREPARE, PROCESSING_STMT_EXECUTE, and PROCESSING_QUERY, to ensure compatibility with the original request processing flow of ProxySQL.

[0086] The process also starts by obtaining a connection, but a core check is added to the rate limiting logic step: check whether the current request is in an intermediate state of the query (i.e., determine whether the request is executing an incomplete stage such as PROCESSING_STMT_PREPARE, ASYNC_STMT_EXECUTE_START); if the check finds that the request is in an intermediate state: rate limiting is not executed temporarily, and the request waits until it completes the current stage (such as ASYNC_STMT_EXECUTE_END) before re-entering the rate limiting judgment; if the check finds that the request is not in an intermediate state (such as not obtaining a connection, or having completed all stages and waiting to be executed): the rate limiting logic is executed normally (an error is directly reported if no connection is obtained, and an error is reported after the connection is returned to the pool if a connection is obtained).

[0087] The backend asynchronous state machine execution (same as the left column, but without the risk of error) also goes through three stages. Since intermediate scenarios have been excluded before rate limiting, even if rate limiting is triggered, the returned connection is in a state with no incomplete requests, and subsequent request reuse will not cause protocol inconsistency issues.

[0088] Figure 4 This is a schematic diagram of the structure of a database rate limiting system provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the system specifically includes: The monitoring system is responsible for monitoring the operational status of the entire architecture in real time, including the request forwarding status of the Proxy (database proxy), the resource usage (CPU, number of connections) of the MySQL cluster (master and read-only nodes), and the triggering and deactivation status of the rate limiting module. When an anomaly is detected (such as a sudden increase in master database QPS or node failure), the system can trigger an alarm mechanism to notify the operations and maintenance personnel to ensure that the problem is discovered in a timely manner.

[0089] The configuration center, based on the concept of centralized configuration management, stores and manages all configuration parameters required by the solution, including rate limiting switches, rate limiting thresholds, traffic collection time windows, etc. It supports hot reloading of configurations, so that new configurations can take effect in real time without restarting the proxy or application, reducing operation and maintenance costs and avoiding service interruptions caused by configuration changes.

[0090] The management console provides a visual interface, serving as the entry point for operations and maintenance personnel to interact with the architecture. It supports manual operations such as enabling / disabling rate limiting switches, adjusting rate limiting thresholds, viewing rate limiting logs, and monitoring the status of MySQL cluster nodes, making solution management more intuitive and efficient.

[0091] The application and session architecture on the left displays multiple application instances. Each application sends database requests to the Proxy through an independent session (session1, session2, session3). The Proxy (database proxy), acting as middleware between the applications and the MySQL cluster, undertakes the basic functions of request routing and load balancing, and is the core of this solution. The newly added rate limiting modules are all integrated within the Proxy, without altering its original architectural logic. Its core functions include: receiving application requests and initially routing them to the primary database or read-only nodes according to preset rules (such as read-write separation); triggering failover when a read-only node fails, rerouting read requests to the primary database; and simultaneously running three rate limiting modules to control the rate of request flow during failover scenarios.

[0092] All three rate limiting modules rely on a proxy to run and work together to achieve dynamic rate limiting, including: The traffic acquisition module collects the number of queries on the master database at 100ms granularity through an independent monitoring thread and stores it in a circular buffer (capacity 10, corresponding to a 1-second acquisition window). It calculates the master database QPS in the most recent second in real time using a unified formula (queries[end]-queries[begin]) / mysql-throttle_sampling_duration, providing data basis for rate limiting decisions and ensuring that the calculation logic is consistent whether the buffer is full or not.

[0093] The RO node status detection module queries the Proxy's runtime_mysql_servers table (the Proxy's built-in node status table) to perceive the health status of all read-only nodes. If a node fails, it will be marked as SHUNNED in the table. The module determines in real time whether all read-only nodes have failed, providing node status conditions for triggering rate limiting.

[0094] The rate limiting decision module dynamically determines whether to trigger rate limiting based on the output of the first two modules: when the rate limiting switch is turned on, all read-only nodes fail and the QPS of the master database exceeds the rate limiting threshold, rate limiting is triggered, and read requests in the failover scenario are rejected; when some or all read-only nodes recover, rate limiting is automatically lifted, allowing requests to be routed normally to read-only nodes, thus avoiding overload of the master database.

[0095] The MySQL cluster is the final data storage and processing unit of the solution, containing two node types to adapt to a read-write separation architecture: The core node of the master cluster is responsible for handling all write requests (such as data insertion, update, and deletion). In the event of a failover scenario where all read-only nodes fail, it receives read requests originally routed to the read-only nodes. The rate limiting function of this solution only applies to read requests that have been failover to the master, preventing the master from exhausting its CPU, connections, and other resources due to sudden read traffic, thus ensuring the normal processing of write requests.

[0096] The slave nodes of a read-only node cluster synchronize data from the master database through master-slave replication. They only handle read requests and share the read load of the master database, which is the key to the read-write separation architecture. Under normal circumstances, the application's read requests are routed to the read-only nodes by the proxy. Failover and rate limiting logic is only triggered when all read-only nodes fail.

[0097] The data flow and processing logic of the entire architecture can be summarized as follows: The application sends database requests to the Proxy through sessions (session1 / session2 / session3); the Proxy first determines the status of read-only nodes through the RO node status detection module. If the read-only nodes are normal, read requests are routed to the read-only nodes, and write requests are routed to the master database; if all read-only nodes fail, read requests trigger failover and need to be routed to the master database; at this time, the rate limiting decision module, combined with the master database QPS calculated by the traffic collection module, determines whether rate limiting should be triggered: if rate limiting is triggered: the read request is rejected and an error is returned to the application; if rate limiting is not triggered: the read request is routed to the master database for processing; the management console and configuration center provide configuration and monitoring support, and the monitoring system tracks the entire link status in real time to ensure the stable operation of the architecture. This architecture, without introducing additional technical components, only adds a module to the Proxy to implement master database rate limiting, which not only adapts to the original read-write separation architecture, but also solves the core problem of master database overload caused by the failure of all read-only nodes, taking into account both stability and compatibility.

[0098] Figure 5 This is a schematic diagram of a database rate limiting device provided in an embodiment of the present invention, as shown below. Figure 5 As shown, the device specifically includes: The acquisition module 51 is used to acquire the number of queries per second of the master database in the database cluster within a preset sampling period, and to acquire the running status of the read-only nodes in the database cluster. The judgment module 52 is used to determine whether all read-only nodes are in a fault state based on the running status. The control module 53 is used to execute a rate limiting strategy for the master database if it is determined that all read-only nodes are in a fault state and the number of queries per second is greater than a preset threshold. The rate limiting strategy is used to control the flow of target requests routed to the master database. The target request represents the read request routed to the master database due to the failure of the read-only nodes. The control module is also used to lift the rate limiting policy of the master database when it is detected that at least one read-only node has recovered from a fault state to a normal state.

[0099] In one possible implementation, the control module is specifically used to determine whether the target request has already obtained a connection to the main database; If the target request has already obtained a connection to the master database, the master database connection will be returned to the connection pool before the target request is rejected and an error message will be returned to the client. If the target request fails to obtain a connection to the master database, the target request will be rejected and an error message will be returned to the client.

[0100] In one possible implementation, the acquisition module is specifically used to periodically collect the number of queries in the main database using an independent monitoring thread at a preset time granularity, and write the number of queries into a circular buffer. If the circular buffer is not full, the number of queries per second is calculated based on the cumulative number of queries collected from the main database, after normalization according to the preset sampling period. When the circular buffer is full and a rolling update occurs, calculate the difference between the cumulative number of queries corresponding to the latest time granularity and the cumulative number of queries corresponding to the earliest time granularity in the circular buffer. Divide the difference by the preset sampling period to get the number of queries per second.

[0101] In one possible implementation, the control module is also used to determine whether the master database is configured to participate in load balancing of read requests; If all read-only nodes are detected to be in a fault state when the primary database is not involved in read request load balancing, read requests originally routed to read-only nodes will be failover and routed to the primary database. If the number of queries per second on the primary database exceeds a preset threshold, a rate limiting policy will be triggered for the primary database. When the primary database participates in read request load balancing, if all read-only nodes are detected to be in a faulty state, read requests will be routed to the primary database in the read node group. When the number of queries per second of the primary database in the read node group exceeds a preset threshold, a rate limiting policy will be triggered for the primary database in the read node group.

[0102] In one possible implementation, the control module is further configured to route read requests to the master database in the read node group if all read-only nodes are detected to be in a fault state. If the number of queries per second of the primary database in the read node group exceeds the preset threshold, the read request will be routed to the primary database that is not participating in read request load balancing. When the number of queries per second of the master database that does not participate in read request load balancing exceeds the preset threshold, a rate limiting policy is triggered for the master database in the read node group, and a rate limiting policy is also triggered for the master database that does not participate in read request load balancing.

[0103] In one possible implementation, the control module is further configured to, when the primary database participates in read request load sharing, release the rate limiting policy of the primary database in the read node group if the number of queries per second of the primary database in the read node group is less than or equal to a preset threshold, or if the number of read-only nodes that recover from a fault state to a normal state is greater than a number threshold. If the number of queries per second of the primary database in the read node group exceeds a preset threshold, and the number of read-only nodes that recover from a fault state to a normal state exceeds a quantity threshold, then the read requests processed by the primary database in the read node group will be routed to the read-only nodes in a normal state.

[0104] In one possible implementation, the control module is further configured to determine the reason why a request is routed to the master database if any request is routed to the master database. If the failure occurs due to a read-only node connection failure and the request is forcibly routed to the primary database, execute the step of obtaining the number of queries per second in the primary database of the database cluster within a preset sampling period.

[0105] Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Figure 6 The computer device 600 shown includes at least one processor 601, a memory 602, at least one network interface 604, and other user interfaces 603. The various components in the computer device 600 are coupled together via a bus system 605. It is understood that the bus system 605 is used to implement communication between these components. In addition to a data bus, the bus system 605 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 6 The general designated all buses as Bus System 605.

[0106] The user interface 603 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0107] It is understood that the memory 602 in this embodiment of the invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 602 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0108] In some implementations, memory 602 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 6021 and application program 6022.

[0109] The operating system 6021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 6022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this embodiment can be included in the application program 6022.

[0110] In this embodiment of the invention, by calling the program or instructions stored in memory 602, specifically the program or instructions stored in application program 6022, processor 601 executes the method steps provided in each method embodiment, including, for example: The system obtains the number of queries per second in the master database of the database cluster within a preset sampling period, as well as the running status of the read-only nodes in the database cluster. Determine whether all read-only nodes are in a fault state based on the operating status; If it is determined that all read-only nodes are in a fault state and the number of queries per second is greater than a preset threshold, a rate limiting policy is executed for the master database. The rate limiting policy is used to control the flow of target requests routed to the master database. The target request represents a read request routed to the master database due to the failure of the read-only nodes. If at least one of the read-only nodes is detected to have recovered from a faulty state to a normal state, the rate limiting policy of the master database is lifted.

[0111] The methods disclosed in the above embodiments of the present invention can be applied to processor 601, or implemented by processor 601. Processor 601 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 601 or by instructions in the form of software. The processor 601 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 602. Processor 601 reads the information in memory 602 and, in conjunction with its hardware, completes the steps of the above method.

[0112] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0113] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0114] The computer device provided in this embodiment may be as follows: Figure 6 The device shown can perform, for example Figure 1 All steps of the method, thus achieving Figure 1 For details on the technical effects of the method shown, please refer to [link / reference]. Figure 1 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0115] This invention also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.

[0116] When one or more programs in the storage medium can be executed by one or more processors to achieve the above-described method of execution on the device side.

[0117] The processor is used to execute a database rate limiting program stored in memory to implement the following steps of a database rate limiting method executed on the device side: The system obtains the number of queries per second in the master database of the database cluster within a preset sampling period, as well as the running status of the read-only nodes in the database cluster. Determine whether all read-only nodes are in a fault state based on the operating status; If it is determined that all read-only nodes are in a fault state and the number of queries per second is greater than a preset threshold, a rate limiting policy is executed for the master database. The rate limiting policy is used to control the flow of target requests routed to the master database. The target request represents a read request routed to the master database due to the failure of the read-only nodes. If at least one of the read-only nodes is detected to have recovered from a faulty state to a normal state, the rate limiting policy of the master database is lifted.

[0118] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0119] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0120] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A database rate limiting method, characterized in that, include: The system obtains the number of queries per second in the master database of the database cluster within a preset sampling period, as well as the running status of the read-only nodes in the database cluster. Determine whether all read-only nodes are in a fault state based on the operating status; If it is determined that all read-only nodes are in a fault state and the number of queries per second is greater than a preset threshold, a rate limiting policy is executed for the master database. The rate limiting policy is used to control the flow of target requests routed to the master database. The target request represents a read request routed to the master database due to the failure of the read-only nodes. If at least one of the read-only nodes is detected to have recovered from a faulty state to a normal state, the rate limiting policy of the master database is lifted.

2. The method according to claim 1, characterized in that, The execution of the rate limiting policy for the master database includes: Determine whether the target request has already obtained a connection to the main database; If the target request has already obtained a master database connection, the master database connection is returned to the connection pool, the target request is rejected, and an error message is returned to the client. If the target request fails to obtain a connection to the master database, the target request will be rejected and an error message will be returned to the client.

3. The method according to claim 1, characterized in that, The step of obtaining the number of queries per second in the master database of the database cluster within a preset sampling period includes: An independent monitoring thread periodically collects the number of queries in the main database according to a preset time granularity, and writes the number of queries into a circular buffer; If the circular buffer is not full, the number of queries per second is calculated based on the cumulative number of queries collected from the main database, after normalization according to a preset sampling period. When the circular buffer is full and a rolling update occurs, calculate the difference between the cumulative number of queries corresponding to the latest time granularity and the cumulative number of queries corresponding to the earliest time granularity in the circular buffer. Divide the difference by the preset sampling period duration to obtain the number of queries per second.

4. The method according to claim 1, characterized in that, Before executing the rate limiting policy for the master database, the method further includes: Determine whether the master database is configured to participate in load balancing for read requests; If the primary database does not participate in read request load balancing, and all read-only nodes are detected to be in a fault state, then read requests originally routed to the read-only nodes will be failover and routed to the primary database. If the number of queries per second of the primary database exceeds the preset threshold, the rate limiting policy will be triggered for the primary database. When the primary database participates in read request load balancing, if all the read-only nodes are detected to be in a fault state, the read requests will be routed to the primary database in the read node group, and when the number of queries per second of the primary database in the read node group exceeds the preset threshold, a rate limiting policy will be triggered for the primary database in the read node group.

5. The method according to claim 4, characterized in that, When the primary database participates in read request load balancing, the method further includes: If all the read-only nodes are detected to be in a fault state, the read request will be routed to the master database in the read node group. If the number of queries per second of the master database in the read node group is greater than the preset threshold, the read request will be routed to the master database that is not participating in read request load balancing. When the number of queries per second of the master database that does not participate in read request load balancing exceeds the preset threshold, a rate limiting policy is triggered for the master database in the read node group, and a rate limiting policy is also triggered for the master database that does not participate in read request load balancing.

6. The method according to claim 5, characterized in that, The method further includes: When the primary database participates in read request load balancing, if the number of queries per second of the primary database in the read node group is less than or equal to the preset threshold, or if the number of read-only nodes that recover from a fault state to a normal state is greater than the number threshold, the rate limiting policy of the primary database in the read node group is lifted. If the number of queries per second in the primary database of the read node group is greater than the preset threshold, and the number of read-only nodes that recover from a fault state to a normal state is greater than the number threshold, then the read requests processed by the primary database in the read node group will be routed to the read-only nodes in a normal state.

7. The method according to claim 1, characterized in that, Before obtaining the number of queries per second in the master database of the database cluster within a preset sampling period, the method further includes: In the case that any request is routed to the master database, determine the reason why the request was routed to the master database; If the reason is that the request fails to acquire a connection to the read-only node and is forcibly routed to the primary database, the step of obtaining the number of queries per second of the primary database in the database cluster within a preset sampling period is executed.

8. A database rate limiting device, characterized in that, include: The acquisition module is used to acquire the number of queries per second of the master database in the database cluster within a preset sampling period, as well as the running status of the read-only nodes in the database cluster. The judgment module is used to determine whether all the read-only nodes are in a fault state based on the operating status. The control module is used to execute a rate limiting policy for the master database if it is determined that all the read-only nodes are in a fault state and the number of queries per second is greater than a preset threshold. The rate limiting policy is used to control the flow of target requests routed to the master database. The target request represents a read request routed to the master database due to the fault of the read-only nodes. The control module is also used to remove the rate limiting policy of the master database when it is detected that at least one of the read-only nodes has recovered from a fault state to a normal state.

9. A computer device, characterized in that, include: A processor and a memory, the processor being configured to execute a database rate limiting program stored in the memory to implement the database rate limiting method according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the database rate limiting method according to any one of claims 1 to 7.

Images