Network request processing method, apparatus, device, and storage medium

Abstract

The application discloses a network request processing method and device, equipment and a storage medium, relates to the technical field of resource configuration, and is applied to a preset load balancing tool, and comprises the following steps: collecting current load states and hardware parameters of each server node, and inputting the current load states and the hardware parameters into a preset multi-layer perception machine model to obtain corresponding load balancing weights; acquiring historical network request logs of the load balancing tool, and determining a network traffic change trend of a server cluster according to the historical network request logs by using a preset network traffic prediction model; the preset network traffic prediction model is constructed based on an autoregressive difference moving average model and a long short-term memory network; receiving a network request of a client, and distributing the network request to each server node for processing according to the load balancing weights and the network traffic change trend. According to the current states of each server node and the predicted network traffic change trend, the network request of the client can be distributed to each server node, and the utilization rate of server resources is effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of resource configuration, and particularly relates to a network request processing method and device, equipment and a storage medium. BACKGROUND

[0002] With the rapid development of the Internet, more and more users begin to use Internet applications, and a large amount of network traffic brings huge load pressure to servers. For this reason, cluster technology in which multiple servers are combined together emerges as the times require. The most important problem in server cluster technology is how to reasonably and effectively allocate request tasks according to the performance of server nodes when facing high concurrency requests, so as to avoid overload of part of the servers and fully utilize all server resources. The technology for solving the above problem is load balancing technology. The goal of the technology is to reasonably distribute network traffic to multiple service nodes to balance the load pressure of each server, and fully utilize server resources on the premise of ensuring that the server can normally process business and quickly respond.

[0003] However, the existing load balancing strategies all have problems to varying degrees. For example, static load balancing fixedly distributes traffic according to pre-set rules, ignores the uncertainty of real-time performance of server nodes, and cannot reasonably and timely adjust when the available performance of server nodes differs too much, which easily leads to server overload and low server resource utilization. Dynamic load balancing considers the uncertainty of real-time performance of server nodes, periodically acquires one or more indicators representing the running state of server nodes through complex technology, then evaluates the load pressure of server nodes according to the indicators, further calculates traffic distribution weights and dynamically adjusts. However, since the hardware performance of each server in the server cluster itself may have large differences, and the weights of these state indicators and the weights of server nodes are obtained through human decision, the calculated load pressure cannot completely represent the real pressure state of the server, the traffic distribution is not reasonable, and the entire service system may run inefficiently or abnormally congested. Moreover, the existing algorithms do not consider whether the overall performance of the server cluster is comparable to high concurrency network traffic, that is, they cannot predictively and actively scale resources in the server cluster in time periods when traffic suddenly changes, and cannot improve the resource utilization of servers as much as possible on the premise of ensuring that services can be normally provided. Therefore, how to more evenly and reasonably distribute network traffic to all service nodes to achieve load balancing of servers is a problem to be solved in the field. SUMMARY

[0004] In view of this, the purpose of this invention is to provide a network request processing method, apparatus, device, and storage medium that can rationally distribute client network requests to each server node based on the current status of each server node and the predicted network traffic change trend, effectively improving the resource utilization of the server. The specific solution is as follows:

[0005] Firstly, this application provides a network request processing method applied to a preset load balancing tool, comprising:

[0006] Collect the current load status and hardware parameters of each server node in the preset server cluster, and input the current load status and hardware parameters into the preset multilayer perceptron model to obtain the load balancing weight of each server node;

[0007] The historical network request logs of the load balancing tool are obtained, and the network traffic change trend of the server cluster is determined based on the historical network request logs using a preset network traffic prediction model; the preset network traffic prediction model is a model constructed based on an autoregressive differential moving average model and a long short-term memory network.

[0008] The system receives network requests sent by the client and distributes the network requests to each of the server nodes in the preset server cluster according to the load balancing weight and the network traffic change trend, so that each server node can process the corresponding network request received.

[0009] Optionally, the collection of the current load status and hardware parameters of each server node in the preset server cluster includes:

[0010] The current load status and hardware parameters of each server node in the preset server cluster are collected based on a preset data collection time interval.

[0011] Accordingly, the step of inputting the current load state and the hardware parameters into a preset multilayer perceptron model to obtain the load balancing weights corresponding to each server node includes:

[0012] Based on the preset data collection time interval, the current load status and the hardware parameters are input into the preset multilayer perceptron model to obtain the target load balancing weight of each server node, and the current load balancing weight of each server node is updated based on the target load balancing weight.

[0013] Optionally, the step of inputting the current load state and the hardware parameters into a preset multilayer perceptron model to obtain the load balancing weights corresponding to each server node includes:

[0014] The current load status and the hardware parameters are input into the preset multilayer perceptron model, and feature vectors corresponding to each server node are constructed based on the current load status and the hardware parameters.

[0015] Using the first hidden layer of the preset multilayer perceptron model, the first load information of the feature vector is extracted based on the corresponding first preset neuron weights, first preset bias and first preset activation function;

[0016] Using the second hidden layer of the preset multilayer perceptron model, the second load information of the feature vector is extracted based on the first load information, according to the corresponding second preset neuron weights, second preset bias, and second preset activation function; the second load information is the load balancing weight corresponding to each server node.

[0017] Optionally, obtaining historical network request logs from the load balancing tool and determining the network traffic change trend of the server cluster based on the historical network request logs using a preset network traffic prediction model includes:

[0018] Obtain the historical network request logs of the load balancing tool, and determine the timestamp information and server node call information corresponding to each historical network request in the historical network request logs;

[0019] Based on the timestamp information and the server node call information, determine the historical network requests corresponding to each server node within the preset time interval;

[0020] Based on the timestamp information, the historical network requests of each server node within the preset time interval are statistically analyzed and sorted, and network traffic time series data corresponding to the historical network requests within the preset time interval are generated based on the sorting results.

[0021] The network traffic change trend of the client is determined by the preset network traffic prediction model based on the network traffic time series data.

[0022] Optionally, determining the network traffic change trend of the server cluster based on the network traffic time series data using the preset network traffic prediction model includes:

[0023] The network traffic time series data is input into the autoregressive differential moving average model of the preset network traffic prediction model to obtain the first traffic prediction data;

[0024] The first traffic prediction data and the network traffic time series data are differentially analyzed to obtain historical residual data.

[0025] The historical residual data is input into the long short-term memory network of the preset network traffic prediction model to obtain the second traffic prediction data;

[0026] The network traffic prediction results of the server cluster are generated based on the first traffic prediction data and the second traffic prediction data, and the corresponding network traffic change trend is determined based on the network traffic prediction results.

[0027] Optionally, distributing the network request to each server node in the preset server cluster according to the load balancing weight and the network traffic change trend includes:

[0028] Based on the network traffic change trend, determine whether the preset server cluster is at risk of traffic overload;

[0029] If there is a risk of traffic overload, a scheduled task is added to scale the resources of the preset server cluster to dynamically adjust the number of server nodes in the preset server cluster to cope with high concurrency traffic.

[0030] When a client request is received, the network request is distributed to each of the server nodes in the preset server cluster according to all available server nodes in the preset server cluster and their corresponding latest load balancing weights.

[0031] Optionally, adding a scheduled task to scale the resources of the preset server cluster to dynamically adjust the number of server nodes in the preset server cluster to cope with high concurrency traffic includes:

[0032] Determine the target time period corresponding to the traffic overload risk, and determine the start and end times of the traffic overload risk based on the target time period;

[0033] When the current time is the start time, the server status of the preset backup server is adjusted to the available state, and the process jumps to the step of collecting the current load status and hardware parameters of each server node in the preset server cluster, so as to update the target load balancing weight of the preset backup server.

[0034] When the current time is the end time, the preset backup server is removed from the preset server cluster.

[0035] Secondly, this application provides a network request processing apparatus applied to a preset load balancing tool, comprising:

[0036] The weight determination module is used to collect the current load status and hardware parameters of each server node in the preset server cluster, and input the current load status and hardware parameters into the preset multilayer perceptron model to obtain the load balancing weight of each server node.

[0037] The trend determination module is used to obtain historical network request logs from the load balancing tool and determine the network traffic change trend of the server cluster based on the historical network request logs using a preset network traffic prediction model; the preset network traffic prediction model is a model constructed based on an autoregressive differential moving average model and a long short-term memory network.

[0038] The request distribution module is used to receive network requests sent by the client and distribute the network requests to each of the server nodes in the preset server cluster according to the load balancing weight and the network traffic change trend, so that each server node can process the corresponding network request received.

[0039] Thirdly, this application provides an electronic device, which includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the aforementioned network request processing method.

[0040] Fourthly, this application provides a computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the aforementioned network request processing method.

[0041] This application first collects the current load status and hardware parameters of each server node in a preset server cluster. The current load status and hardware parameters are then input into a preset multilayer perceptron model to obtain the load balancing weight for each server node. Next, historical network request logs from the load balancing tool are obtained. A preset network traffic prediction model, constructed based on an autoregressive differential moving average model and a long short-term memory network, is used to determine the network traffic change trend of the server cluster based on the historical network request logs. Finally, network requests sent by clients are distributed to each server node in the preset server cluster according to the load balancing weight and the network traffic change trend, so that each server node can process the received network requests. In this way, this application determines the corresponding load balancing weight based on the current load status and hardware parameters of the server, taking into account the possible impact of differences in hardware performance among the servers in the server cluster on the actual load status of the server. Furthermore, it uses a multilayer perceptron neural network model to evaluate the load status of server nodes, avoiding the bias caused by subjective human decision-making. Then, it predicts future network traffic trends by using an autoregressive differential moving average model and a long short-term memory network, making the scaling time of resources in the server cluster predictable. This can effectively avoid business system interruptions and paralysis caused by sudden traffic, while improving the utilization rate of server resources. It can more reasonably evaluate the load status of the server, thereby dynamically and effectively distributing network traffic based on the real-time performance of all backend servers. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0043] Figure 1 A flowchart of a network request processing method provided in this application;

[0044] Figure 2 An architecture diagram of a network request processing method provided in this application;

[0045] Figure 3 A multilayer perceptron network structure diagram is provided in this application;

[0046] Figure 4 A flowchart of a specific network request processing method provided in this application;

[0047] Figure 5 A schematic diagram of a traffic prediction framework provided in this application;

[0048] Figure 6 A long short-term memory network framework diagram is provided for this application;

[0049] Figure 7 A flowchart of a load balancing scheduling method provided in this application;

[0050] Figure 8 A schematic diagram of a network request processing device provided in this application;

[0051] Figure 9 This application provides a structural diagram of an electronic device. Detailed Implementation

[0052] 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, and 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.

[0053] While existing load balancing strategies can periodically acquire the operating status of server nodes to calculate and dynamically adjust the traffic distribution weights corresponding to each server, the resulting load pressure cannot fully represent the actual load status of the servers due to differences in server hardware performance and errors in human decision-making. This application takes into account the potential impact of differences in hardware performance among servers in the server cluster on the actual load status of the servers, and uses a multilayer perceptron neural network model to evaluate the load status of server nodes, avoiding the bias caused by subjective human decision-making and providing a more reasonable evaluation of the server load status.

[0054] See Figure 1 As shown, this embodiment of the invention discloses a network request processing method applied to a preset load balancing tool, including:

[0055] Step S11: Collect the current load status and hardware parameters of each server node in the preset server cluster, and input the current load status and hardware parameters into the preset multilayer perceptron model to obtain the load balancing weight of each server node.

[0056] In this embodiment, the current load status and hardware parameters of each server node in a preset server cluster are first collected. These data are then input into a preset Multilayer Perceptron (MLP) model to obtain the load balancing weights for each server node. Specifically, when collecting load metrics and hardware parameters from each node in the backend server cluster, since it's necessary to collect load metric information from each node for analyzing its load status, Golang can be chosen as the development language to develop a node load metric collection service program, which is then deployed on each server node. Following this... Figure 2 As shown, load balancing software can obtain real-time CPU (Central Processing Unit) utilization, memory utilization, disk utilization, network bandwidth utilization, and server connection count from the service program via HTTP (Hypertext Transfer Protocol) requests, as well as the inherent hardware information of each server node, including but not limited to CPU clock speed. Core number Number of threads and power consumption Memory frequency Number of channels Memory type and memory bandwidth Disk caching and random read / write speed The calculation process for each load indicator is as follows:

[0057] CPU utilization: ;

[0058] in Indicates CPU utilization. The percentage of idle CPU can be obtained using the Linux command `top -bn1 | grep "Cpu(s)" | awk '{print $8}'`.

[0059] Memory usage: ;

[0060] in This indicates memory usage. "used" and "total" are the amount of memory used and the total amount of memory obtained using the Linux command `free -m | awk ' / Mem: / {print $3, $2}'`.

[0061] Disk usage: ;

[0062] in This is the disk utilization obtained using the Linux command `iostat -dx 1 2 | awk ' / sda / {print $23}'`.

[0063] Network bandwidth utilization: ;

[0064] in Indicates network bandwidth utilization. and Each represents a short period of time. Total number of bytes sent and received on the internal network This indicates the bandwidth of the server node.

[0065] Server connection count: ;

[0066] in Indicates the number of server connections. This indicates the number of connections to the current node obtained by checking the ip_conntrack_count kernel parameter. This indicates the maximum number of connections for the current node, obtained by checking the ip_conntrack_max kernel parameter.

[0067] After obtaining the aforementioned load metrics and hardware parameters, the current load status and hardware parameters are input into a preset multilayer perceptron model to obtain the load balancing weights corresponding to each server node. Specifically, the current load status and hardware parameters can be input into the preset multilayer perceptron model, and feature vectors corresponding to each server node can be constructed based on the current load status and hardware parameters. Then, using the first hidden layer of the preset multilayer perceptron model, the first load information of the feature vector is extracted based on the corresponding first preset neuron weights, first preset bias, and first preset activation function. Similarly, using the second hidden layer of the preset multilayer perceptron model, the second load information of the feature vector is extracted based on the first load information using the corresponding second preset neuron weights, second preset bias, and second preset activation function. The second load information is the load balancing weight corresponding to each server node. In this embodiment, the collected server node load metrics and the inherent hardware parameters of the server can be input into a trained MLP model to calculate the distribution weights of each server node. MLP (Multi-Layered Painless LP) is a feedforward artificial neural network consisting of an input layer, hidden layers, and an output layer. Neurons are connected layer by layer without loops. MLP transmits and transforms information layer by layer through linear transformations and non-linear activation functions, enabling complex function mappings. The input layer receives features from external input, the hidden layers contain one or more neurons to extract features from the data, and the output layer outputs the final result. Furthermore, since estimating the distribution weights of server nodes based on their load metrics and hardware parameters is a regression problem, the MLP model used in this embodiment is as follows... Figure 3 As shown, the model has 15 input nodes and one output node. Furthermore, the MLP model in this embodiment employs two hidden layers. The first hidden layer has 32 neurons to extract shallow load information from the load metrics, and the second hidden layer has 16 neurons to extract deeper load information. Thus, in the trained model, using the various load metrics and hardware parameters of the server node as input, the output after passing through the neurons in the two hidden layers is the distribution weight of that server node.

[0068] It should be noted that in this embodiment, a Self-Attention layer can be added between the feature input of the MLP model and the first hidden layer. This allows the model to automatically learn the differences in the contribution of different load features, such as processor utilization, memory bandwidth, and disk read / write speed, to the server load status. This addresses the limitation of traditional MLPs in treating all input features equally by dynamically allocating feature weights, making it particularly suitable for scenarios with large differences in server hardware parameters and strong coupling of load features. Through the attention mechanism, the model can automatically strengthen the influence of key features and weaken the interference of irrelevant features, making the output load balancing weights more closely match the actual server load status and improving computational accuracy. Furthermore, the output layer can be extended to achieve multi-step traffic prediction for N future time points, providing sufficient decision-making buffer time for server elastic scaling. For example, the output label of each sample in the historical network traffic time series data can be set to the traffic value for N future time points, and the number of neurons in the output layer of the original LSTM network can be adjusted to N. During training, the mean squared error loss function can be used to optimize the model's fitting ability to multi-step outputs. In this way, the model can first output linear trend predictions for the next N time points, and then perform nonlinear fitting on the N-step residual data to obtain the final traffic prediction results for the next N time points. By outputting the complete trend of traffic changes in advance, hasty decisions caused by predictions at a single time point can be avoided. Furthermore, based on the multi-step traffic prediction results, three levels of traffic thresholds can be set. For example: the warning threshold is set to 70% of the maximum capacity of the server cluster. When the traffic is predicted to exceed the warning threshold within the next N1 minutes, the node warm-up phase is triggered; the expansion threshold is set to 90% of the maximum capacity of the server cluster. When the traffic is predicted to exceed the expansion threshold within the next N2 minutes, the node activation phase is triggered; and the contraction threshold is set to 50% of the maximum capacity of the server cluster. When the traffic is predicted to remain below the contraction threshold within the next N3 minutes, the node release phase is triggered. Specifically, during the node preheating phase, nodes matching the existing node hardware configuration can be selected from a pre-set backup server pool, and basic services can be started, but they are not yet included in cluster traffic distribution to avoid expansion delays. During the node activation phase, the preheated backup nodes can be formally included in the server cluster, their load balancing weights can be calculated in real time, and they can immediately participate in traffic distribution. During the node release phase, redundant backup nodes can be gradually removed from the cluster, basic services can be shut down, and resources can be released to ensure that resource utilization is maintained within a reasonable range. In this way, the preheating mechanism can improve response speed and reduce unnecessary resource overhead and lower resource costs while dealing with sudden traffic surges.

[0069] Specifically, when calculating the real-time weights of each server node using an MLP model, such as Figure 3 As shown, firstly, all load metrics and hardware parameters of the server node are combined to form a feature vector. Then, through forward propagation, the input signal is multiplied by the weights of the neurons in that layer and a bias is added. The output of that layer is then obtained through an activation function. For the ... neurons in the layer Its output The calculation process is as follows:

[0070] ;

[0071] ;

[0072] in From the previous layer of neurons To the current layer neuron The weight, It is the bias value of the current layer neuron. This represents the activation function. In this embodiment, Tanh (hyperbolic tangent function) is used as the activation function, and its formula is shown below:

[0073] ;

[0074] Then, using the feature vector of each server node as input, the distribution weights of all server nodes in the server cluster can be obtained by calculating all hidden layers of the MLP model. ,in Let be the total number of server nodes. Then, all server weights are standardized using min-max normalization, and the final result is used to update all server weights. The formula for min-max normalization is shown below:

[0075] ;

[0076] in For the first The normalized weights of each server node, where min and max represent the functions for finding the minimum and maximum values, respectively. This represents the set of original weights for all server nodes, i.e. .

[0077] In the training process of an MLP model, it can be understood that the training process is a dynamic iterative process. Therefore, after each forward propagation, the error between the output result and the label value can be calculated using a loss function. Then, the weights and biases of the neurons are updated in the direction of the gradients of each parameter through backpropagation, completing one learning cycle. This process continues until the forward propagation error value is within a certain range, at which point the learning objective has been achieved. Furthermore, during this process, the model's performance can be evaluated using a loss function to measure the difference between the predicted and actual values. In a specific embodiment, mean squared error loss can be used as the loss function, and its calculation process is as follows:

[0078] ;

[0079] in This represents the weights of the MLP output. This represents the true label value during training, and in order to update the weights and biases more effectively, this embodiment can use SGD (Stochastic Gradient Descent) as the optimization algorithm.

[0080] In this way, this embodiment can input the collected load indicators of each server node and the inherent hardware parameters of the server into the trained MLP model. The MLP model can more reasonably calculate the distribution weight of each server node, which is used by the intelligent load balancing scheduling method to distribute all high-concurrency requests, thereby maximizing the utilization of server resources while ensuring service quality.

[0081] And as Figure 2 As shown, in this embodiment, the current load status and hardware parameters of each server node in a preset server cluster can be collected based on a preset data collection time interval. Then, based on the preset data collection time interval, the current load status and hardware parameters are input into a preset multilayer perceptron model to obtain the target load balancing weight of each server node, and the current load balancing weight of each server node is updated based on the target load balancing weight. In other words, the intelligent load balancing scheduling method in this embodiment can periodically obtain the load indicators and hardware parameters of all backend server nodes through HTTP requests, and then calculate and update the distribution weight of all nodes through the MLP model. When high-concurrency requests from clients arrive at the load balancing software, the intelligent load balancing scheduling method will reasonably distribute the requests according to the latest weight of all server nodes, so that server nodes under high load pressure are distributed to fewer requests, while nodes under low load can handle more requests, thereby maximizing the utilization of server resources while ensuring service quality.

[0082] Step S12: Obtain the historical network request logs of the load balancing tool, and determine the network traffic change trend of the server cluster based on the historical network request logs using a preset network traffic prediction model; the preset network traffic prediction model is a model constructed based on an autoregressive differential moving average model and a long short-term memory network.

[0083] In this embodiment, as Figure 2 As shown, historical network request logs can be obtained through load balancing software, and the network traffic trend of the server cluster can be determined based on these logs using a preset network traffic prediction model. It should be noted that the preset network traffic prediction model is based on an Autoregressive Integrated Moving Average (ARIMA) model and a Long Short-Term Memory (LSTM) network.

[0084] Step S13: Receive the network request sent by the client, and distribute the network request to each of the server nodes in the preset server cluster according to the load balancing weight and the network traffic change trend, so that each server node can process the corresponding network request received.

[0085] In this embodiment, as Figure 2 As shown, after receiving a network request from a client, the load balancing software can distribute the network request to each server node in the preset server cluster according to the load balancing weight and network traffic change trend, so that each server node can process the corresponding network request received.

[0086] In this embodiment, the current load status and hardware parameters of each server node in a preset server cluster are collected. These data are then input into a preset multilayer perceptron model to obtain the load balancing weight for each server node. Historical network request logs from the load balancing tool are then acquired. A preset network traffic prediction model, constructed based on an autoregressive differential moving average model and a long short-term memory network, is used to determine the network traffic trend of the server cluster based on these historical logs. Upon receiving network requests from clients, the network requests are distributed to each server node in the preset server cluster according to the load balancing weights and network traffic trends, allowing each server node to process the received requests. Through this technical solution, this embodiment can determine the corresponding load balancing weight based on the current load status and hardware parameters of the servers. It considers the potential impact of hardware performance differences among servers in the cluster on the actual server load status and uses a multilayer perceptron neural network model to evaluate the load status of server nodes, avoiding bias caused by subjective human decision-making. This allows for dynamic, reasonable, and effective distribution of network traffic based on the real-time performance of all backend servers. Then, by using an autoregressive differential moving average model and a long short-term memory network to predict future network traffic trends, the scaling time of resources in the server cluster becomes predictable. This effectively avoids business system interruptions and paralysis caused by sudden traffic surges, while improving the utilization rate of server resources. It also allows for a more reasonable evaluation of server load status, thereby dynamically and effectively distributing network traffic based on the real-time performance of all backend servers.

[0087] As described in the previous embodiment, this application can collect hardware and load status information of each server and use a multilayer perceptron neural network model to evaluate the load status of server nodes, thereby achieving server load balancing. Next, this embodiment will elaborate on the process of distributing network requests based on future network traffic trends. See also... Figure 4 As shown in the figure, this application discloses a specific network request processing method applied to a preset load balancing tool, including:

[0088] Step S21: Collect the current load status and hardware parameters of each server node in the preset server cluster, and input the current load status and hardware parameters into the preset multilayer perceptron model to obtain the load balancing weight of each server node.

[0089] Step S22: Obtain the historical network request logs of the load balancing tool, and determine the network traffic change trend of the server cluster based on the historical network request logs using a preset network traffic prediction model; the preset network traffic prediction model is a model constructed based on an autoregressive differential moving average model and a long short-term memory network.

[0090] In this embodiment, the name of the requested backend server group can be added to each access record of the load balancing software. Then, all request records requesting the same backend server group in the log are counted by minute to obtain the number of requests per unit time (minute). These requests are then sorted according to timestamps (accurate to the minute) to obtain network traffic time series data for a specific backend server group. This data can then be used for network traffic prediction. In other words, in this embodiment, when determining the network traffic change trend of the server cluster based on historical network request logs using a preset network traffic prediction model, the historical network request logs of the load balancing tool are first obtained. The timestamp information and server node call information corresponding to each historical network request in the historical network request logs are determined. Then, based on the timestamp information and server node call information, the historical network requests corresponding to each server node within a preset time interval are determined. The historical network requests of each server node within the preset time interval are then counted and sorted according to the timestamp information. Based on the sorting results, network traffic time series data corresponding to the historical network requests within the preset time interval is generated. Finally, the future network traffic change trend of the server cluster is determined based on the historical network traffic time series data using a preset network traffic prediction model. In one specific embodiment, the load balancing software records all request records. Each request record has a timestamp. In this embodiment, the name of the requested backend server group is added to each access record. Then, all request records in the log that request the same backend server group are counted by minute to obtain the number of requests per unit time (minute). The data is then sorted according to the timestamp (accurate to the minute) to obtain the network traffic time series data of a certain backend server group.

[0091] Accordingly, in this embodiment, network traffic time series data can be input into the autoregressive differencing moving average model of a preset network traffic prediction model to obtain first traffic prediction data. Then, the first traffic prediction data and the network traffic time series data are differencing to obtain historical residual data. This historical residual data is then input into the long short-term memory network of the preset network traffic prediction model to obtain second traffic prediction data. Based on the first and second traffic prediction data, a network traffic prediction result for the server cluster is generated, and the corresponding network traffic change trend is determined based on the network traffic prediction result. It is understood that network traffic exhibits characteristics such as abrupt changes, weak coupling, and nonlinearity under the influence of many intrinsic factors. Therefore, in order to accurately analyze the linear and nonlinear factors in network traffic and improve the accuracy of network traffic prediction, this embodiment can combine the linear model ARIMA and the nonlinear model LSTM to predict network traffic. Specifically, as shown... Figure 5As shown, this embodiment can predict the overall traffic trend for a future time period based on historical traffic data of the application using ARIMA and LSTM models, which can guide the dynamic scaling of server cluster resources. First, based on ARIMA's strong processing capabilities for time-series data, it can extract linear features while retaining the original information of historical data. Therefore, historical network traffic data is used as input to the ARIMA model to predict future network traffic trends. Then, the network traffic residuals predicted by the ARIMA model are used as input to the LSTM network, leveraging LSTM's nonlinear fusion and global optimization capabilities to fully capture nonlinear factors in the residual data. Finally, the ARIMA model prediction result is added to the LSTM residual prediction result to obtain the final network traffic prediction value. In this way, the traffic prediction scheme combining ARIMA and LSTM improves the accuracy of network traffic prediction from both linear and nonlinear perspectives.

[0092] In one specific embodiment, the linear characteristics of network traffic can first be extracted using the ARIMA model. Specifically, in this embodiment, the ARIMA model consists of three parts: "AR", "I", and "MA", where "AR" represents autoregression, "I" represents difference, and "MA" represents moving average. Based on the ARIMA model, the time series patterns hidden behind the data can be extracted through the autocorrelation and differencing of the data, and then these patterns can be used to predict future data. The AR part is used to process the autoregressive part of the time series, which can consider the influence of observations from several past periods on the current value, and is usually expressed as... ,in It represents the order of the autoregression. The observed values ​​at the current time point t. Can be passed before It can be represented by a linear combination of time values, as shown in the following formula:

[0093] ;

[0094] in It is a constant term. It is the autoregressive coefficient. yes White noise at any given moment.

[0095] Part I is used to transform a non-stationary series into a stationary series. This is done by differentiating the time series one or more times, stabilizing it around a fixed average value. This is typically represented as... ,in This is the difference order. After... Time series of order differences It can be represented as:

[0096] ;

[0097] in Represents the lag operator, i.e. .

[0098] The MA part represents the relationship between the current value and the weighted average of the previous residuals, that is, a weighted average of the noise terms over a certain number of past time points, usually expressed as: ,in It is the order of the moving average. Current time point. Observations Depends on the previous The linear combination of the white noise terms at each time step is shown below:

[0099] ;

[0100] in The mean, It is the moving average coefficient. yes White noise prior to the time step.

[0101] Therefore, the ARIMA model can be expressed as: The formula is as follows:

[0102] ;

[0103] The meanings of p and q are exactly the same as in the original AR and MA models, and p and q can be set to different values, while d is the order of differencing required in the ARIMA model. It should be noted that the mean, representing the long-term trend, is used in the MA model. These constants do not exist in the formula of the ARIMA model because the function of "predicting long-term trends" in the ARIMA model is performed by the AR model itself; therefore, the constants in the AR model are not included. Replaced the original In the ARIMA model, It can be 0.

[0104] Thus, the main steps of using the ARIMA model in this embodiment are as follows: First, by plotting or using methods such as ADF (Augmented Dickey-Fuller Test), the minimum value of d that makes the time series data stationary is determined. Then, the ACF (Autocorrelation Function) and PACF (Partial Autocorrelation Function) are calculated respectively to estimate the sequence parameters p and q. Next, the most suitable parameters p and q of the model are determined by AIC (Akaike Information Criterion). Finally, the historical time series data is input into the ARIMA model to obtain all network traffic prediction results from the historical start time point to the future end time point.

[0105] Next, the prediction residuals can be calculated using the LSTM model, and then summed with the prediction output of the ARIMA model to obtain the final prediction value. It's understandable that LSTM is a special type of recurrent neural network (RNN) used to process and learn long-term dependencies in long sequence data. An LSTM unit consists of three gates (gating mechanism) and a cell state. The three gates are: the input gate, the forget gate, and the output gate. And as... Figure 6 As shown, an LSTM network can be composed of one or more LSTM cells connected sequentially.

[0106] In one specific embodiment, a forgetting gate can be used to control the degree of information forgetting between the current and previous time steps, based on the input at the current time step. and the hidden state of the previous moment They jointly decide how much information to discard from the hidden state of the previous time step. The computation process of the forget gate can be represented as:

[0107] ;

[0108] in It is the output of the forget gate. This represents the sigmoid function. and These represent the weights and biases of the neurons in the forgetting layer, respectively. The output of the forgetting gate is a vector with values ​​between [0, 1], representing the degree of forgetting of the information, where 0 indicates complete forgetting and 1 indicates complete retention.

[0109] The input gate controls the degree of updating of the input information at the current moment. A candidate cell state can first be calculated. and the output value of the input gate This process can be represented as:

[0110] ;

[0111] ;

[0112] in and These represent the weights and biases of the input layer neurons, respectively. and represents the weights and biases of neurons in the cell layer, respectively, and tanh represents the hyperbolic tangent function.

[0113] Then update the cell state at the current moment. :

[0114] ;

[0115] in, This indicates the cell state at the previous moment.

[0116] The output gate determines the current hidden state. This is crucial output information for the current time step. The current cell state can be used to update the hidden state at the current time step, and this information will be passed to the LSTM unit at the next time step. The process is as follows:

[0117] ;

[0118] ;

[0119] in, and These represent the weights and biases of the output layer neurons, respectively. This indicates the output value of the output gate.

[0120] Based on the above technical solution, this embodiment constructs an LSTM network consisting of two LSTM units. The hidden layer size in each LSTM unit is 32. A fully connected layer is added after the output of the last LSTM unit to output the prediction result. The time window size during training and testing is 720, meaning that traffic data from the past 12 hours is used to predict network traffic for the next minute. During training, a dropout rate of 0.2 is used to avoid overfitting, the learning rate is 0.001, and the Adam optimizer is used to optimize the network. In this way, after obtaining all network traffic prediction results from the historical start time to the future end time through the ARIMA model, the actual historical data can be differiated with the historical data predicted by ARIMA to obtain historical residual data. This historical residual data is then used as input to the LSTM network to obtain the residual prediction result for future network traffic. Finally, the prediction result output by the ARIMA model is added to the residual prediction result of the LSTM network to obtain the final network traffic prediction result.

[0121] Step S23: Receive the network request sent by the client, and distribute the network request to each of the server nodes in the preset server cluster according to the load balancing weight and the network traffic change trend, so that each server node can process the corresponding network request received.

[0122] This embodiment can determine whether there is a risk of traffic overload in the preset server cluster based on network traffic change trends. If there is a risk of traffic overload, a timed task is added to scale the resources of the preset server cluster to dynamically adjust the number of server nodes in the preset server cluster to cope with high concurrency traffic. Specifically, the target time period corresponding to the traffic overload risk can be determined first, and the start and end times of the traffic overload risk can be determined based on the target time period. When the current time is the start time, the server status of the preset backup server is adjusted to an available state. Then, the process jumps to the step of collecting the current load status and hardware parameters of each server node in the preset server cluster to update the target load balancing weight of the preset backup server. When the current time is the end time, the preset backup server is removed from the preset server cluster. Specifically, as follows... Figure 7As shown, future network traffic trends can be inferred periodically using ARIMA and LSTM models. Then, based on the configured traffic threshold, it can be determined whether there is a period of risk of traffic overload. If so, corresponding server cluster resource timed scaling tasks are added to adjust the status of backup server nodes to be available before the time of traffic surge to cope with the upcoming high concurrency traffic. In addition, the enabled backup servers can be removed from the server cluster after the high concurrency traffic scale drops to the normal range to ensure high server resource utilization.

[0123] Based on the above technical solution, this embodiment can collect the load indicators and hardware parameters of the backend server nodes, and calculate the real-time weight of each server node through the MLP model for load balancing. Then, logs are collected and processed to obtain the time-series data of historical network traffic, so as to obtain the future network traffic trend through model inference based on ARIMA and LSTM for elastic scaling of the server cluster.

[0124] For a more detailed description of the process of step S21, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0125] Through the above technical solution, this embodiment can collect various indicators representing the load status of server nodes from the backend server cluster in real time. Then, the inherent hardware parameters of the server nodes and the collected dynamic load indicators are input into the MLP model to calculate the distribution weight of each server node. This allows the intelligent load balancing algorithm to update the server node weights and distribute client requests to the most suitable backend server node. This enables a more reasonable method to analyze the true load status of all server nodes and distribute network traffic evenly and reasonably to all service nodes. In addition, client access log information can be collected from the load balancing software periodically and processed into time series data. Then, network traffic trends over a future period can be predicted using ARIMA and LSTM-based models. The time points when traffic may suddenly change can be calculated. Thus, the intelligent load balancing algorithm can proactively expand the server cluster with backup server nodes when traffic surges or remove the expanded backup servers from the server cluster when traffic drops. This achieves adaptive scaling of the server cluster when network traffic changes suddenly, improving resource utilization while ensuring normal service. In this way, by organically combining ARIMA and LSTM, it is possible to more accurately predict the overall traffic trend in a future time period based on historical request data. This allows for the predictive and dynamic scaling of server cluster resources at the point when network traffic changes drastically, ensuring efficient utilization of server resources while avoiding server congestion or downtime due to high concurrency traffic.

[0126] See Figure 8 As shown in the illustration, this application also discloses a network request processing device applied to a preset load balancing tool, comprising:

[0127] The weight determination module 11 is used to collect the current load status and hardware parameters of each server node in the preset server cluster, and input the current load status and hardware parameters into the preset multilayer perceptron model to obtain the load balancing weight of each server node.

[0128] The trend determination module 12 is used to obtain the historical network request logs of the load balancing tool and determine the network traffic change trend of the server cluster based on the historical network request logs through a preset network traffic prediction model; the preset network traffic prediction model is a model constructed based on an autoregressive differential moving average model and a long short-term memory network.

[0129] The request distribution module 13 is used to receive network requests sent by the client and distribute the network requests to each of the server nodes in the preset server cluster according to the load balancing weight and the network traffic change trend, so that each server node can process the corresponding network requests received.

[0130] This embodiment can collect the current load status and hardware parameters of each server node in a preset server cluster, input the current load status and hardware parameters into a preset multilayer perceptron model to obtain the load balancing weight for each server node, and then obtain the historical network request logs of the load balancing tool. Based on a preset network traffic prediction model constructed using an autoregressive differential moving average model and a long short-term memory network, the network traffic change trend of the server cluster is determined according to the historical network request logs. Finally, network requests sent by clients are distributed to each server node in the preset server cluster according to the load balancing weights and network traffic change trends, so that each server node can process the received network requests. The above technical solution can determine the corresponding load balancing weight based on the current load status and hardware parameters of the servers. It takes into account the impact of differences in hardware performance among the servers in the server cluster on the actual load status of the servers, and uses a multilayer perceptron neural network model to evaluate the load status of server nodes, avoiding the bias caused by subjective human decision-making. Then, it uses an autoregressive differential moving average model and a long short-term memory network to predict future network traffic trends, making the scaling time of resources in the server cluster predictable. This can effectively avoid business system interruptions and paralysis caused by sudden traffic, while improving the utilization rate of server resources. It can more reasonably evaluate the load status of servers, and thus dynamically and effectively distribute network traffic based on the real-time performance of all backend servers.

[0131] In some specific embodiments, the weight determination module 11 specifically includes:

[0132] The parameter acquisition unit is used to acquire the current load status and hardware parameters of each server node in the preset server cluster based on a preset data acquisition time interval.

[0133] The weight update unit is used to input the current load status and the hardware parameters into the preset multilayer perceptron model based on the preset data collection time interval to obtain the target load balancing weight of each server node, and update the current load balancing weight of each server node based on the target load balancing weight.

[0134] In some specific embodiments, the weight determination module 11 specifically includes:

[0135] The vector construction unit is used to input the current load state and the hardware parameters into the preset multilayer perceptron model, and construct the feature vector corresponding to each server node according to the current load state and the hardware parameters;

[0136] The first information extraction unit is used to extract the first load information of the feature vector based on the first hidden layer of the preset multilayer perceptron model, the corresponding first preset neuron weights, the first preset bias, and the first preset activation function.

[0137] The second information extraction unit is used to extract the second load information of the feature vector based on the first load information by utilizing the second hidden layer of the preset multilayer perceptron model, based on the corresponding second preset neuron weights, second preset bias, and second preset activation function; the second load information is the load balancing weight corresponding to each of the server nodes.

[0138] In some specific embodiments, the trend determination module 12 specifically includes:

[0139] The information determination unit is used to obtain the historical network request logs of the load balancing tool and determine the timestamp information and server node call information corresponding to each historical network request in the historical network request logs.

[0140] A request determination unit is used to determine the historical network requests corresponding to each server node within a preset time interval based on the timestamp information and the server node call information.

[0141] The request sorting unit is used to count and sort the historical network requests of each server node within the preset time interval according to the timestamp information, and generate network traffic time series data corresponding to the historical network requests within the preset time interval according to the sorting results.

[0142] The trend determination unit is used to determine the network traffic change trend of the server cluster based on the network traffic time series data using the preset network traffic prediction model.

[0143] In some specific embodiments, the trend determination module 12 specifically includes:

[0144] The first data prediction unit is used to input the network traffic time series data into the autoregressive differential moving average model of the preset network traffic prediction model to obtain the first traffic prediction data.

[0145] The data difference unit is used to perform difference analysis on the first traffic prediction data and the network traffic time series data to obtain historical residual data.

[0146] The second data prediction unit is used to input the historical residual data into the long short-term memory network of the preset network traffic prediction model to obtain the second traffic prediction data.

[0147] The result generation unit is used to generate network traffic prediction results for the server cluster based on the first traffic prediction data and the second traffic prediction data, and to determine the corresponding network traffic change trend based on the network traffic prediction results.

[0148] In some specific embodiments, the request distribution module 13 specifically includes:

[0149] The risk assessment unit is used to determine whether the preset server cluster has a risk of traffic overload based on the network traffic change trend.

[0150] The timed scaling submodule is used to add a timed task to scale the resources of the preset server cluster if there is a risk of traffic overload, so as to dynamically adjust the number of server nodes in the preset server cluster to cope with high concurrency traffic.

[0151] The request distribution unit is used to distribute the received client request to each of the server nodes in the preset server cluster according to all available server nodes in the preset server cluster and their corresponding latest load balancing weights.

[0152] In some specific embodiments, the timed scaling submodule specifically includes:

[0153] A time determination unit is used to determine the target time period corresponding to the traffic overload risk, and to determine the start time and end time of the traffic overload risk based on the target time period;

[0154] The status adjustment unit is used to adjust the server status of the preset backup server to an available state when the current time is the start time, and then jump to the step of collecting the current load status and hardware parameters of each server node in the preset server cluster to update the target load balancing weight of the preset backup server, and remove the preset backup server from the preset server cluster when the current time is the end time.

[0155] Furthermore, embodiments of this application also disclose an electronic device, Figure 9 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0156] Figure 9 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the network request processing method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0157] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0158] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0159] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the network request processing method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0160] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned network request processing method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0161] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0162] 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 implementation should not be considered beyond the scope of this application.

[0163] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by 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.

[0164] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0165] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A network request processing method, characterized in that, Applied to pre-defined load balancing tools, including: The current load status and inherent hardware parameters of each server node in a preset server cluster are collected, and the current load status and inherent hardware parameters are input into a preset multilayer perceptron model to obtain the load balancing weight corresponding to each server node; the inherent hardware parameters are the inherent hardware attributes of the server node. The historical network request logs of the load balancing tool are obtained, and the network traffic change trend of the server cluster is determined based on the historical network request logs using a preset network traffic prediction model. The preset network traffic prediction model is a model constructed based on an autoregressive differential moving average model and a long short-term memory network. The system receives network requests sent by clients and distributes the network requests to each of the server nodes in the preset server cluster according to the load balancing weight and the network traffic change trend, so that each server node can process the corresponding network requests received. The step of collecting the current load status and inherent hardware parameters of each server node in the preset server cluster includes: The current load status and inherent hardware parameters of each server node in the preset server cluster are collected based on a preset data collection time interval. Accordingly, the step of inputting the current load state and the inherent hardware parameters into a preset multilayer perceptron model to obtain the load balancing weights corresponding to each server node includes: Based on the preset data collection time interval, the current load status and the inherent hardware parameters are input into the preset multilayer perceptron model to obtain the target load balancing weight of each server node, and the current load balancing weight of each server node is updated based on the target load balancing weight.

2. The network request processing method according to claim 1, characterized in that, The step of inputting the current load state and the inherent hardware parameters into a preset multilayer perceptron model to obtain the load balancing weights corresponding to each server node includes: The current load state and the inherent hardware parameters are input into the preset multilayer perceptron model, and feature vectors corresponding to each server node are constructed based on the current load state and the inherent hardware parameters. Using the first hidden layer of the preset multilayer perceptron model, the first load information of the feature vector is extracted based on the corresponding first preset neuron weights, first preset bias and first preset activation function; Using the second hidden layer of the preset multilayer perceptron model, the second load information of the feature vector is extracted based on the first load information, according to the corresponding second preset neuron weights, second preset bias, and second preset activation function; the second load information is the load balancing weight corresponding to each server node.

3. The network request processing method according to claim 1, characterized in that, The process of obtaining historical network request logs from the load balancing tool and determining the network traffic change trend of the server cluster based on the historical network request logs using a preset network traffic prediction model includes: Obtain the historical network request logs of the load balancing tool, and determine the timestamp information and server node call information corresponding to each historical network request in the historical network request logs; Based on the timestamp information and the server node call information, determine the historical network requests corresponding to each server node within the preset time interval; Based on the timestamp information, the historical network requests of each server node within the preset time interval are statistically analyzed and sorted, and network traffic time series data corresponding to the historical network requests within the preset time interval are generated based on the sorting results. The network traffic change trend of the server cluster is determined based on the network traffic time series data using the preset network traffic prediction model.

4. The network request processing method according to claim 3, characterized in that, The step of determining the network traffic change trend of the server cluster based on the network traffic time series data using the preset network traffic prediction model includes: The network traffic time series data is input into the autoregressive differential moving average model of the preset network traffic prediction model to obtain the first traffic prediction data; The first traffic prediction data and the network traffic time series data are differentially analyzed to obtain historical residual data. The historical residual data is input into the long short-term memory network of the preset network traffic prediction model to obtain the second traffic prediction data; The network traffic prediction results of the server cluster are generated based on the first traffic prediction data and the second traffic prediction data, and the corresponding network traffic change trend is determined based on the network traffic prediction results.

5. The network request processing method according to any one of claims 1 to 4, characterized in that, The step of distributing the network request to each server node in the preset server cluster according to the load balancing weight and the network traffic change trend includes: Based on the network traffic change trend, determine whether the preset server cluster is at risk of traffic overload; If there is a risk of traffic overload, add a scheduled task to scale the resources of the preset server cluster to dynamically adjust the number of server nodes in the preset server cluster to cope with high concurrency traffic. When a client request is received, the network request is distributed to each of the server nodes in the preset server cluster according to all available server nodes in the preset server cluster and their corresponding latest load balancing weights.

6. The network request processing method according to claim 5, characterized in that, The addition of a scheduled task to scale the resources of the preset server cluster, dynamically adjusting the number of server nodes in the preset server cluster to handle high concurrency traffic, includes: Determine the target time period corresponding to the traffic overload risk, and determine the start and end times of the traffic overload risk based on the target time period; When the current time is the start time, the server status of the preset backup server is adjusted to the available state, and the process jumps to the step of collecting the current load status and inherent hardware parameters of each server node in the preset server cluster, so as to update the target load balancing weight of the preset backup server. When the current time is the end time, the preset backup server is removed from the preset server cluster.

7. A network request processing apparatus, characterized in that, Applied to pre-defined load balancing tools, including: The weight determination module is used to collect the current load status and inherent hardware parameters of each server node in the preset server cluster, and input the current load status and the inherent hardware parameters into the preset multilayer perceptron model to obtain the load balancing weight of each server node; the inherent hardware parameters are the inherent hardware attributes of the server node. The trend determination module is used to obtain historical network request logs from the load balancing tool and determine the network traffic change trend of the server cluster based on the historical network request logs using a preset network traffic prediction model; the preset network traffic prediction model is a model constructed based on an autoregressive differential moving average model and a long short-term memory network. The request distribution module is used to receive network requests sent by clients and distribute the network requests to each of the server nodes in the preset server cluster according to the load balancing weight and the network traffic change trend, so that each server node can process the corresponding network request received. The weight determination module includes: The parameter acquisition unit is used to acquire the current load status and inherent hardware parameters of each server node in the preset server cluster based on a preset data acquisition time interval. The weight update unit is used to input the current load status and the inherent hardware parameters into the preset multilayer perceptron model based on the preset data collection time interval to obtain the target load balancing weight of each server node, and update the current load balancing weight of each server node based on the target load balancing weight.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the network request processing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Used to store a computer program, which, when executed by a processor, implements the network request processing method as described in any one of claims 1 to 6.

Images