Method, system, device and medium for controlling API request traffic

Abstract

The embodiment of the application provides an API request flow control method, system, device and medium, and belongs to the field of computer networks.The method comprises the following steps: receiving an API request and recording a timestamp; determining the time window to which the API request belongs according to the timestamp, and checking whether the number of requests that have passed in the time window exceeds the maximum number of requests allowed in the current time window; if not, allowing the API request to continue, updating the number of requests that have passed in the time window, obtaining the system load and the time window flow saturation, and adjusting the maximum number of requests of the subsequent time window by using a window calculation model; and if yes, rejecting the API request or adding the API request to a waiting queue.The real-time load is dynamically adjusted to dynamically adjust the flow control strategy, the impact of burst flow on the system can be effectively avoided, smooth allocation of flow is realized, the size of the time window is intelligently adjusted, the overload problem caused by the fixed time window is avoided, and the stability of the back-end service is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer networks, in particular to an API request flow control method, system, device and medium. BACKGROUND

[0002] With the popularity of microservice architecture, traditional single-machine throttling (such as semaphore or thread pool isolation) cannot achieve global flow control in a multi-node environment. For example, when a scheduled task is deployed on multiple machines, concurrent data pulling will cause a surge in downstream service pressure, and single-machine throttling cannot count the total number of requests across nodes. At this time, a throttling mechanism that can coordinate across machines is needed to ensure that the overall request rate of the cluster is controllable.

[0003] In the microservice architecture, the API gateway (such as Spring Cloud Gateway) acts as an intermediary for inter-service communication, responsible for receiving and forwarding requests, and also needs to provide a flow control mechanism to ensure the stability of the backend services and the rational use of resources. Common flow control algorithms include leaky bucket algorithm, token bucket algorithm, etc.

[0004] However, existing flow control algorithms often have some problems, such as: fixed window problem: fixed time window flow control strategy cannot make flexible adjustments according to actual traffic changes, which may cause requests to concentrate in a short time, causing system overload. Insufficient handling of burst traffic: high-concurrency requests often appear in a large number of requests in a short time, and existing algorithms cannot well alleviate the instantaneous traffic impact. Performance bottleneck: traditional flow control algorithms may have performance bottlenecks when handling high-concurrency scenarios, affecting system response time. SUMMARY

[0005] The purpose of the embodiments of the present application is to provide an API request flow control method, system, device and medium, which dynamically adjusts the flow control strategy according to real-time load, can effectively avoid the impact of burst traffic on the system, realizes smooth allocation of traffic, and through intelligent adjustment of the size of the time window, avoids the overload problem caused by the fixed time window, and ensures the stability of the backend services.

[0006] To achieve the above purpose, the embodiments of the present application provide an API request flow control method, comprising:

[0007] receiving API requests entering the gateway and recording the timestamps of the API requests;

[0008] determining the time window to which the API request belongs according to the timestamp of the API request, and checking whether the number of requests passed in the time window exceeds the maximum number of requests allowed by the current time window;

[0009] If not, the API request is allowed to continue, the number of passed requests in the time window is updated, the system load condition and the time window traffic saturation are obtained, and the maximum number of requests in the subsequent time window is adjusted based on the system load condition and the time window traffic saturation by using a window calculation model;

[0010] If so, the API request is rejected and a flow limiting error message is returned, a rejection log is recorded, or the API request is added to a waiting queue, and an upper limit of the length of the waiting queue and a request timeout threshold are set, and the API request is discarded when the queue is full or the request is not processed within the timeout threshold.

[0011] Optionally, adjusting the maximum number of requests in the subsequent time window based on the system load condition comprises:

[0012] In a low load condition, increasing the maximum number of requests in the time window, wherein the low load condition is represented by a system load factor being lower than a load preset threshold;

[0013] In a high load condition, decreasing the maximum number of requests in the time window, wherein the high load condition is represented by the system load factor being higher than the load preset threshold.

[0014] Optionally, the load factor is calculated according to the following formula:

[0015] F = min(σ, L x 1.5);

[0016] In the formula, F represents the system load factor, L represents the system load, and σ represents the load preset threshold.

[0017] Optionally, adjusting the maximum number of requests in the subsequent time window based on the system load condition and the time window traffic saturation by using the window calculation model comprises: obtaining a target time window according to the following formula:

[0018] ;

[0019] In the formula, W represents the target window, represents a window reference value, S represents the time window traffic saturation, and F represents the system load factor.

[0020] Optionally, the time window traffic saturation is calculated according to the following formula:

[0021] ;

[0022] In the formula, S is the time window traffic saturation, is the current query rate per second of the system, is the maximum query rate per second of the system.

[0023] Optionally, before determining the time window to which the API request belongs according to the timestamp of the API request and checking whether the number of API requests passed in the time window exceeds the maximum number of API requests allowed in the current time window, the control method further comprises:

[0024] defining a gateway filter to intercept each API request entering the gateway;

[0025] using an AtomicInteger counter to count the number of API requests in the current time window, and determining whether the API request enters a new time window, if yes, resetting the request count and updating the window reset time.

[0026] Optionally, the control method further comprises:

[0027] if the number of requests in the continuous multiple window periods exceeds the maximum number, triggering a fuse mechanism to stop receiving new API requests.

[0028] In a second aspect, the present application further provides an API request flow control system, comprising:

[0029] a request counter configured to count the number of API requests received in the current window;

[0030] a load detection mechanism configured to monitor the system load in real time and obtain the system load condition and the time window flow saturation degree;

[0031] a flow control module configured to check whether the number of API requests passed in the time window exceeds the maximum number of API requests allowed in the current time window; if not, allowing the API request to continue, updating the number of API requests passed in the time window, obtaining the system load condition and the time window flow saturation degree, and adjusting the maximum number of API requests in the subsequent time window based on the system load condition and the time window flow saturation degree using a window calculation model; if yes, rejecting the API request and returning a flow limiting error message, recording a rejection log, or adding the API request to a waiting queue, setting an upper limit of the waiting queue length and a request timeout threshold, and discarding the API request when the queue is full or the request times out.

[0032] In a third aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the API request flow control method described above.

[0033] In a fourth aspect, the present application provides a non-transitory computer readable storage medium having a computer program stored thereon, wherein the computer program is executable by a processor to implement the steps of the API request flow control method described above.

[0034] Through the technical solution, the flow control strategy is dynamically adjusted according to real-time load, so that the impact of burst flow on the system can be effectively avoided, smooth allocation of flow is realized, and through intelligent adjustment of the time window size, the overload problem caused by the fixed time window is avoided, and the stability of the backend service is ensured.

[0035] Other features and advantages of the embodiments of the present application will be described in detail in the following detailed description. BRIEF DESCRIPTION OF DRAWINGS

[0036] The accompanying drawings are included to provide a further understanding of the embodiments of the application, and constitute a part of the specification, and are used to explain the embodiments of the application together with the following detailed description, but do not constitute a limitation on the embodiments of the application. In the drawings:

[0037] Figure 1 is a flow chart of an API request flow control method provided by the embodiments of the present application;

[0038] Figure 2 is a detailed flow chart of an API request flow control method provided by the embodiments of the present application;

[0039] Figure 3 is a structural schematic diagram of an API request flow control system provided by the embodiments of the present application;

[0040] Figure 4 is a hardware structure schematic diagram of an electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0041] The specific embodiments of the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings. It should be understood that the specific embodiments described herein are only used to illustrate and explain the embodiments of the present application, and are not used to limit the embodiments of the present application.

[0042] In the following detailed description, various embodiments of the present disclosure will be described more fully. The present disclosure can have various embodiments, and adjustments and changes can be made therein. However, it should be understood that there is no intention to limit various embodiments of the present disclosure to the specific embodiments disclosed herein, but the present disclosure should be understood to cover all adjustments, equivalents and / or alternatives falling within the spirit and scope of various embodiments of the present disclosure.

[0043] Hereinafter, the term "include" or "may include" used in various embodiments of the present disclosure indicates the presence of the disclosed functions or operations and does not limit one or more additions of functions or operations. Also, as used in various embodiments of the present disclosure, the terms "include", "have", and their conjugates merely indicate that specific features, numbers, steps, operations, or combinations thereof are present and do not exclude the existence or addition of one or more other features, numbers, steps, operations, or combinations thereof.

[0044] In various embodiments of the present disclosure, the expression "or" or "at least one of A or / and B" includes any combination of the listed terms or all combinations thereof. For example, the expression "A or B" or "at least one of A or / and B" can include A, can include B, or can include both A and B.

[0045] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0046] Referring to Figure 1 The flowchart of the API request traffic control method in a specific embodiment is shown, which includes the following execution steps:

[0047] Step 100: Receive the API request entering the gateway and record the timestamp of the API request.

[0048] For example, the gateway receives an API request from the client, such as POST / api / payment.

[0049] Step 101: Determine the time window to which the API request belongs according to the timestamp of the API request, and check whether the number of requests passed in the time window exceeds the maximum number of requests allowed in the current time window.

[0050] Specifically, first, time window division is performed: time is divided into multiple fixed-length time windows, for example, every 1 second is a time window, and the length of the time window can be adjusted according to actual needs without limitation. Then, time window storage is performed: a preset data structure is used to store time window information, for example, a hash table, wherein the key of the hash table can be the start time or end time of the time window, and the value is the number of requests that have passed in the time window. Finally, time window updating is performed: when a request arrives, the time stamp of the request is used to determine the time window to which the request belongs. If the time window does not exist in the hash table, the time window is created and the number of passed requests is initialized to 0. Then, the number of passed requests in the time window is incremented by 1, and expired time windows are periodically cleaned up to save storage space.

[0051] In some embodiments, according to a preset time window size, such as 1 second, 1 minute, etc., and the time stamp of the request, the time window to which the request belongs is determined. For example, if the time window size is 1 second and the current time is 10:00:05.234, then the time window to which the request belongs is 10:00:05.000-10:00:06.000.

[0052] It can be seen that the main purpose of checking whether the number of requests that have passed in the window exceeds the allowed maximum number of requests is to achieve request throttling, to ensure the stability, availability and performance of the system, which is embodied in the following aspects:

[0053] System resources (such as CPU, memory, network bandwidth, etc.) are limited. If a large number of requests pour in within a short period of time, the system may run out of resources due to being unable to process them in time. For example, a web server may have a CPU usage rate that rises to 100% under high concurrency requests, causing the server to be unable to respond to new requests, or even to crash. By checking whether the number of requests exceeds the maximum limit, this situation can be prevented, ensuring that the system has enough resources to handle normal requests. By limiting the number of requests in each time window, the system can dynamically adjust resource allocation according to actual load conditions. In low load conditions, more requests are allowed to enter, improving resource utilization; in high load conditions, the number of requests is limited to avoid excessive resource consumption. For example, a cloud computing platform can dynamically adjust the resource allocation of each virtual machine according to user needs and system load conditions, ensuring that resources are used reasonably.

[0054] Support for priority processing: the throttling mechanism can be used in combination with a priority policy to ensure that important requests are processed first. For example, in a real-time monitoring system, emergency alert requests can be set to a higher priority and passed first during throttling, while ordinary data collection requests can be set to a lower priority and processed when system resources are sufficient. This can improve the system's ability to handle critical business.

[0055] Follow system planning: Every system is designed with its expected load capacity and performance indicators. Rate limiting mechanisms can help systems operate according to design requirements, avoiding exceeding their capacity. For example, a newly launched online education platform might be designed to support 100,000 concurrent users. Rate limiting can ensure that the actual number of users does not exceed this limit, guaranteeing the platform's stable operation.

[0056] Facilitates system scalability: As system load gradually increases, rate limiting mechanisms can provide a buffer time for system expansion. By monitoring request volume and system performance, administrators can promptly identify system bottlenecks and take corresponding expansion measures, such as adding servers or optimizing code. For example, a social media platform experiencing rapid user growth can control request traffic through rate limiting while simultaneously scaling up the system to ensure a smooth transition.

[0057] In some implementations, the following steps are performed before performing step 101:

[0058] S1: Define a Gateway filter to intercept every API request entering the gateway.

[0059] S2: Use an AtomicInteger counter to count the number of API requests within the current time window, and determine whether the API request has entered a new time window. If so, reset the request count and update the window reset time.

[0060] By integrating the elastic window algorithm into the filters of Spring Cloud Gateway, traffic control is applied to each API request entering the gateway, ensuring that the request volume does not exceed the set limit. Spring Cloud's configuration management features allow for flexible adjustment of flow control parameters, such as maximum request count and window size, to meet the needs of different business scenarios.

[0061] Step 102: If the time limit is not exceeded, allow the API request to continue, update the number of requests that have been approved within the time window, obtain the system load and time window traffic saturation, and use the window calculation model to adjust the maximum number of requests in subsequent time windows based on the system load and time window traffic saturation.

[0062] Specifically, in step 102, the time window size is adjusted according to the system load, including the following two cases:

[0063] 1. Under low load conditions, increase the maximum number of requests within the time window, where the low load condition is defined as the system load factor being lower than a preset load threshold.

[0064] 2. Reduce the maximum number of requests in the time window in high load situations, where the high load situation is represented by a system load factor higher than a load preset threshold.

[0065] If the system is in a high load state, in order to reduce the system pressure, the maximum number of requests allowed in the current time window needs to be reduced, and the adjustment range can be determined according to the severity of the load, for example, the maximum number of requests is reduced by 10% for every 10% increase in CPU usage. If the system is in a low load state, in order to improve resource utilization, the maximum number of requests allowed in the current time window can be appropriately increased. Similarly, the adjustment range can be determined according to the load situation, for example, the maximum number of requests is increased by 10% for every 10% decrease in CPU usage. In addition, in order to prevent the maximum number of requests from fluctuating frequently and causing the system to be unstable, the adjustment range and adjustment frequency of the maximum number of requests are limited. For example, the maximum number of requests can only be adjusted between 50% and 150% of the initial value, and at most once per minute.

[0066] In a specific embodiment, the elastic adjustment is based on the current QPS (Queries Per Second) of the system and the load situation. The function first sets a 1000 millisecond base window reference value, and then dynamically adjusts it through two key factors: traffic adaptation factor, using an exponential decay function to process traffic saturation (the ratio of current QPS to maximum QPS), so that the window can be expanded to improve processing capacity in low load, and converge to the reference window to prevent overload in high load; load suppression factor 1.5-0.5x load factor, linearly adjusted according to the amplified system load, gradually reducing the window to protect the system in high load. Finally, the function returns the product of the base window size and the two factors as the result, thereby realizing a dynamic window mechanism that can actively respond to low load and protect itself in high load.

[0067] More specifically, the load factor can be calculated according to the following formula:

[0068] F=min(σ,L×1.5);

[0069] In the formula, F represents the system load factor, L represents the system load, and σ represents the load preset threshold.

[0070] In some embodiments, the window calculation model is used to adjust the maximum number of requests in the subsequent time window according to the system load situation and the traffic saturation of the time window, including: obtaining the target time window according to the following formula:

[0071] ;

[0072] In the formula, W represents the target window, S represents a time window reference value, S represents a time window traffic saturation, and F represents a system load factor.

[0073] More specifically, the time window traffic saturation is calculated according to the following formula:

[0074] ;

[0075] In the formula, S is the time window traffic saturation, is the current per-second query rate of the system, is the maximum per-second query rate of the system.

[0076] Step 103: If the API request exceeds the limit, reject the API request and return a flow control error message, record a rejection log, or add the API request to a waiting queue, set an upper limit of the waiting queue length and a request timeout threshold, and discard the API request when the queue is full or the request times out.

[0077] In a specific example, the flow control implementation process is as follows: when the request is processed, the flexible window filter first checks whether the current time has reached a new window period based on a variable window length (initially 2 seconds); if it has, the request counter is safely reset to zero and the window reset timestamp is updated in a synchronous code block, then the real-time system load is obtained, and the window size and the maximum number of requests allowed in the window are dynamically adjusted based on the load, thereby realizing a sliding window flow control mechanism that can adapt to changes in system state.

[0078] In another specific embodiment, the flow control process is implemented as follows: after passing the time window check, the filter first increments the request counter of the current window. Then, the flow is judged: if the current count value has exceeded the maximum request limit threshold of the window, the request is immediately intercepted and a "429 Too Many Requests" status code is returned; if it is not over the limit, the request is normally released. At the same time, the system obtains the current CPU load (value range 0.0 to 1.0) as the core indicator, and based on this, the adjustment strategy is executed: when the load is below 0.3, the window size is set to 5 seconds and the maximum number of requests is increased to 500; when the load is between 0.3 and 0.7, a moderate 3-second window and a request limit of 300 are used; and when the load reaches 0.7 or above, a strict protection strategy is adopted, the window is shrunk to 1 second and the number of requests is limited to 100, thereby dynamically adjusting the flow control strength according to the real-time load of the system.

[0079] By sending an explicit error response to the client, informing it that its request is rejected due to system throttling. For example, returning an HTTP 429 status code in a web application and including detailed error information in the response body, such as "current request is too frequent, please try later", this way is simple and direct, can quickly reduce system load, but may affect user experience. The information of the rejected request is recorded in the log file, including the time of the request, the source IP, the requested interface or function, etc. These logs are helpful for subsequent analysis of the system's traffic patterns, identification of potential malicious attacks or abnormal behaviors, and provide data support for system optimization. For example, by analyzing the logs, it is found that a certain IP address frequently sends a large number of requests, which may be malicious crawlers or attack behavior, further protection measures can be taken.

[0080] On the other hand, by putting the requests that exceed the limit into a queue and waiting for processing in a certain order (such as first-in-first-out), the queue can be set in memory or use external storage system to ensure the reliability and scalability of the system. For example, in a high-concurrency e-commerce system, when the order processing request exceeds the system processing capacity, the request can be put into the queue and processed in turn when the system resources are idle. In order to avoid the queue being too long and causing the system memory to be exhausted or the request waiting time to be too long, the maximum length of the queue needs to be set, when the queue is full, the newly arrived request can be rejected or other degradation strategies can be used. At the same time, a timeout time is set for each queued request, if it is not processed within the specified time, the request will be automatically discarded and a timeout error information will be returned to the client.

[0081] In a specific embodiment, the control method further comprises: if the number of requests in the continuous multiple window periods exceeds the maximum number, triggering a fuse mechanism to stop receiving new API requests.

[0082] In this embodiment, by recording the request timestamp and determining the corresponding time window, the number of requests in each time window is accurately counted. When the number of requests exceeds the maximum number of allowed requests, timely measures such as rejecting requests or queuing are taken to avoid the system running out of resources due to receiving too many requests in a short period of time, and thus causing system crash or unavailability. For example, during the e-commerce promotion activities, a large number of users simultaneously initiate requests, and this throttling method can effectively control the request flow into the system, ensuring that the system can still run stably in high-concurrency scenarios. The design of dynamic time window makes the throttling not simply based on fixed time point judgment, but considers the request distribution in a period of time. This helps to smooth the sudden traffic impact and avoid the sharp decline of system performance caused by instantaneous traffic peak, thereby ensuring the stability of the system.

[0083] In an embodiment, Figure 2This is a detailed flowchart of an API request traffic control method according to an embodiment of the present invention. This embodiment is further optimized and extended based on the above embodiments.

[0084] Upon receiving a request, determine if the current window has expired. If so, calculate the new window size, create a new time window, perform load monitoring, and update the load factor. If not, increment the request count by 1 and check if the count exceeds a threshold. If so, reject the request; otherwise, allow the request.

[0085] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0086] The beneficial effects of this invention are mainly reflected in the following aspects:

[0087] 1. Smooth Traffic Flow: The elastic window algorithm dynamically adjusts the traffic control strategy based on the real-time load, which can effectively avoid the impact of sudden traffic on the system and achieve smooth traffic distribution.

[0088] 2. Improve system stability: By intelligently adjusting the size of the time window, the overload problem caused by the fixed time window is avoided, ensuring the stability of the backend service.

[0089] 3. Optimize high-concurrency performance: The elastic window can be flexibly adjusted according to the load, effectively handling high-concurrency requests and avoiding performance bottlenecks.

[0090] 4. Simple and easy to use: This method is implemented through an extension module of Spring Cloud Gateway, without requiring modification of the backend service, and supports flexible configuration and dynamic adjustment, making it highly applicable.

[0091] like Figure 3 As shown, the following are embodiments of the API request traffic control system provided in this disclosure. The API request traffic control methods described above belong to the same inventive concept. For details not described in detail in the embodiments of the API request traffic control system, please refer to the embodiments of the API request traffic control methods described above.

[0092] The control system for API request traffic includes:

[0093] The request counter is used to count the number of API requests received in the current window.

[0094] A load detection mechanism is used to monitor system load in real time and obtain system load status and traffic saturation within a time window;

[0095] The flow control module is configured to check whether the number of requests passed in the time window exceeds the maximum number of requests allowed in the current time window; if not, the API request is allowed to continue, the number of requests passed in the time window is updated, the system load condition and the time window traffic saturation degree are obtained, and the maximum number of requests in the subsequent time window is adjusted based on the system load condition and the time window traffic saturation degree by using a window calculation model; if yes, the API request is rejected and a flow control error message is returned, a rejection log is recorded, or the API request is added to a waiting queue, and a maximum length of the waiting queue and a request timeout threshold are set, and the API request is discarded when the queue is full or the request is not processed within the timeout threshold.

[0096] The system dynamically adjusts the flow control strategy through real-time monitoring of the API request. Through the load detection mechanism, when the request amount is low, the window size is automatically increased to allow more requests to pass; when the request amount is high, the window size is automatically reduced to reduce the number of concurrent requests, thereby avoiding overload of the backend service.

[0097] Figure 4 FIG. 1 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present application.

[0098] The API request flow control method provided by the embodiments of the present application can be applied to an electronic device. Those skilled in the art can understand that the electronic device structure involved in the embodiments of the present application does not constitute a limitation on the electronic device, and the electronic device can include more or fewer components than the diagram, or combine certain components, or different component arrangements. In the embodiments of the present application, the electronic device includes but is not limited to a laptop computer, a desktop computer, a workstation, a personal digital assistant, a server, a blade server, a mainframe computer, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as a personal digital processor, a cellular phone, a smart phone, a wearable device, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of the present application described herein and / or claimed.

[0099] The electronic device can include a processor, an external memory interface, an internal memory, a universal serial bus (USB) interface, a charge management module, a power management module, a battery, a wireless communication module, an audio module, a speaker, a microphone, a sensor module, a key, a camera, a display screen, and a SIM card interface, etc.

[0100] It can be understood that the structure shown in the embodiments of the present application does not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device can include more or fewer components than shown, or combine certain components, or split certain components, or different arrangement of components. The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0101] The processor can include one or more processing units, such as: the processor can include a central processing unit (CPU), an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units can be independent devices, or can be integrated in one or more processors.

[0102] Among them, the processor can be the nerve center and command center of the electronic device. The controller can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching and executing instructions.

[0103] The memory can also be provided in the processor for storing instructions and data. In some embodiments, the memory in the processor is a cache memory. The memory can save instructions or data that the processor has just used or repeatedly uses. If the processor needs to use the instructions or data again, it can directly call from the memory. Avoiding repeated access, reducing the waiting time of the processor, thus improving the efficiency of the system.

[0104] The external memory interface can be used to connect an external storage card, such as a MicroSD card, to realize the expansion of the storage capacity of the electronic device. The external storage card communicates with the processor through the external memory interface to realize the data storage function. For example, files such as music and video are saved in the external storage card.

[0105] The internal memory can be used to store computer executable program code including instructions. The processor performs various function applications and data processing of the electronic device by running the instructions stored in the internal memory. The internal memory can include a program area and a data area. The internal memory can include a high-speed random access memory, and can further include a non-volatile memory such as at least one disk storage device, a flash storage device, a universal flash storage (UFS), etc.

[0106] The wireless communication function of the electronic device can be implemented through an antenna, a wireless communication module, a modem processor, and a baseband processor, etc.

[0107] The wireless communication module can provide a wireless communication solution including wireless local area networks (WLAN) (such as a wireless fidelity (Wi-Fi) network), Bluetooth (BT), a global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc. applied to the electronic device.

[0108] The electronic device can implement an audio function, etc. through an audio module, a speaker, a receiver, a microphone, an earphone interface, and an application processor, etc.

[0109] The electronic device can implement a photographing function through an ISP, a camera, a video codec, a GPU, a display screen, and an application processor, etc.

[0110] The electronic device can implement a display function through a GPU, a display screen, and an application processor, etc.

[0111] The GPU is a microprocessor for image processing, connected to the display screen and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor can include one or more GPUs that execute program instructions to generate or change display information.

[0112] The display screen is used to display images, videos, etc. The display screen includes a display panel.

[0113] In the storage medium provided in the present application, a program product capable of implementing the API request flow control method is stored.

[0114] The API request flow control method comprises: receiving an API request entering a gateway, and recording a timestamp of the API request; determining a time window to which the API request belongs according to the timestamp of the API request, and checking whether the number of requests that have passed in the time window exceeds the maximum number of requests allowed in the current time window; if not, allowing the API request to continue, updating the number of requests that have passed in the time window, obtaining a system load condition and a time window traffic saturation degree, and adjusting the maximum number of requests of a subsequent time window based on the system load condition and the time window traffic saturation degree by using a window calculation model; if yes, rejecting the API request and returning a flow limiting error message, recording a rejection log, or adding the API request to a waiting queue, setting an upper limit of the length of the waiting queue and a request timeout threshold, and discarding the API request when the queue is full or the request times out.

[0115] In some possible implementation manners, the API request flow control method and system of the subject name of the present disclosure can be implemented in the form of a program product, which includes program codes for causing terminal equipment to perform the steps described in the above “Exemplary Method” section of the present specification according to various exemplary embodiments of the present disclosure when the program product is run on the terminal equipment.

[0116] The storage medium of the present disclosure can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, be but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0117] The above description of disclosed embodiments enables one of ordinary skill in the art to make or use the application. Various modifications to these embodiments will be apparent to those of ordinary skill in the art, and the generic principles defined herein can be applied to other embodiments without departing from the spirit or scope of the application. Therefore, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for controlling API request traffic, characterized in that, include: Receive API requests entering the gateway and record the timestamp of the API request; The time window to which the API request belongs is determined based on the timestamp of the request, and the number of requests that have been approved within the time window is checked to see if it exceeds the maximum number of requests allowed in the current time window. If the limit is not exceeded, the API request is allowed to continue, the number of requests that have been approved within the time window is updated, the system load and time window traffic saturation are obtained, and the maximum number of requests in subsequent time windows is adjusted based on the system load and time window traffic saturation using the window calculation model. If the limit is exceeded, the API request will be rejected and a rate limiting error message will be returned. The rejection log will be recorded. Alternatively, the API request will be added to the waiting queue, and the upper limit of the waiting queue length and the request timeout threshold will be set. When the queue is full or the request times out and is not processed, the API request will be discarded. The adjustment of the maximum number of requests in subsequent time windows based on system load includes: Under low load conditions, increase the maximum number of requests within the time window, where the low load condition is defined as the system load factor being lower than a preset load threshold. Under high load conditions, reduce the maximum number of requests within the time window, where the high load condition is defined as the system load factor being higher than a preset load threshold. The load factor is calculated according to the following formula: F = min(σ, L × 1.5) In the formula, F represents the system load factor, L represents the system load, and σ represents the preset load threshold. The window calculation model adjusts the maximum number of requests in subsequent time windows based on system load and time window traffic saturation, including obtaining the target time window according to the following formula: In the formula, W represents the target window. S represents the window baseline value, S represents the time window traffic saturation, and F represents the system load factor. The flow saturation within the time window is calculated using the following formula: In the formula, S represents the flow saturation level within the time window. This represents the system's current query rate per second. This represents the maximum query rate per second that the system can handle.

2. The API request traffic control method according to claim 1, characterized in that, Before determining the time window to which an API request belongs based on its timestamp and checking whether the number of requests that have been approved within that time window exceeds the maximum number of requests allowed in the current time window, the control method further includes: Define a Gateway filter to intercept every API request entering the gateway; Use an AtomicInteger counter to count the number of API requests within the current time window, and determine whether the API request has entered a new time window. If so, reset the request count and update the window reset time.

3. The API request traffic control method according to claim 1, characterized in that, The control method further includes: If the number of requests exceeds the maximum limit within multiple consecutive window periods, the circuit breaker mechanism is triggered, and new API requests are stopped being accepted.

4. A control system for API request traffic applied to the API request traffic control method according to any one of claims 1-3, characterized in that, include: The request counter is used to count the number of API requests received in the current window. A load detection mechanism is used to monitor system load in real time and obtain system load status and traffic saturation within a time window; The flow control module checks whether the number of requests that have passed within the current time window exceeds the maximum number of requests allowed in the current time window. If it does not exceed the limit, the API request is allowed to continue, the number of requests that have passed within the current time window is updated, and the system load and time window flow saturation are obtained. The maximum number of requests in subsequent time windows is adjusted based on the system load and time window flow saturation using the window calculation model. If the limit is exceeded, the API request will be rejected and a rate limiting error message will be returned. The rejection log will be logged. Alternatively, the API request will be added to a waiting queue with a maximum waiting queue length and a request timeout threshold. The API request will be discarded when the queue is full or the request times out.

5. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the API request traffic control method as described in any one of claims 1-3.

6. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the API request traffic control method as described in any one of claims 1-3.

Images