Method for adjusting database load, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention provides a method for adjusting a database load, electronic equipment, a storage medium and a program product. Determining current load information of each slave node in the database; the load information is used for indicating the operation state of the slave node; updating the service request allocation weight of each slave node according to the current load information and the historical load information; and distributing a to-be-processed request to each slave node based on the updated service request distribution weight. According to the method, adaptive load balancing of the slave nodes of the database can be realized, and the database response stability and the resource utilization rate are improved.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a method for adjusting database load, electronic equipment, storage medium, and program product. Background Technology

[0002] In high-concurrency internet business scenarios, databases need to process massive read requests within a short period of time. To improve system throughput, existing technologies typically employ a master-slave replication architecture, routing write operations to the master node and distributing read operations to multiple slave nodes, thereby decoupling read and write operations and effectively alleviating the performance bottleneck of a single node. Requests are allocated based on the static weights of the slave nodes.

[0003] However, the static weight allocation mechanism used in existing technologies cannot quickly adjust request allocation according to current load changes, resulting in some slave nodes experiencing response delays or even crashes due to overload, while some slave node resources remain idle. Summary of the Invention

[0004] This application provides a method, electronic device, storage medium, and program product for adjusting database load, in order to solve the problem in the prior art that the use of static request weight allocation causes some slave nodes to be overloaded and some nodes to be idle when business traffic changes suddenly, thereby affecting the stability and resource utilization efficiency of the database system.

[0005] In a first aspect, embodiments of this application provide a method for adjusting database load, including:

[0006] Determine the current load information of each slave node in the database; the load information is used to indicate the operating status of the slave nodes;

[0007] Based on the current load information and historical load information, update the service request allocation weights of each slave node;

[0008] Based on the updated service request allocation weights, the requests to be processed are distributed to each slave node.

[0009] In one possible implementation, the load information includes: CPU utilization, memory usage, query response time, and connection pool utilization; determining the current load information of each slave node in the database includes:

[0010] Obtain the current CPU utilization, memory usage, query response time, and connection pool utilization of each slave node in the database, and normalize them to obtain the corresponding standard values.

[0011] The standard values ​​are weighted and summed according to preset weights to obtain the current load information of each slave node.

[0012] In one possible implementation, updating the service request allocation weights of each slave node based on the current load information and historical load information includes:

[0013] Calculate the fluctuation coefficient of the current load information compared to the historical load information;

[0014] Based on the fluctuation coefficient, an adjustment parameter for the allocation weight of the service request is determined, wherein the adjustment parameter indicates the proportion of the current load information when updating the allocation weight of the service request;

[0015] Based on the adjustment parameters, update the service request allocation weights for each slave node.

[0016] In one possible implementation, determining the adjustment parameter for allocating the service request weight based on the fluctuation coefficient includes:

[0017] If the fluctuation coefficient is greater than the first preset threshold, then the adjustment parameter is determined to be within the first value range;

[0018] If the fluctuation coefficient is less than the second preset threshold, then the adjustment parameter is determined to be within the second value range;

[0019] The adjustment parameter is determined based on the fluctuation coefficient and the range of values ​​for the adjustment parameter.

[0020] In one possible implementation, updating the service request allocation weights of each slave node according to the adjustment parameters includes:

[0021] Based on the adjustment parameters, determine the first weight value of the current load information and the second weight value of the historical load average.

[0022] The current load information and the historical average load are weighted and summed based on the first weight value and the second weight value to obtain the current load assessment value of each slave node;

[0023] Update the service request allocation weights of each slave node based on the current load assessment value of each slave node.

[0024] In one possible implementation, the step of distributing the requests to be processed to each slave node based on the updated service request allocation weight includes:

[0025] Distribute the pending requests to each slave node according to the updated business request weight allocation;

[0026] or,

[0027] If there are pending requests that have entered the slave node allocation queue, then the requests that have entered the node allocation queue will be distributed to each slave node according to the business request allocation weight before the update.

[0028] Once the distribution of requests that have entered the slave node allocation queue has ended, the requests to be processed are distributed to each slave node according to the updated business request allocation weight.

[0029] In one possible implementation, the method further includes:

[0030] If the fluctuation coefficient is between the first preset threshold and the second preset threshold, the range of the adjustment parameter is determined by linear interpolation.

[0031] Secondly, embodiments of this application provide an apparatus for adjusting database load, comprising:

[0032] The determination module is used to determine the current load information of each slave node in the database; the load information is used to indicate the operating status of the slave nodes.

[0033] The processing module is used to update the service request allocation weight of each slave node based on the current load information and historical load information.

[0034] The processing module is also used to assign weights to the updated business requests and distribute the requests to be processed to each slave node.

[0035] In one possible implementation, the apparatus further includes: an acquisition module;

[0036] The acquisition module is used to acquire the current CPU usage, memory usage, query response time, and connection pool usage of each slave node in the database.

[0037] The processing module is also used to normalize the CPU utilization, memory usage, query response time and connection pool utilization to obtain the corresponding standard values.

[0038] The processing module is further configured to perform a weighted summation of the standard values ​​according to a preset weight to obtain the current load information of each slave node.

[0039] In one possible implementation, the device further includes: a computing module;

[0040] The calculation module is used to calculate the fluctuation coefficient of the current load information compared with the historical load information;

[0041] The determining module is further configured to determine an adjustment parameter for the allocation weight of the service request based on the fluctuation coefficient, wherein the adjustment parameter indicates the proportion of the current load information when updating the allocation weight of the service request;

[0042] The processing module is also used to update the service request allocation weight of each slave node according to the adjustment parameters.

[0043] In one possible implementation, the determining module is further configured to determine the adjustment parameter as a first value range when the fluctuation coefficient is greater than a first preset threshold.

[0044] The determining module is further configured to determine the adjustment parameter as a second value range when the fluctuation coefficient is less than a second preset threshold.

[0045] The determining module is further configured to determine the adjustment parameter based on the fluctuation coefficient and the range of values ​​of the adjustment parameter.

[0046] In one possible implementation, the determining module is further configured to determine a first weight value of the current load information and a second weight value of the historical load average value based on the adjustment parameters;

[0047] The processing module is further configured to perform a weighted summation of the current load information and the historical load average value based on the first weight value and the second weight value to obtain the current load evaluation value of each slave node;

[0048] The processing module is also used to update the service request allocation weight of each slave node according to the current load assessment value of each slave node.

[0049] In one possible implementation, the processing module is further configured to distribute the requests to be processed to each slave node according to the updated business request allocation weight;

[0050] The processing module is also used to distribute the requests that have entered the node allocation queue to each slave node according to the business request allocation weight before the update when there are requests to be processed that have entered the slave node allocation queue.

[0051] The processing module is also used to distribute the pending requests to each slave node according to the updated business request allocation weight after the request distribution that has entered the slave node allocation queue has ended.

[0052] In one possible implementation, the determining module is further configured to determine the range of the adjustment parameter by linear interpolation when the fluctuation coefficient is between the first preset threshold and the second preset threshold.

[0053] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0054] The memory stores computer-executed instructions;

[0055] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0056] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0057] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0058] The method, electronic device, storage medium, and program products for adjusting database load provided in this application collect load information (CPU utilization, memory usage, query response time, and connection pool utilization) that reflects the current operating status of each slave node in real time. Combined with the historical load information of the slave node over a period of time, a new weight value is determined to determine "how many requests should be allocated to this slave node." According to the new weight value, user requests are intelligently distributed to various slave nodes, allowing the request distribution strategy to adapt to differences in slave node performance. When the load of a slave node suddenly increases, its weight is automatically reduced to decrease the influx of new requests; idle nodes receive higher weights and can handle more requests. This avoids node overload and resource idleness problems caused by static weights, thereby improving database response stability and resource utilization. Attached Figure Description

[0059] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0060] Figure 1 A schematic diagram illustrating a scenario for a method of adjusting database load provided in this application;

[0061] Figure 2 A flowchart illustrating a method for adjusting database load provided in this application. Figure 1 ;

[0062] Figure 3 A flowchart illustrating a method for adjusting database load provided in this application. Figure 2 ;

[0063] Figure 4 A schematic diagram of a device for adjusting database load provided in this application;

[0064] Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application.

[0065] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0066] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0067] First, let me explain the terms used in this application:

[0068] A slave node, in a master-slave replication architecture, is a database instance that receives synchronized data from the master node and processes read requests. Slave nodes do not accept write operations; their data is replicated from the master node asynchronously or semi-synchronously. They are primarily used to distribute read load and improve the overall concurrency of the database.

[0069] A connection pool is a set of persistent connections to a database server that is pre-created and maintained by the database client or middleware at runtime. When an application needs to perform a database operation, it obtains an idle connection from the connection pool and returns the connection to the pool after use, rather than frequently creating and destroying physical connections.

[0070] Load: refers to the resource consumption and service pressure borne by a node during operation. The higher the load, the closer the node's current processing capacity is to its limit, and continuing to allocate requests may lead to performance degradation or timeouts.

[0071] Weight: In load balancing, weight is a numerical parameter assigned to each slave node to determine the proportion of requests it receives. The higher the weight, the higher the probability that the node will be selected to process requests.

[0072] In high-concurrency internet business scenarios, databases need to process massive read requests in a short period of time, which places extremely high demands on the database's response speed and stability.

[0073] To improve overall throughput and ensure service availability, existing technologies typically employ a master-slave replication architecture: the master node is responsible for handling all write operations (such as insert, update, and delete), while the slave nodes replicate data from the master node asynchronously or semi-synchronously and are dedicated to handling read requests (such as query operations).

[0074] In the above architecture, request distribution usually relies on a static weight mechanism, that is, a set of fixed weights are pre-set during the system deployment phase based on the hardware configuration of each slave node, and remain unchanged during operation; subsequent requests are then distributed to each slave node according to these static weights.

[0075] However, the static weight allocation mechanism cannot detect real-time load changes of slave nodes during operation (such as a sudden increase in CPU utilization or a longer query response time). This leads to some slave nodes becoming overloaded due to continuously receiving requests that exceed their processing capacity, resulting in response delays or even service interruptions, while other slave nodes with lighter loads remain idle due to their fixed weights.

[0076] To address the aforementioned issues, this application proposes a method for adjusting database load. This method continuously collects the real-time operating status of each slave node (such as CPU utilization, memory usage, query response time, and connection pool utilization) and combines this data with historical load trends to adaptively generate business request allocation weights that match the actual processing capacity of the slave nodes. Specifically, nodes with lower loads receive higher allocation weights, and vice versa. This method achieves adaptive load balancing of database slave nodes, improving database response stability and resource utilization.

[0077] Figure 1 A schematic diagram illustrating a scenario for the method of adjusting database load provided in this application, such as... Figure 1As shown, this application can be applied to database service systems in high-concurrency internet business backends. Taking a major e-commerce platform promotion as an example, when millions of users are simultaneously online shopping for goods, the database needs to process hundreds of thousands of read requests per second, such as product detail queries and inventory checks. In this scenario, the database adopts a master-slave architecture, with write operations handled by the master node and massive read requests distributed among multiple slave nodes. In this scenario, the method of this application automatically runs in the database middleware or load balancing proxy: it collects load information such as CPU utilization, memory usage, query response time, and connection pool utilization of each slave node in real time, and dynamically calculates the current business request allocation weight for each slave node based on its historical load change trends. For example, when an older slave node slows down due to a sudden high load, its allocation weight is automatically reduced; while high-performance idle nodes receive higher weights and handle more requests. The entire database load adjustment process requires no manual intervention, and the weight update is completed within milliseconds without restarting the service or modifying the configuration. Subsequent requests are then intelligently distributed to slave nodes through weighted round-robin. Users are unaware of the issue and consistently receive fast and stable query responses. Furthermore, operations and maintenance personnel do not need to manually optimize or expand the database before major promotional events, significantly improving database response stability and resource utilization.

[0078] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0079] Figure 2 A flowchart illustrating the method for adjusting database load provided in this application. Figure 1 ,like Figure 2 As shown, the method includes:

[0080] S101. Determine the current load information of each slave node in the database.

[0081] Understandably, current load information refers to runtime metrics that characterize the current resource usage and service pressure of a node, and its value changes dynamically with the actual workload of the node.

[0082] One possible implementation involves periodically (e.g., every 5 seconds) collecting at least one of the following raw performance data from the operational database engine of each slave node as current load information: CPU (Central Processing Unit) utilization, memory usage, query response time, and connection pool utilization. The collected data directly reflects the operating status of the slave nodes at the time of collection and serves as the basis for subsequent load assessment.

[0083] This process requires no modification to the database configuration and can be implemented through a standard monitoring interface, ensuring the universality and deployability of the method in this application.

[0084] S102. Update the service request allocation weights of each slave node based on the current load information and historical load information.

[0085] Understandably, for each slave node, its latest current load information is analyzed together with the historical load information accumulated over a period of time, and the weight of business requests allocated to that slave node is dynamically adjusted based on the analysis results.

[0086] Historical load information refers to the load status data recorded by the slave node before the current moment, such as the load value of the previous period, the load sequence of multiple recent periods, or the load trend characteristics after statistical processing.

[0087] The business request allocation weight is a value used to determine the probability that a slave node will be selected during the request distribution process. The higher the weight, the more requests will be routed to that node.

[0088] One possible implementation involves comparing and processing the current load information with historical load information to determine whether the current load status of the slave node has changed significantly. If the current load is significantly higher than the historical level, its allocation weight is reduced to avoid overload; if the current load is low or stable, the status quo is maintained or its allocation weight is appropriately increased to make full use of idle resources.

[0089] Update the business request allocation weights of each slave node. The business request allocation weights of each slave node can be automatically updated as its actual operating status changes, realizing dynamic adaptation of the request distribution strategy.

[0090] Optionally, the above-mentioned weight allocation update process is triggered by the load balancer after each collection of current load information, ensuring that the weight allocation always reflects the service capacity of the slave node in the most recent time period.

[0091] S103. Based on the updated business request allocation weights, distribute the requests to be processed to each slave node.

[0092] Understandably, after obtaining the updated business request allocation weights from each slave node, the newly arriving pending requests are routed according to the updated allocation weight values, and each request is directed to one of the slave nodes for processing.

[0093] One possible implementation is to assign weights to each slave node based on the current business requests they are currently handling, distributing requests proportionally. Slave nodes with higher weights are more likely to be selected and thus receive more requests; slave nodes with lower weights receive fewer requests accordingly.

[0094] The above-mentioned pending request distribution process is executed in real time each time a new request arrives, ensuring that requests are always routed according to the latest weight configuration, so that the actual load of each slave node is consistent with its assigned weight.

[0095] The method for adjusting database load provided in this application collects load information (CPU utilization, memory usage, query response time, and connection pool utilization) that reflects the current operating status of each slave node in real time. Combined with the historical load information of the slave node over a period of time, a new weight value is determined to determine "how many requests should be allocated to this slave node." According to the new weight value, user read requests are intelligently distributed to each slave node, allowing the request distribution strategy to adapt to differences in slave node performance. When the load of a slave node suddenly increases, its weight is automatically reduced to decrease the influx of new requests; idle nodes receive higher weights and can handle more requests. This avoids node overload and resource idleness problems caused by static weights, thereby improving database response stability and resource utilization.

[0096] Figure 3 A flowchart illustrating the method for adjusting database load provided in this application. Figure 2 ,like Figure 3 As shown, in this embodiment... Figure 2 Based on the examples, a method for adjusting database load is described in detail, which includes:

[0097] S201. Obtain the current CPU utilization, memory usage, query response time, and connection pool utilization of each slave node in the database, and normalize them to obtain the corresponding standard values.

[0098] Central Processing Unit (CPU) utilization: refers to the proportion of time the CPU is currently occupied, reflecting the degree of strain on computing resources;

[0099] Memory utilization rate: refers to the percentage of total available memory that is in use, reflecting the degree of memory resource scarcity;

[0100] Query response time: refers to the average response time of queries over a recent period, directly reflecting whether users perceive a response delay;

[0101] Connection pool utilization: refers to the proportion of currently active database connections to the maximum capacity of the connection pool, reflecting the bottleneck of concurrent processing capabilities.

[0102] One possible implementation is to use a database monitoring agent or a built-in data collection module to obtain the CPU usage, memory usage, query response time, and connection pool usage of each slave node at fixed time intervals.

[0103] To eliminate differences in the units and value ranges of different indicators, the raw load data were normalized. For example, min-max normalization was used to map each raw load data to... Interval, specifically

[0104] If the current indicator value is less than the minimum threshold, the standard value is 0;

[0105] If the current indicator value is greater than the maximum threshold, the standard value is set to 1;

[0106] If the current indicator value is between the minimum threshold and the maximum threshold

[0107]

[0108] The maximum and minimum thresholds are set based on hardware specifications or historical experience.

[0109] S202. The standard values ​​are weighted and summed according to preset weights to obtain the current load information of each slave node.

[0110] Understandably, after obtaining the normalized standard values ​​of CPU utilization, memory usage, query response time, and connection pool utilization for each slave node, these standard values ​​are combined according to pre-configured weights to obtain a comprehensive value, which serves as a representation of the current load status of the slave node.

[0111] The preset weights refer to the importance coefficients set for different performance dimensions, reflecting the sensitivity of the business scenario to the consumption of various resources. For example, in online transaction scenarios that are highly sensitive to query latency, a higher weight is assigned to the standard value of "query response time"; in compute-intensive scenarios, a higher weight is assigned to the standard value of "CPU utilization". It is important to note that the preset weights can be manually configured by operations personnel during the database deployment phase according to business characteristics, or dynamically adjusted through configuration files or management interfaces, remaining unchanged during a single load calculation. The preset weights are non-negative real numbers, and their sum is 1.

[0112] One possible implementation is that for a given slave node, the standard values ​​for CPU utilization, memory usage, query response time, and connection pool utilization are as follows: , , , The corresponding preset weights are as follows: , , , The current load information of the slave node is then calculated using the following formula:

[0113]

[0114] The current load information is a scalar value between 0 and 1. The larger the value, the heavier the overall load of the slave node.

[0115] S203. Calculate the fluctuation coefficient of the current load information compared to the historical load information.

[0116] Understandably, for each slave node, after obtaining its current load information, its current load information is compared with the historical load information previously recorded by the node to quantify the degree of change of the current load state relative to the historical level, and the degree of change is expressed as a dimensionless value, namely the fluctuation coefficient.

[0117] Historical load information refers to one or more load data that the slave node has stored before the current moment, such as a sequence of load information for the most recent N periods (e.g., N=5).

[0118] The fluctuation coefficient is used to reflect the relative magnitude of load changes. The larger the fluctuation coefficient, the more significantly the current load deviates from historical levels, which may indicate sudden traffic or performance abnormalities.

[0119] One possible implementation involves reading the historical load information of the slave node for the most recent N periods from a local cache or state storage, obtaining a historical load information sequence. The arithmetic mean of the historical load data for these N periods is then calculated to obtain the historical load average. Finally, a relative deviation formula is used to calculate the fluctuation coefficient of the current load information relative to the historical load average. Specifically:

[0120]

[0121] The larger the fluctuation coefficient, the more drastic the change in the current load of the slave node.

[0122] S204. If the fluctuation coefficient is greater than the first preset threshold, then the adjustment parameter is determined to be within the first value range.

[0123] Understandably, the calculated fluctuation coefficient is compared with a pre-configured first preset threshold. Based on the comparison result, a corresponding value range is selected from multiple preset numerical intervals as a candidate interval for the adjustment parameter. Specifically, if the fluctuation coefficient is greater than the first preset threshold, the value range of the adjustment parameter is determined as the first value range.

[0124] The adjustment parameter is a numerical variable used to control the degree of influence of the current load information during subsequent processing. The first value range is the allowable range of values ​​for the adjustment parameter in high-fluctuation scenarios (e.g., ...). A larger value in the first range indicates that when updating the weight allocation of business requests to each slave node, more emphasis is placed on the current load information.

[0125] One possible implementation is to determine that the load state of a slave node has changed drastically compared to historical load information when the fluctuation coefficient of a slave node exceeds a first preset threshold. In this case, the adjustment parameters of the slave node are limited to a first value range. For example, .

[0126] S205. If the fluctuation coefficient is less than the second preset threshold, then the adjustment parameter is determined to be within the second value range.

[0127] Understandably, the calculated fluctuation coefficient is compared with a pre-configured second preset threshold. Based on the comparison result, a corresponding value range is selected from multiple preset numerical intervals as a candidate interval for the adjustment parameter. Specifically, when the fluctuation coefficient is less than the second preset threshold, the value range of the adjustment parameter is determined as the second value range.

[0128] The second preset threshold is a non-negative real number, and is less than the aforementioned first preset threshold. The second value range is the range of values ​​that the adjustment parameter is allowed to take in low-fluctuation scenarios (e.g., The smaller value in the second range indicates that when updating the weight of business requests allocated to each slave node, more emphasis is placed on historical load information in order to maintain the stability of the allocation strategy.

[0129] One possible implementation is to determine that when the fluctuation coefficient of a slave node is less than a second preset threshold, the load status of that slave node is basically consistent with historical load information and shows no significant change. In this case, the adjustment parameters of the slave node are limited to the second value range. For example... .

[0130] It should be noted that the first and second value ranges can be preset through configuration files or management interfaces and remain unchanged during runtime. This mechanism enables a more sensitive processing strategy to the current state when the load changes abruptly, providing basic support for subsequent dynamic adjustments.

[0131] S206. Determine the adjustment parameters based on the fluctuation coefficient and the range of adjustment parameter values.

[0132] Understandably, after determining the range of adjustment parameters based on the fluctuation coefficient's range (such as high or low volatility), a specific adjustment parameter value is then determined within that range using linear interpolation based on the specific value of the fluctuation coefficient.

[0133] Within each fluctuation range, the specific value of the adjustment parameter is linearly related to the magnitude of the fluctuation coefficient. Taking the high fluctuation range as an example: the larger the fluctuation coefficient, the more drastic the current load change, and the larger the determined adjustment parameter value should be, but it should not exceed the upper limit of the range; the closer the fluctuation coefficient is to the first preset threshold, the closer the adjustment parameter value is to the lower limit of the range. Similarly, in the low fluctuation range, the smaller the fluctuation coefficient, the smaller the adjustment parameter value, in order to maintain the stability of the allocation strategy.

[0134] By using the above method, an adjustment parameter value that matches the current load change can be smoothly generated within the corresponding value range based on the subtle differences in the fluctuation parameter, avoiding problems such as insufficient response or oversensitivity caused by fixed values.

[0135] In some embodiments, if the fluctuation coefficient is between a first preset threshold and a second preset threshold, the range of values ​​for the adjustment parameter is determined by linear interpolation.

[0136] Understandably, when the fluctuation coefficient is greater than the second preset threshold but less than the first preset threshold, the load state of the slave node is determined to be at a moderate fluctuation level, neither a drastic change nor a lack of significant change. In this case, the value of the adjustment parameter is no longer fixed to the range corresponding to high or low fluctuation, but is dynamically determined by linear interpolation between the upper limit of the adjustment parameter corresponding to low fluctuation and the lower limit of the adjustment parameter corresponding to high fluctuation, based on the specific value of the fluctuation coefficient.

[0137] One possible implementation is to assign a lower adjustment parameter value (i.e., the upper limit of the second value range) to the second preset threshold, and a higher adjustment parameter value (i.e., the lower limit of the first value range) to the first preset threshold. When the fluctuation coefficient changes continuously between these two values, the adjustment parameter value also smoothly transitions between these two boundary values: the closer the fluctuation coefficient is to the first preset threshold, the closer the adjustment parameter is to the lower limit of the first value range; the closer the fluctuation coefficient is to the second preset threshold, the closer the adjustment parameter is to the upper limit of the second value range.

[0138] By using a linear interpolation mechanism, fine-tuning of adjustment parameters can be achieved when the load change level is in an intermediate state, avoiding sudden changes in the allocation strategy caused by interval switching, thereby improving the continuity and stability of the load balancing process.

[0139] S207. Based on the adjustment parameters, determine the first weight value of the current load information and the second weight value of the historical load average.

[0140] Understandably, the adjustment parameter characterizes the level of confidence or responsiveness to the current load state, and its value is limited to between 0 and 1, serving as the first weight value for the current load information. Correspondingly, the second weight value for the historical load average is obtained by subtracting the aforementioned adjustment parameter from 1, ensuring that the sum of the first weight value for the current load information and the second weight value for the historical load average is 1.

[0141] Specifically, when the adjustment parameter is large, it indicates that the current load has changed significantly, and the update of the service request allocation weight of each slave node relies more on the current load information. In this case, the first weight value is higher and the second weight value is lower. Conversely, when the adjustment parameter is small, it indicates that the load is stable, and the update of the service request allocation weight of each slave node relies more on the historical load average value. In this case, the first weight value is lower and the second weight value is higher.

[0142] By using the above method, the relative importance of the current load information and the historical load average in the subsequent distribution and processing of pending requests can be dynamically allocated according to the adjustment parameters, laying the foundation for achieving adaptive load.

[0143] S208. The current load information and the historical average load are weighted and summed based on the first weight value and the second weight value to obtain the current load evaluation value of each slave node.

[0144] Understandably, for each slave node, the current load information calculated in the current period and the historical average load are multiplied by the corresponding first weight value and second weight value respectively, and then added together to obtain a value, which is used as the load evaluation value of the slave node in the current period.

[0145] The current load information reflects the latest resource usage of the slave node, while the historical load average represents its previous overall load trend. The two are combined through weighted matching. Since the sum of the first and second weight values ​​is 1, the weighted summation result remains within a reasonable numerical range (such as between 0 and 1) and can smoothly reflect the continuity and variability of the load status.

[0146] For example, when in a highly volatile state, the first weight value is larger, and the weighted result is closer to the current load information, thus enabling a rapid response to sudden loads; when in a stable state, the second weight value dominates, and the weighted result is closer to the historical load average, effectively suppressing instantaneous noise interference.

[0147] Through the above weighted summation operation, a current load assessment value is generated for each slave node that takes into account both the latest state and historical performance, serving as a unified indicator to measure its current service capacity.

[0148] S209. Update the service request allocation weight of each slave node according to the current load assessment value of each slave node.

[0149] Understandably, based on the latest calculated current load assessment value of each slave node, a corresponding business request allocation weight is generated through a preset mapping relationship, and the original allocation weight is replaced with this weight, thereby updating the business request allocation weight of each slave node.

[0150] The mapping relationship follows the principle that the lower the load, the higher the allocation weight. Specifically, the current load assessment value reflects the overall load level of the slave node. The larger the value, the busier the node is and the closer its processing capacity is to saturation. Therefore, when generating the allocation weight, this value is reversed so that high-load nodes receive lower allocation weights and low-load nodes receive higher allocation weights.

[0151] For example, if the current load assessment value of a slave node increases significantly, it indicates that it may be under great pressure. In this case, its business request allocation weight should be reduced accordingly to reduce the inflow of new requests. Conversely, if the current load assessment value of another slave node is low, its allocation weight should be increased so that it can handle more requests, thereby achieving reasonable utilization of resources.

[0152] Through the above mechanism, the weight of business requests allocated to each slave node can reflect its latest service capabilities in real time, ensuring that requests are always directed to slave nodes with the current load processing capacity.

[0153] Optionally, to avoid drastic fluctuations in the request distribution strategy caused by sudden changes in allocation weights, a gradual adjustment mechanism is adopted when updating the allocation weights of business requests. One possible implementation is to calculate the new allocation weight, but not immediately replace the currently used weight. Instead, the difference between the new weight and the currently used weight is calculated, and this difference is gradually added to the current weight according to a preset ratio (e.g., 10% or 20% each time) to form the weight value that actually takes effect in this round.

[0154] In this way, weight updates are broken down into multiple small, gradual adjustment steps. For example, if the new weight is significantly higher than the current weight, a large number of requests will not be switched to that slave node all at once. Instead, its allocation ratio will be increased in small increments multiple times, giving the node a buffer time to adapt to the increased load. Conversely, if the new weight is significantly lower, request traffic will gradually decrease, avoiding sudden unloading that could lead to resource waste or service instability. While maintaining sensitivity to load changes, this effectively suppresses request allocation fluctuations caused by sudden weight changes.

[0155] In some embodiments, to ensure the stability and reliability of the database service, an active isolation mechanism is implemented for abnormal slave nodes. Specifically, when a slave node meets any of the following conditions, its business request allocation rights are immediately reset to zero:

[0156] If the current load assessment value of a node exceeds the preset overload threshold, it indicates that the node is in a performance bottleneck or is on the verge of becoming unavailable.

[0157] If the load information of the slave node is not successfully collected multiple times (e.g., three or five times), it indicates that the node may have crashed, experienced a network outage, or timed out.

[0158] Once the weight is set to zero, all newly arriving requests will no longer be distributed to that slave node, thus avoiding further pressure on the faulty or overloaded node and preventing the spread of errors or deterioration of user experience. Once the slave node subsequently recovers (e.g., successfully re-reports load data and the load assessment value is below the overload threshold), it will no longer maintain a zero weight. Instead, it will gradually recover to the target weight dynamically calculated based on the current load, starting from its preset initial request allocation weight, in fixed steps, to achieve a safe and smooth service recovery.

[0159] S210. Distribute the pending requests to each slave node according to the updated business request weight allocation.

[0160] Understandably, pending requests are distributed to each slave node according to the updated business request weight allocation. Pending requests refer to operations initiated by the application that require retrieving data from the database, such as querying user information or retrieving product details.

[0161] One possible implementation is to assign a higher weight to the slave node, indicating that the slave node has stronger idle processing capabilities in the current state, and therefore a greater probability of being selected; conversely, a lower weight results in a lower probability of being selected. Each time a new request is received, a real-time decision is made based on the latest weight, ensuring that the request is always directed to the most suitable slave node for processing.

[0162] The pending requests are distributed to each slave node according to the updated business request allocation weights. The request allocation can dynamically adapt to the actual load status of each slave node, avoiding some nodes being overloaded while others are idle, realizing adaptive load balancing of database slave nodes, and improving database response stability and resource utilization.

[0163] In some embodiments, if there are pending requests that have entered the slave node allocation queue, the requests that have entered the node allocation queue are distributed to each slave node according to the business request allocation weight before the update; if the distribution of requests that have entered the slave node allocation queue has ended, the pending requests are distributed to each slave node according to the updated business request allocation weight.

[0164] To avoid confusion in the processing of queued requests due to sudden changes in weight, a phased execution strategy is adopted for request distribution.

[0165] Specifically, if some pending requests have already been pre-placed in the slave node allocation queue (i.e., requests have entered the scheduling buffer but have not yet been actually forwarded to the slave node) when the business request allocation weight is updated, then the aforementioned queued requests will still be distributed according to the business request allocation weight before the update. This processing method ensures the consistency of the allocation logic for queued requests, preventing the same batch of requests from being unevenly distributed to nodes with different performance states due to weight switching, thereby ensuring the stability of the service.

[0166] Meanwhile, newly arrived pending requests (i.e. requests that enter the system after the weight update) do not participate in the current queue allocation. Instead, they wait for all the previously queued requests to be distributed before making routing decisions based on the updated business request weight allocation.

[0167] Through the above mechanism, while realizing dynamic adjustment based on load awareness, the continuity of request processing and the stability of allocation strategy are taken into account, avoiding the aggravation of node load fluctuations caused by frequent weight updates.

[0168] Figure 4 A schematic diagram of the structure of the device for adjusting database load provided in this application is shown below. Figure 4 As shown, the apparatus 300 for adjusting database load provided in this embodiment includes:

[0169] The determination module 301 is used to determine the current load information of each slave node in the database; the load information is used to indicate the running status of the slave nodes.

[0170] Processing module 302 is used to update the service request allocation weight of each slave node based on the current load information and historical load information;

[0171] The processing module 302 is also used to distribute the requests to be processed to each slave node based on the updated business request weight.

[0172] In one possible implementation, the device further includes: an acquisition module 303;

[0173] The acquisition module 303 is used to acquire the current CPU utilization, memory usage, query response time, and connection pool utilization of each slave node in the database.

[0174] The processing module 302 is also used to normalize the CPU utilization, memory usage, query response time and connection pool utilization to obtain the corresponding standard values.

[0175] The processing module 302 is also used to perform weighted summation of the standard values ​​according to preset weights to obtain the current load information of each slave node.

[0176] In one possible implementation, the device further includes: a computing module 304;

[0177] The calculation module 304 is used to calculate the fluctuation coefficient of the current load information compared with the historical load information;

[0178] The determination module 301 is also used to determine the adjustment parameter for the weight allocation of business requests based on the fluctuation coefficient. The adjustment parameter indicates the proportion of the current load information when updating the weight allocation of business requests.

[0179] The processing module 302 is also used to update the weight of the business request allocation for each slave node according to the adjustment parameters.

[0180] In one possible implementation, the determining module 301 is further configured to determine the adjustment parameter as a first value range when the fluctuation coefficient is greater than a first preset threshold.

[0181] The determining module 301 is also used to determine the adjustment parameter as a second value range when the fluctuation coefficient is less than the second preset threshold.

[0182] The determination module 301 is also used to determine the adjustment parameters based on the fluctuation coefficient and the range of adjustment parameter values.

[0183] In one possible implementation, the determining module 301 is further configured to determine a first weight value of the current load information and a second weight value of the historical load average value based on the adjustment parameters.

[0184] The processing module 302 is also used to perform a weighted summation of the current load information and the historical load average based on the first weight value and the second weight value to obtain the current load evaluation value of each slave node;

[0185] The processing module 302 is also used to update the service request allocation weight of each slave node according to the current load assessment value of each slave node.

[0186] In one possible implementation, the processing module 302 is further configured to distribute the requests to be processed to each slave node according to the updated business request allocation weight;

[0187] The processing module 302 is also used to distribute the requests that have entered the node allocation queue to each slave node according to the business request allocation weight before the update when there are pending requests that have entered the slave node allocation queue.

[0188] The processing module 302 is also used to distribute the pending requests to each slave node according to the updated business request allocation weight after the request distribution that has entered the slave node allocation queue has ended.

[0189] In one possible implementation, the determining module 301 is further configured to determine the range of values ​​for the adjustment parameter by linear interpolation when the fluctuation coefficient is between a first preset threshold and a second preset threshold.

[0190] The device for adjusting database load provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0191] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 400 provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the device 400 further includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0192] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above-described method.

[0193] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0194] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0195] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0196] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0197] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0198] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0199] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0200] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0201] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0202] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0203] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0204] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0205] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0206] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and 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 the invention is limited only by the appended claims.

Claims

1. A method for adjusting database load, characterized in that, include: Determine the current load information of each slave node in the database; The load information is used to indicate the operating status of the slave node; Based on the current load information and historical load information, update the service request allocation weights of each slave node; Based on the updated service request allocation weights, the requests to be processed are distributed to each slave node.

2. The method according to claim 1, characterized in that, The load information includes: CPU utilization, memory usage, query response time, and connection pool utilization; determining the current load information of each slave node in the database includes: Obtain the current CPU utilization, memory usage, query response time, and connection pool utilization of each slave node in the database, and normalize them to obtain the corresponding standard values. The standard values ​​are weighted and summed according to preset weights to obtain the current load information of each slave node.

3. The method according to claim 1, characterized in that, The step of updating the service request allocation weight of each slave node based on the current load information and historical load information includes: Calculate the fluctuation coefficient of the current load information compared to the historical load information; Based on the fluctuation coefficient, an adjustment parameter for the allocation weight of the service request is determined, wherein the adjustment parameter indicates the proportion of the current load information when updating the allocation weight of the service request; Based on the adjustment parameters, update the service request allocation weights for each slave node.

4. The method according to claim 3, characterized in that, The step of determining the adjustment parameter for allocating the weight of the service request based on the fluctuation coefficient includes: If the fluctuation coefficient is greater than the first preset threshold, then the adjustment parameter is determined to be within the first value range; If the fluctuation coefficient is less than the second preset threshold, then the adjustment parameter is determined to be within the second value range; The adjustment parameter is determined based on the fluctuation coefficient and the range of values ​​for the adjustment parameter.

5. The method according to claim 4, characterized in that, The step of updating the service request allocation weight of each slave node according to the adjustment parameters includes: Based on the adjustment parameters, determine the first weight value of the current load information and the second weight value of the historical load average. The current load information and the historical average load are weighted and summed based on the first weight value and the second weight value to obtain the current load assessment value of each slave node; Update the service request allocation weights of each slave node based on the current load assessment value of each slave node.

6. The method according to claim 5, characterized in that, The step of allocating weights to the pending requests based on the updated service requests and distributing them to each slave node includes: Distribute the pending requests to each slave node according to the updated business request weight allocation; or, If there are pending requests that have entered the slave node allocation queue, then the requests that have entered the node allocation queue will be distributed to each slave node according to the business request allocation weight before the update. Once the distribution of requests that have entered the slave node allocation queue has ended, the requests to be processed are distributed to each slave node according to the updated business request allocation weight.

7. The method according to claim 4, characterized in that, The method further includes: If the fluctuation coefficient is between the first preset threshold and the second preset threshold, the range of the adjustment parameter is determined by linear interpolation.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images