A method, device, equipment and readable storage medium for requesting data throttling

Abstract

The application discloses a method, device and equipment for request data flow limiting and a readable storage medium. The method comprises the following steps: obtaining historical flow request data of a plurality of servers, wherein the historical flow request data comprises a server identifier, a flow request amount and a time; training a time series prediction algorithm according to the historical flow request data to obtain a trained time series prediction model; determining a predicted flow request amount of a target server identifier at a target time based on the trained time series prediction model, wherein the time series prediction model comprises a corresponding relationship among the server identifier, the time and the flow request amount; and performing request data flow limiting on a target server corresponding to the target server identifier based on the predicted flow request amount. The embodiment can adapt to actual request data changes and perform flow limiting on the target server.

Description

Technical Field

[0001] This application relates to the field of network traffic management, and in particular to a method, apparatus, device, and readable storage medium for request data rate limiting. Background Technology

[0002] In the field of internet communication, many scenarios require limiting the rate of network requests to prevent server failures caused by large traffic surges.

[0003] In related technologies, traffic limiting is typically based on pre-set fixed thresholds. However, this method lacks flexibility and may not adapt to changes in actual requests. Summary of the Invention

[0004] This application provides a method, apparatus, device, and readable storage medium for request data rate limiting, which can adapt to actual changes in request data and rate limit the target server.

[0005] In a first aspect, embodiments of this application provide a method for request data rate limiting. The method includes: acquiring historical traffic request data from multiple servers, the historical traffic request data including server identifiers, traffic request volume, and time; training a time series prediction algorithm based on the historical traffic request data to obtain a trained time series prediction model; determining the predicted traffic request volume of a target server identifier at a target time based on the trained time series prediction model, the time series prediction model including the correspondence between server identifiers, time, and traffic request volume; and performing request data rate limiting on the target server corresponding to the target server identifier based on the predicted traffic request volume.

[0006] According to the first aspect of this application, before training the time series prediction algorithm based on historical traffic request data to obtain a trained time series prediction model, the method further includes: determining whether the historical traffic request data includes resource locators; if the historical traffic request data includes resource locators, training the time series prediction algorithm based on the historical traffic request data.

[0007] According to any of the foregoing embodiments of the first aspect of this application, training a time series prediction algorithm based on historical traffic request data to obtain a trained time series prediction model includes: calculating the change in traffic request volume between any time t and time t-1 in the historical traffic request data; calculating the sum of the changes in traffic request volume between any time t and time ti in the historical traffic request data to obtain a moving average; calculating the sum of the moving averages at time ti to obtain an autoregressive model; and obtaining the trained time series prediction model based on the change in traffic request volume, the moving average, and the autoregressive model.

[0008] According to any of the foregoing embodiments of the first aspect of this application, the sum of the changes in traffic request volume between any time t and time ti in the historical traffic request data is calculated to obtain a moving average value, which satisfies the following relationship: MA(q)=∑(ρ i *ΔY(ti)) where MA(q) represents the moving average, ρ i Let be the first model parameter, and ΔY(ti) be the change in traffic request volume between any time t and time ti.

[0009] According to any of the foregoing embodiments of the first aspect of this application, the sum of the moving averages at time ti is calculated to obtain an autoregressive model that satisfies the following relationship: Where AR(p) represents the autoregressive model, MA(q)(ti) represents the moving average value at time ti, which is the second model parameter.

[0010] According to any of the foregoing embodiments of the first aspect of this application, limiting the request data of a target server corresponding to a target server identifier based on the predicted traffic request volume includes: obtaining current traffic request data of multiple servers, wherein the current traffic request data includes server identifier, traffic request volume, and time; calculating the average request volume and standard deviation of the traffic request volume in the current traffic request data; determining a threshold based on the average request volume, standard deviation, and preset traffic request volume; and limiting the request data of the target server corresponding to the target server identifier based on the threshold. Wherein, determining the threshold based on the average request volume, standard deviation, and preset traffic request volume satisfies the following relationship: R=Q+σ*μ*Y(t+k) / (1+Y(t+k)) where R represents the threshold, Q represents the average request volume, σ represents the standard deviation, μ represents the adjustment factor, and Y(t+k) represents the predicted traffic request volume.

[0011] According to any of the foregoing embodiments of the first aspect of this application, request data flow limiting is performed on the target server corresponding to the target server identifier based on a threshold, including: sending traffic exceeding the threshold of the target server to a backup server based on the type of historical traffic request data and the priority of the routing configuration corresponding to the server.

[0012] According to any of the foregoing embodiments of the first aspect of this application, request data flow limiting is performed on the target server corresponding to the target server identifier based on a threshold, including: sending an alarm message to the target system when the threshold minus the current traffic is less than a preset threshold; and intercepting the traffic exceeding the threshold and returning to the target page when the current traffic exceeds the threshold.

[0013] Secondly, this embodiment provides a request data rate limiting device, which includes: an acquisition module for acquiring historical traffic request data from multiple servers, the historical traffic request data including server identifier, traffic request volume, and time; a training module for training a time series prediction algorithm based on the historical traffic request data to obtain a trained time series prediction model; a determination module for determining the predicted traffic request volume of a target server identifier at a target time based on the trained time series prediction model, the time series prediction model including the correspondence between server identifier, time, and traffic request volume; and a rate limiting module for rate limiting the request data of the target server corresponding to the target server identifier based on the predicted traffic request volume.

[0014] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the request data flow limiting method as described in any one of claims 1-8.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement a request data flow limiting method as described in any of the first aspects.

[0016] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a request data flow limiting method as described in the first aspect.

[0017] This application discloses a method, apparatus, device, and readable storage medium for request data rate limiting. It uses a time series prediction model to predict the traffic request volume of a target server at a target time based on existing historical traffic request data, thus obtaining the predicted traffic request volume. Rate limiting is then applied to the target server based on this predicted traffic request volume. This process does not require manually setting a fixed threshold for rate limiting, and because the predicted traffic request volume is based on historical traffic request data, the predicted request volume is reasonable and can adapt to actual request changes; achieving automatic traffic balancing control without manual intervention. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a method for request data rate limiting provided in an embodiment of this application;

[0020] Figure 2 This is a flowchart illustrating another method for request data rate limiting provided in an embodiment of this application;

[0021] Figure 3 This is a flowchart illustrating another method for request data rate limiting provided in this application embodiment.

[0022] Figure 4 This is a schematic diagram of the structure of a request data rate limiting device provided in an embodiment of this application;

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

[0024] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0025] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0026] As described in the background section, traffic limiting in related technologies is typically based on pre-set fixed thresholds. However, this approach lacks flexibility and may not adapt to changes in actual requests.

[0027] To address the aforementioned technical problems, embodiments of this application provide a method, apparatus, device, readable storage medium, and computer program product for requesting data rate limiting. The method for requesting data rate limiting provided in this application embodiment will be described first below.

[0028] Figure 1 This is a flowchart illustrating a method for request data rate limiting according to an embodiment of this application. Figure 1 As shown, the request data rate limiting method provided in this application embodiment may include: S110-S140.

[0029] S110: Obtain historical traffic request data from multiple servers.

[0030] Historical traffic request data includes server identifier, traffic request volume, and time.

[0031] The time can be the time when the requested data was sent, and the traffic request volume can include the amount of requests within a certain period. For example, the traffic request volume includes the number of requests per second, per minute, and per hour, as well as the request size.

[0032] In some embodiments, when acquiring and processing historical traffic request data, data security and privacy can be ensured through methods such as data anonymization and encryption.

[0033] In some embodiments, a high-performance and low-latency database or caching system, such as Redis, may also be considered for storing data.

[0034] S120. Train the time series prediction algorithm based on historical traffic request data to obtain a trained time series prediction model.

[0035] For example, time series forecasting algorithms may include the ARIMA algorithm. The ARIMA algorithm typically uses operations such as differencing, moving averages, and autoregression to capture the inherent patterns in the data for forecasting training. See [link to training process details] for more information. Figure 2 Detailed explanation of some parts.

[0036] S130. Based on the trained time series prediction model, determine the predicted traffic request volume of the target server at the target time.

[0037] The time series prediction model includes the correspondence between server identifier, time, and traffic request volume.

[0038] Since the predicted traffic request volume is based on a trained time series prediction model, which is trained on historical traffic request data, the predicted traffic request volume can adapt to actual request changes without the need for manually setting fixed thresholds for rate limiting. Furthermore, as historical traffic request data is updated—that is, as new data continuously enters the system—the time series prediction model is also periodically updated to adapt to changes in traffic.

[0039] S140. Based on the predicted traffic request volume, limit the request data flow to the target server corresponding to the target server identifier.

[0040] In some embodiments, the predicted traffic request volume is the maximum request volume value within one or more window periods, such as the maximum request volume within the last 5 minutes, 1 hour, 24 hours, or 1 week.

[0041] For details on the rate limiting process, please refer to [link / reference]. Figure 3 Detailed explanation of some parts.

[0042] This application provides a method for rate limiting of requested data. It uses a time series prediction model to predict the traffic request volume of a target server at a target time based on existing historical traffic request data, thus obtaining the predicted traffic request volume. Rate limiting is then applied to the target server based on this predicted traffic request volume. This process does not require manually setting a fixed threshold for rate limiting, and because the predicted traffic request volume is based on historical traffic request data, the predicted volume is reasonable and can adapt to actual request changes; achieving automatic traffic balancing control without manual intervention.

[0043] In some embodiments, before training the time series prediction algorithm based on historical traffic request data to obtain a trained time series prediction model in S120, the method for limiting request data flow may further include: step one and step two.

[0044] Step 1: Determine whether the historical traffic request data includes resource locators.

[0045] The resource locator can be a Uniform Resource Locator (URL). A URL is an address used to locate a specific resource on the internet and is commonly found in web page traffic and HTTP requests.

[0046] Step 2: If the historical traffic request data includes resource locators, train the time series prediction algorithm based on the historical traffic request data.

[0047] In this embodiment, the processing efficiency can be improved by determining whether the historical traffic request data includes resource locators. If the historical traffic request data does not include resource locators, then the historical traffic request data without resource locators is initialized.

[0048] In some embodiments, to ensure high availability and rapid updates of the time series forecasting model, the model should support multiple deployment methods, such as containerized deployment or bare metal deployment.

[0049] In some embodiments, such as Figure 2 As shown, S120, training the time series prediction algorithm based on historical traffic request data to obtain a trained time series prediction model, may include: S121-S124.

[0050] S121. Calculate the change in traffic request volume between any time t and time t-1 in the historical traffic request data.

[0051] In some embodiments, S121, the change in traffic request volume between any time t and time t-1 in the historical traffic request data is calculated, satisfying the following relationship:

[0052] ΔYt=Yt-Y(t-1) (1)

[0053] In the formula, ΔYt represents the change in traffic request volume, Yt represents the traffic request volume at any time t, and Y(t-1) represents the traffic request volume at time t-1.

[0054] S122. Calculate the sum of the changes in traffic request volume between any time t and time ti in the historical traffic request data, and obtain the moving average value.

[0055] In some embodiments, S122, the sum of the changes in traffic request volume between any time t and time ti in the historical traffic request data is calculated to obtain a moving average value that satisfies the following relationship:

[0056] MA(q)=∑(ρ i *ΔY(ti)) (2)

[0057] Where MA(q) represents the moving average, ρ i Let be the first model parameter, and ΔY(ti) be the change in traffic request volume between any time t and time ti.

[0058] S123. Calculate the sum of the moving averages at time ti to obtain the autoregressive model.

[0059] In some embodiments, S123, the sum of the moving averages at time ti is calculated to obtain an autoregressive model that satisfies the following relationship:

[0060]

[0061] Where AR(p) represents the autoregressive model, MA(q)(ti) represents the moving average value at time ti, which is the second model parameter.

[0062] ρ i and These are two parameters of the time series prediction model, which can be estimated using optimization methods such as the least squares method.

[0063] S124. Based on the changes in traffic requests, the moving average, and the autoregressive model, a trained time series prediction model is obtained.

[0064] Combining the above formulas (1)-(3), we can obtain:

[0065]

[0066] Where ARIMA(p,d,q) is the model calculation formula of the ARIMA algorithm.

[0067] Finally, the model calculation formula corresponding to the time series prediction model can be obtained as follows:

[0068]

[0069] Where Y(t+k) represents the traffic request at time t+k, ΔY(t+ki) is the change in traffic request between any time t and time ti, and MA(q)(t+k) represents the moving average at time t+k.

[0070] It is important to note that the traffic request volume calculated based on this time series forecasting model is the predicted traffic request volume. In some embodiments, the predicted traffic request volume needs to be adjusted. For example... Figure 3 As shown, S140 may include S141-S144.

[0071] S141. Obtain current traffic request data from multiple servers. The current traffic request data includes server identifier, traffic request volume, and time.

[0072] S142. Calculate the average request volume and standard deviation of the traffic request volume in the current traffic request data.

[0073] S143. Determine the threshold based on the average request volume, standard deviation, and preset traffic request volume.

[0074] S144. Based on the threshold, limit the request data flow to the target server corresponding to the target server identifier.

[0075] The thresholds, determined based on average request volume, standard deviation, and preset traffic request volume, satisfy the following relationship:

[0076] R = Q + σ*μ*Y(t+k) / (1+Y(t+k))

[0077] Where R represents the threshold, Q represents the average request volume, σ represents the standard deviation, μ represents the adjustment factor, and Y(t+k) represents the predicted traffic request volume.

[0078] In some embodiments, the threshold can be fine-tuned according to actual circumstances (holidays, promotional activities, or other specific events) to set different alarm thresholds and blocking thresholds. For example, if the threshold is 100G, then 100G * 0.8 = 80G, and 80G is set as the alarm threshold, an alarm signal will be sent to the relevant system when the current traffic is equal to or greater than 80G.

[0079] In some embodiments, S144, limiting the request data flow to the target server corresponding to the target server identifier according to the threshold, may include: step three.

[0080] Step 3: Based on the type of historical traffic request data and the priority of the corresponding server's routing configuration, send traffic exceeding the threshold from the target server to the backup server.

[0081] It's important to understand that one gateway corresponds to multiple servers, and different servers correspond to different routes with different priorities. The gateway distributes traffic to the servers through these routes. For example, one gateway might correspond to three servers: one target server and the others as backup servers. The route corresponding to the target server has the highest priority. When the current traffic request volume for the target server exceeds the predicted traffic request volume, the overflow traffic is sent to the backup servers through lower-priority routes. This ensures the smooth processing of critical requests.

[0082] In some embodiments, S144, according to the threshold, performing request data rate limiting on the target server corresponding to the target server identifier, may include steps four and five.

[0083] Step 4: If the threshold minus the current traffic is less than the preset threshold, send an alarm message to the target system.

[0084] For example, the threshold is 100, the preset threshold is 10, and when the difference between the current traffic and the threshold is less than 10, an alarm signal is triggered.

[0085] Step 5: If the current traffic exceeds the threshold, intercept the traffic exceeding the threshold and return to the target page.

[0086] In some embodiments, consider using traffic control tools and middleware, such as excellent open-source API gateways like Apisix, Kong, or Istio, to intercept and route traffic.

[0087] To ensure the stability and effectiveness of the system, in some embodiments, the performance and accuracy of the system corresponding to request data rate limiting can be evaluated periodically, for example, through A / B testing and canary release testing.

[0088] Training solely on the volume of traffic requests may be too simplistic and yield suboptimal results. In some embodiments, in addition to learning the maximum request volume, other metrics such as request success rate, response time, and status code weighting can be incorporated to further optimize the rate limiting strategy. Furthermore, for traffic overflow, alternative handling methods can be introduced, such as automatic scaling and dynamic scheduling.

[0089] Some unexpected events may cause temporary spikes in traffic, but this may not indicate a future trend. In some embodiments, smoothing techniques or weighted averaging can be used to ensure that short-term traffic fluctuations do not unduly affect the learning results.

[0090] Continuously recording the number of requests within each window can require significant storage resources. In some embodiments, data compression, sampling, or aggregation strategies can be employed to reduce storage requirements.

[0091] When traffic requests suddenly increase, time series forecasting models may need time to adapt and relearn. In some embodiments, a fast response mechanism, such as using a sliding window or a fast-response algorithm, can be implemented to shorten the adjustment time.

[0092] When the system generates false alarms or false blocks due to occasional traffic fluctuations or learning errors, a fault tolerance threshold can be set, providing an opportunity for manual intervention. Simultaneously, verification mechanisms, such as CAPTCHAs, can be used to distinguish between legitimate users and malicious traffic.

[0093] Based on the same inventive concept as the request data rate limiting method provided in the embodiments, this application also provides a request data rate limiting apparatus 400. Please see the following embodiments.

[0094] like Figure 4 As shown, the device 400 for requesting data rate limiting may include: an acquisition module 401, a training module 402, a determination module 403, and a rate limiting module 404.

[0095] The acquisition module 401 is used to acquire historical traffic request data from multiple servers. The historical traffic request data includes server identifier, traffic request volume, and time.

[0096] Training module 402 is used to train the time series prediction algorithm based on historical traffic request data to obtain a trained time series prediction model.

[0097] The determination module 403 is used to determine the predicted traffic request volume of the target server identifier at the target time based on the trained time series prediction model. The time series prediction model includes the correspondence between the server identifier, time, and traffic request volume.

[0098] The rate limiting module 404 is used to limit the request data of the target server corresponding to the target server identifier based on the predicted traffic request volume.

[0099] As one implementation of this application, the above-mentioned device may further include a judgment module, which is specifically used to determine whether the historical traffic request data includes a resource locator, and the training module 402 is specifically used to train the time series prediction algorithm based on the historical traffic request data when the historical traffic request data includes a resource locator.

[0100] As another implementation of this application, the training module 402 is specifically used to calculate the change in traffic request volume between any time t and time t-1 in the historical traffic request data; calculate the sum of the changes in traffic request volume between any time t and time ti in the historical traffic request data to obtain the moving average; calculate the sum of the moving averages at time ti to obtain the autoregressive model; and obtain the trained time series prediction model based on the change in traffic request volume, the moving average, and the autoregressive model.

[0101] As another implementation of this application, the sum of the changes in traffic request volume between any time t and time ti in the historical traffic request data is calculated to obtain the moving average, which satisfies the following relationship: MA(q)=∑(ρ i *ΔY(ti)) where MA(q) represents the moving average, ρ i Let be the first model parameter, and ΔY(ti) be the change in traffic request volume between any time t and time ti.

[0102] As another implementation of this application, the sum of the moving averages at time ti is calculated to obtain an autoregressive model that satisfies the following relationship: Where AR(p) represents the autoregressive model, MA(q)(ti) represents the moving average value at time ti, which is the second model parameter.

[0103] As another implementation of this application, the rate limiting module 404 is specifically used to obtain the current traffic request data of multiple servers, the current traffic request data including server identifier, traffic request volume and time; calculate the average request volume and standard deviation of the traffic request volume in the current traffic request data; determine the threshold based on the average request volume, standard deviation and preset traffic request volume; and perform request data rate limiting on the target server corresponding to the target server identifier based on the threshold; wherein, the threshold determined based on the average request volume, standard deviation and preset traffic request volume satisfies the following relationship: R=Q+σ*μ*Y(t+k) / (1+Y(t+k)) where R represents the threshold, Q represents the average request volume, σ represents the standard deviation, μ represents the adjustment factor and Y(t+k) represents the predicted traffic request volume.

[0104] As another implementation of this application, the rate limiting module 404 is specifically used to send traffic exceeding the threshold of the target server to the backup server according to the type of historical traffic request data and the priority of the routing configuration corresponding to the server.

[0105] As another implementation of this application, the rate limiting module 404 is specifically used to send an alarm message to the target system when the threshold minus the current traffic is less than the preset threshold; and to intercept the traffic exceeding the threshold and return to the target page when the current traffic exceeds the threshold.

[0106] This application provides an apparatus for request data rate limiting. It uses a time series prediction model to predict the traffic request volume of a target server at a target time based on existing historical traffic request data, thus obtaining the predicted traffic request volume. Rate limiting is then applied to the target server based on this predicted traffic request volume. This process does not require manually setting a fixed threshold for rate limiting, and because the predicted traffic request volume is based on historical traffic request data, the predicted volume is reasonable and can adapt to actual request changes; achieving automatic traffic balancing control without manual intervention.

[0107] If the training module 402 malfunctions, the device requesting data rate limiting may lose its dynamic adjustment capability. Therefore, in some embodiments, a backup mechanism or redundant system can be implemented to ensure that the device requesting data rate limiting can still operate normally when a critical module malfunctions.

[0108] Malicious users may attempt to trick data rate limiting devices by simulating traffic patterns, causing them to make incorrect judgments. This can be addressed by combining malicious behavior with other security strategies, such as IP blacklists and user behavior analysis.

[0109] Figure 5 A schematic diagram of an electronic device provided in an embodiment of this application, such as... Figure 5 As shown, the electronic device includes a processor 501 and a memory 502 storing computer program instructions.

[0110] Specifically, the processor 501 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0111] Memory 502 may include mass storage for data or instructions. For example, and not limitingly, memory 502 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where suitable, memory 502 may include removable or non-removable (or fixed) media. Where suitable, memory 502 may be internal or external to an electronic device. In a particular embodiment, memory 502 is a non-volatile solid-state memory.

[0112] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to the first aspect of this application.

[0113] The processor 501 implements any of the request data flow limiting methods in the above embodiments by reading and executing computer program instructions stored in the memory 502.

[0114] In one example, an electronic device may further include a communication interface 503 and a bus 510. Wherein, as... Figure 5 As shown, the processor 501, memory 502, and communication interface 503 are connected through bus 510 and complete communication with each other.

[0115] The communication interface 503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0116] Bus 510 includes hardware, software, or both, that couples components of a terminal service device together. For example, and not limited to, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Linear Predictive Coding (LPC) bus, a memory bus, a MicroChannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (Peripheral Component Interconnect-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VESA Local Bus, VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0117] This device can execute the request data rate limiting method in the embodiments of this application based on each unit / component in the request data rate limiting device, thereby achieving a combination Figures 1 to 3 Described data processing methods

[0118] Furthermore, in conjunction with the request data rate limiting method in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the request data rate limiting methods in the above embodiments.

[0119] This application also provides a computer program product, including a computer program, which, when executed, implements any of the request data rate limiting methods described in the above embodiments.

[0120] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0121] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0122] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0123] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0124] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for request data rate limiting, characterized in that, include: Obtain historical traffic request data from multiple servers, wherein the historical traffic request data includes server identifier, traffic request volume, and time; The time series prediction algorithm is trained based on the historical traffic request data to obtain a trained time series prediction model; Based on a trained time series prediction model, the predicted traffic request volume of the target server identifier at the target time is determined. The time series prediction model includes the correspondence between the server identifier, time, and traffic request volume. Based on the predicted traffic request volume, the request data rate is limited for the target server corresponding to the target server identifier.

2. The method for request data rate limiting according to claim 1, characterized in that, Before training the time series prediction algorithm based on the historical traffic request data to obtain the trained time series prediction model, the method further includes: Determine whether the historical traffic request data includes resource locators; If the historical traffic request data includes the resource locator, the time series prediction algorithm is trained based on the historical traffic request data.

3. The method for request data rate limiting according to claim 1, characterized in that, The step of training the time series prediction algorithm based on the historical traffic request data to obtain a trained time series prediction model includes: Calculate the change in traffic request volume between any time t and time t-1 in the historical traffic request data; Calculate the sum of the changes in traffic request volume between any time t and time ti in the historical traffic request data to obtain the moving average value; Calculate the sum of the moving averages at time ti to obtain the autoregressive model; Based on the change in traffic request volume, the moving average, and the autoregressive model, a trained time series prediction model is obtained.

4. The method for request data rate limiting according to claim 3, characterized in that, The sum of the changes in traffic request volume between any time t and time ti in the historical traffic request data is calculated to obtain a moving average value, which satisfies the following relationship: MA(q)=∑(ρ i *ΔY(ti)) Where MA(q) represents the moving average, ρ i Let be the first model parameter, and ΔY(ti) be the change in traffic request volume between any time t and time ti.

5. The method for request data rate limiting according to claim 3 or 4, characterized in that, The sum of the moving averages at time ti is used to obtain the autoregressive model, which satisfies the following relationship: Where AR(p) represents the autoregressive model, MA(q)(ti) represents the moving average value at time ti, which is the second model parameter.

6. The method for request data rate limiting according to claim 1, characterized in that, The step of limiting the request data flow to the target server corresponding to the target server identifier based on the predicted traffic request volume includes: Obtain current traffic request data from multiple servers, wherein the current traffic request data includes server identifier, traffic request volume, and time; Calculate the average request volume and standard deviation of the traffic request volume in the current traffic request data; The threshold is determined based on the average request volume, the standard deviation, and the preset traffic request volume; Based on the threshold, request data flow is limited for the target server corresponding to the target server identifier; Wherein, the threshold determined based on the average request volume, the standard deviation, and the preset traffic request volume satisfies the following relationship: R = Q + σ*μ*Y(t+k) / (1+Y(t+k)) Where R represents the threshold, Q represents the average request volume, σ represents the standard deviation, μ represents the adjustment factor, and Y(t+k) represents the predicted traffic request volume.

7. The method for request data rate limiting according to claim 6, characterized in that, The step of limiting the request data flow to the target server corresponding to the target server identifier based on the threshold includes: Based on the type of historical traffic request data and the priority of the corresponding server's routing configuration, traffic exceeding the threshold from the target server is sent to a backup server.

8. The method for request data rate limiting according to claim 6, characterized in that, The step of limiting the request data flow to the target server corresponding to the target server identifier based on the threshold includes: If the difference between the current traffic and the threshold is less than a preset threshold, an alarm message is sent to the target system. If the current traffic exceeds the threshold, the traffic exceeding the threshold is blocked, and the user is returned to the target page.

9. A device for requesting data rate limiting, characterized in that, The device includes: The acquisition module is used to acquire historical traffic request data from multiple servers, wherein the historical traffic request data includes server identifier, traffic request volume, and time. The training module is used to train the time series prediction algorithm based on the historical traffic request data to obtain a trained time series prediction model. The determination module is used to determine the predicted traffic request volume of the target server identifier at the target time based on the trained time series prediction model. The time series prediction model includes the correspondence between the server identifier, time, and traffic request volume. The rate limiting module is used to limit the request data to the target server corresponding to the target server identifier based on the predicted traffic request volume.

10. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the request data rate limiting method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the request data rate limiting method as described in any one of claims 1-8.

12. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the request data flow limiting method as described in any one of claims 1-8.

Images