Request traffic control method and device, computer device and readable storage medium

Abstract

This application discloses a method, apparatus, computer device, and readable storage medium for controlling request traffic, relating to the fields of digital healthcare and internet technology. It involves delaying the transmission of requests for different durations based on the scenario to avoid simultaneous transmission and prevent requests from being dropped. The method includes: responding to a first business request to be processed, querying the first business scenario in which the user initiated the first business request; when a traffic control requirement is detected in the first business scenario, obtaining a first control ratio corresponding to the first business scenario; querying the first average transmission time of the business request initiated in the first business scenario, and selecting a random number as a first delay duration using the first control ratio and the first average transmission time; determining the request initiation time of the first business request, and when it is detected that the time interval between the current time and the request occurrence time is equal to the first delay duration, sending the first business request to a first server providing services for the first business scenario.

Description

Technical Field

[0001] This application relates to the fields of digital healthcare and internet technology, and in particular to a method, apparatus, computer device, and readable storage medium for controlling request traffic. Background Technology

[0002] With the continuous development of internet technology, the number of internet users is increasing, and internet-based applications are constantly emerging, making people's lives more convenient and efficient. In recent years, the rise of digital healthcare technology has led to a proliferation of applications supporting functions such as disease-aided diagnosis, health management, and remote consultations. However, internet server capacity is limited. Sometimes, when applications provide physical examinations, online medical consultations, or trending medical news, a large number of users access the application simultaneously, causing server overload, server crashes, and internet outages. Therefore, in scenarios where short-term high concurrency requests may occur, applications implement request traffic control to prevent the normal operation of the application from being overwhelmed by instantaneous traffic spikes, ensuring high availability.

[0003] In related technologies, some applications employ traffic control middleware such as Sentinel (a traffic control plugin). This middleware discards requests exceeding traffic thresholds to reduce server load. However, the applicant recognizes that this method of request traffic control leads to user access failures due to dropped requests, and the probability of request droppage is high in high-concurrency scenarios, impacting normal user experience. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, computer device, and readable storage medium for controlling request traffic. The main purpose is to solve the problem that user access failures are caused by requests being dropped, and the probability of requests being dropped is very high in high-concurrency scenarios, which affects the normal use of the user.

[0005] According to a first aspect of this application, a method for controlling request traffic is provided, the method comprising:

[0006] In response to the first business request to be processed, query the first business scenario in which the user initiated the first business request;

[0007] When a traffic control requirement is detected in the first business scenario, the first control ratio corresponding to the first business scenario is obtained;

[0008] Query the first average time consumption corresponding to the first business scenario, and select a random number as the first delay duration using the first control ratio and the first average time consumption. The first average time consumption is the average time consumed when transmitting business requests initiated in the first business scenario.

[0009] The request initiation time of the first service request is determined. When the time interval between the current time and the time when the request occurred is equal to the first delay duration, the first service request is sent to the first server that provides services for the first service scenario, so that the first server can process the first service request.

[0010] Optionally, before querying the first business scenario in which the user initiated the first business request in response to the first business request to be processed, the method further includes:

[0011] When it is detected that the user initiates a service request based on the terminal he holds, it is queried whether there is a service request in progress on the terminal. The service request in progress is a service request that has been sent to the first server and has not received a processing result returned by the first server.

[0012] If the query determines that the terminal has an ongoing service request, then the service request initiated by the user this time will be put on hold, and the current process will end.

[0013] If the query determines that there is no ongoing service request on the terminal, then the service request initiated by the user this time will be treated as the first service request to be processed.

[0014] Optionally, after responding to the first business request to be processed and querying the first business scenario in which the user initiated the first business request, the method further includes:

[0015] Extract the first scenario identifier of the first business scenario, generate a query request carrying the first scenario identifier, and call the data transmission interface between the first server and the first server to transmit the query request to the first server;

[0016] Receive the traffic control parameters of the first business scenario fed back by the first server, collect the current scenario information of the first business scenario, and compare the traffic control parameters with the current scenario information;

[0017] When the comparison determines that the current scenario information matches the traffic control parameters, it is determined that the first business scenario has a traffic control requirement;

[0018] When the comparison determines that the current scenario information does not match the traffic control parameters, it is determined that there is no traffic control requirement for the first service scenario, and the first service request is sent to the first server.

[0019] Optionally, comparing the flow control parameters with the current scene information includes:

[0020] A preset control time point is extracted from the flow control parameters. This preset control time point is compared with the current scene time included in the current scene information. If the preset control time point matches the current scene time, the current scene information is determined to match the flow control parameters. If the preset control time point does not match the current scene time, the current scene information is determined to not match the flow control parameters. And / or,

[0021] A request quantity threshold is extracted from the traffic control parameters. The request quantity threshold is compared with the number of currently occurring requests included in the current scenario information. If the number of currently occurring requests is greater than or equal to the request quantity threshold, the current scenario information is determined to match the traffic control parameters. If the number of currently occurring requests is less than the request quantity threshold, the current scenario information is determined to not match the traffic control parameters.

[0022] Optionally, the step of selecting a random number as the first delay duration using the first control ratio and the first average time consumption includes:

[0023] Determine a preset coefficient and calculate the first difference between the preset coefficient and the first control ratio;

[0024] Calculate the first ratio of the preset coefficient to the first difference, and calculate the first product of the first ratio and the first average time consumed;

[0025] Obtain a preset endpoint value, construct a first value interval using the preset endpoint value and the first product as interval endpoints, and call a random function to take a value in the first value interval to obtain a random number as the first delay duration.

[0026] Optionally, the method further includes:

[0027] When multiple second business requests to be processed are received simultaneously, and each of the multiple second business requests is initiated in a scenario where there is a traffic control requirement, for each second business request, query the second business scenario in which the user initiated the second business request.

[0028] Obtain the second control ratio and scenario weight value corresponding to the second business scenario, and query the second average time consumption corresponding to the second business scenario. The second average time consumption is the average time consumed when transmitting business requests initiated in the second business scenario.

[0029] Using the second control ratio, the second average time consumption, and the scenario weight value, a random number is selected as the second delay duration of the second service request;

[0030] The request initiation time of the second service request is determined. When the time interval between the current time and the request initiation time is detected to be equal to the second delay duration, the second service request is sent to the second server that provides services for the second service scenario, so that the second server can process the second service request.

[0031] Optionally, the step of selecting a random number as the second delay duration of the second service request using the second control ratio, the second average time consumption, and the scenario weight value includes:

[0032] Determine a preset coefficient, and calculate the second difference between the preset coefficient and the second control ratio;

[0033] Calculate the second ratio of the preset coefficient to the second difference, and calculate the second product of the second ratio and the second average time consumption;

[0034] Calculate the sum of the second product and the scene weight value, use the scene weight value and the sum as interval endpoints to form a second value interval, and call a random function to take a value in the second value interval to obtain a random number as the second delay duration.

[0035] According to a second aspect of this application, a request flow control device is provided, the device comprising:

[0036] The query module is used to respond to the first business request to be processed and query the first business scenario in which the user initiated the first business request.

[0037] The acquisition module is used to acquire the first control ratio corresponding to the first business scenario when it is detected that there is a traffic control requirement in the first business scenario;

[0038] The selection module is used to query the first average time consumption corresponding to the first business scenario, and select a random number as the first delay duration using the first control ratio and the first average time consumption. The first average time consumption is the average time consumed when transmitting business requests initiated in the first business scenario.

[0039] The sending module is used to determine the request initiation time of the first service request, and when it detects that the time interval between the current time and the time when the request occurred is equal to the first delay duration, it sends the first service request to the first server that provides services for the first service scenario, so that the first server can process the first service request.

[0040] Optionally, the query module is further configured to, when detecting that the user has initiated a service request based on their terminal, query whether the terminal has an ongoing service request, wherein the ongoing service request is a service request that has been sent to the first server and has not received a processing result returned by the first server; if the query determines that the terminal has an ongoing service request, then the service request initiated by the user this time is put on hold and the current process ends; if the query determines that the terminal does not have an ongoing service request, then the service request initiated by the user this time is treated as the first service request to be processed.

[0041] Optionally, the acquisition module is further configured to: extract a first scenario identifier of the first business scenario; generate a query request carrying the first scenario identifier; and call the data transmission interface between the first server and the first server to transmit the query request to the first server; receive traffic control parameters of the first business scenario fed back by the first server; collect current scenario information of the first business scenario; and compare the traffic control parameters with the current scenario information; when the comparison determines that the current scenario information matches the traffic control parameters, determine that the first business scenario has a traffic control requirement; when the comparison determines that the current scenario information does not match the traffic control parameters, determine that the first business scenario does not have a traffic control requirement, and send the first business request to the first server.

[0042] Optionally, the acquisition module is further configured to extract a preset control time point from the traffic control parameters, compare the preset control time point with the current scene time included in the current scene information, wherein if the preset control time point is consistent with the current scene time, the current scene information is determined to match the traffic control parameters; if the preset control time point is inconsistent with the current scene time, the current scene information is determined to not match the traffic control parameters; and / or, extract a request quantity threshold from the traffic control parameters, compare the request quantity threshold with the number of currently occurring requests included in the current scene information, wherein if the number of currently occurring requests is greater than or equal to the request quantity threshold, the current scene information is determined to match the traffic control parameters; if the number of currently occurring requests is less than the request quantity threshold, the current scene information is determined to not match the traffic control parameters.

[0043] Optionally, the selection module is used to determine a preset coefficient, calculate a first difference between the preset coefficient and the first control ratio; calculate a first ratio between the preset coefficient and the first difference, and calculate a first product of the first ratio and the first average consumption time; obtain a preset endpoint value, construct a first value interval using the preset endpoint value and the first product as interval endpoints, and call a random function to select a value in the first value interval to obtain a random number as the first delay duration.

[0044] Optionally, the query module is further configured to, when multiple second business requests to be processed are received simultaneously and each of the multiple second business requests is initiated in a scenario where there is a flow control requirement, query the second business scenario in which the user initiated the second business request for each second business request.

[0045] The acquisition module is also used to acquire the second control ratio and scenario weight value corresponding to the second business scenario;

[0046] The selection module is also used to query the second average time consumption corresponding to the second business scenario. The second average time consumption is the average time consumed when transmitting business requests initiated in the second business scenario.

[0047] The selection module is further configured to use the second control ratio, the second average time consumption and the scenario weight value to select a random number as the second delay duration of the second service request;

[0048] The sending module is further configured to determine the request initiation time of the second service request, and when it detects that the time interval between the current time and the request initiation time is equal to the second delay duration, send the second service request to the second server that provides services for the second service scenario, so that the second server can process the second service request.

[0049] Optionally, the selection module is further configured to determine a preset coefficient, calculate a second difference between the preset coefficient and the second control ratio; calculate a second ratio between the preset coefficient and the second difference, and calculate a second product of the second ratio and the second average consumption time; calculate the sum of the second product and the scene weight value, using the scene weight value and the sum as interval endpoints to form a second value interval, and call a random function to select a value in the second value interval to obtain a random number as the second delay duration.

[0050] According to a third aspect of this application, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any of the first aspects above.

[0051] According to a fourth aspect of this application, a readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0052] By employing the above technical solutions, this application provides a method, apparatus, computer device, and readable storage medium for controlling request traffic. In response to a first service request to be processed, this application queries the first service scenario in which the user initiates the first service request. When a traffic control requirement is detected in the first service scenario, it obtains the first control ratio corresponding to the first service scenario, queries the first average time spent transmitting service requests corresponding to the first service scenario, selects a random number as the first delay duration using the first control ratio and the first average time spent, and determines the request initiation time of the first service request. When it is detected that the time interval between the current time and the request occurrence time is equal to the first delay duration, the first service request is sent to the first server providing services for the first service scenario, so that the first server can process the first service request. This allows for different delay durations based on the specific scenario, avoiding the simultaneous sending of a large number of requests and significantly reducing the number of concurrent requests. While achieving the purpose of traffic control, it also prevents user requests from being dropped, reduces the risk of user access failure, and ensures normal user access.

[0053] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0054] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0055] Figure 1 This illustration shows a flowchart of a request traffic control method provided in an embodiment of this application;

[0056] Figure 2A This paper illustrates a flowchart of another request traffic control method provided in an embodiment of this application.

[0057] Figure 2B This illustration shows a flowchart of a request traffic control method provided in an embodiment of this application;

[0058] Figure 3 This paper shows a schematic diagram of the structure of a request traffic control device according to an embodiment of the present application;

[0059] Figure 4 A schematic diagram of the device structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0060] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0061] This application provides a method for controlling request traffic, such as... Figure 1 As shown, the method includes:

[0062] 101. In response to the first business request to be processed, query the first business scenario in which the user initiated the first business request.

[0063] Many applications currently employ traffic control mechanisms. The principle behind traffic control is to monitor metrics such as the application's queries per second (QPS) or concurrent threads. When these metrics reach specified thresholds, traffic is controlled to prevent the application from being overwhelmed by sudden traffic spikes, thus ensuring high availability. Many applications implement traffic control through middleware, which is used by the server and discards requests exceeding the limit. However, the applicant recognizes that in short-term, high-concurrency scenarios such as flash sales or daily check-ins, server capacity is generally not temporarily expanded. Directly discarding requests exceeding the threshold based on middleware during traffic control can easily lead to user access failures and disrupt normal user experience.

[0064] Therefore, this application proposes a method for controlling request traffic. When traffic control is required, the delay duration of the business request is determined according to the control ratio corresponding to the scenario initiating the business request. The business request is then sent with a delay according to the delay duration, which enables different delay durations to be sent according to specific scenarios. This avoids sending a large number of requests at the same time, greatly reducing the number of concurrent requests. While achieving the purpose of traffic control, it can also prevent user requests from being dropped, reduce the risk of user access failure, and ensure normal user use.

[0065] To determine the specific delay time based on the actual situation of the scenario, this application embodiment, in response to the first business request to be processed, queries the first business scenario in which the user initiated the first business request. For example, if the first business request to be processed is an "online consultation request," then it can be determined that the user initiated the first business request in the "online consultation" business scenario. The technical solution in this application can be executed by an application program. The application program provides a front-end application to the user, who can download the front-end application on their terminal to use the services provided by the application. The application program is backed up by a server, which can be an independent server or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms, enabling the application to provide users with browsing, querying, and purchasing services. It should be noted that the application program can be an application providing purchasing services for various physical or virtual goods, or an application providing communication and interaction services between users. This application does not limit the specific type and function of the application program. Specifically, the application can be a medical service application through which users can browse medical data, electronic medical records, health check packages, etc. Specifically, medical data can be data such as personal health records, prescription information, and examination reports; electronic medical records are electronic healthcare records, which can include a series of electronic personal health records with archival value, such as medical records, electrocardiograms, and medical images; health check packages can be health check items or combinations of health check items that can be purchased by the application.

[0066] 102. When a traffic control requirement is detected in the first business scenario, obtain the first control ratio corresponding to the first business scenario.

[0067] In this embodiment, since traffic control is only required when there is a risk of high concurrency, the application detects whether a traffic control requirement exists in the first business scenario. Specifically, it determines whether a traffic control requirement exists by referring to the current time and the number of requests currently occurring in the first business scenario. Accordingly, when a traffic control requirement is detected in the first business scenario, it indicates that the transmission of the first business request needs to be delayed. Therefore, the application obtains the first control ratio corresponding to the first business scenario and determines the specific delay duration according to the first control ratio. The control ratio indicates how much traffic in the business scenario needs to be limited, and each business scenario can have its control ratio preset, such as 50%, 60%, etc.

[0068] 103. Query the first average time consumption corresponding to the first business scenario, and select a random number as the first delay duration using the first control ratio and the first average time consumption.

[0069] Considering that sending requests to a server under heavy load actually takes a long time, a significant delay is needed to prevent further load accumulation. Therefore, in this embodiment, when determining the delay duration, the application also queries the first average latency corresponding to the first business scenario. The first average latency is the average transmission time of business requests initiated in the first business scenario. Then, using the first control ratio and the first average latency, a random number is selected as the first delay duration. This ensures that the actual time spent sending the request is also considered in the delay duration calculation process, comprehensively considering multiple parameters to determine the delay duration and further guaranteeing its reasonableness.

[0070] 104. Determine the request initiation time of the first business request. When it is detected that the time interval between the current time and the request occurrence time is equal to the first delay duration, send the first business request to the first server that provides services for the first business scenario, so that the first server can process the first business request.

[0071] In this embodiment, after determining the first delay duration, the application determines the request initiation time of the first service request. When it detects that the time interval between the current time and the request occurrence time is equal to the first delay duration, it sends the first service request to the first server providing services for the first service scenario, so that the first server can process the first service request. That is, the first service request is sent with a delay according to the first delay duration, distributing the service requests, avoiding simultaneous sending, and reducing concurrency.

[0072] The method provided in this application embodiment, in response to a first service request to be processed, queries the first service scenario in which the user initiates the first service request. When a flow control requirement is detected in the first service scenario, a first control ratio corresponding to the first service scenario is obtained, and a first average time consumption for transmitting service requests corresponding to the first service scenario is queried. Using the first control ratio and the first average time consumption, a random number is selected as a first delay duration, and the request initiation time of the first service request is determined. When it is detected that the time interval between the current time point and the request occurrence time point is equal to the first delay duration, the first service request is sent to a first server providing services for the first service scenario, so that the first server can process the first service request. It can perform different delays according to the specific scenario, avoid sending a large number of requests at the same time, greatly reduce the number of concurrent requests, achieve the purpose of flow control, and also prevent user requests from being dropped, reduce the risk of user access failure, and ensure normal user use.

[0073] Furthermore, as a refinement and extension of the specific implementation methods of the above embodiments, and in order to fully illustrate the specific implementation process of this embodiment, this application provides another method for controlling request traffic, such as... Figure 2A As shown, the method includes:

[0074] 201. When a user initiates a service request based on their terminal, query whether the terminal has an ongoing service request. If the query determines that the terminal has an ongoing service request, proceed to step 202 below; if the query determines that the terminal does not have an ongoing service request, proceed to steps 203 to 206 below.

[0075] In this embodiment, considering that some users may initiate the same service request multiple times in a short period of time, and that the previous service request has not been processed before the same service request is initiated again, resulting in a large amount of resource consumption, the application checks whether there is an ongoing service request on the terminal when it detects that a user has initiated a service request based on their terminal. An ongoing service request is a service request that has been sent to the first server and for which no processing result has been received. The first server is the server that provides services for the service request.

[0076] Accordingly, if the query determines that the terminal has an ongoing service request, it means that the user's previous service request has not been completed and the processing result has not been received. Therefore, the current service request cannot be processed temporarily. Thus, step 202 is executed. If the query determines that the terminal does not have an ongoing service request, the current service request can be sent to the first server for processing. Before sending, it is necessary to determine whether there is a flow control requirement. Thus, steps 203 to 206 are executed.

[0077] 202. If the query determines that there is an ongoing business request on the terminal, then the business request initiated by the user will be put on hold, and the current process will end.

[0078] In this embodiment of the application, if the query determines that there is an ongoing business request on the terminal, it means that the user's previous business request has not been completed and the processing result has not been received. Therefore, the current business request cannot be processed temporarily. Thus, the current business request initiated by the user is put on hold, and the current process ends.

[0079] 203. If the query determines that there is no ongoing business request on the terminal, then the business request initiated by the user this time will be regarded as the first business request to be processed.

[0080] In this embodiment of the application, if the query determines that there is no ongoing service request on the terminal, the current service request can be sent to the first server for processing. Before sending, it is necessary to determine whether there is a need for traffic control. Therefore, the service request initiated by the user is regarded as the first service request to be processed. Subsequently, the evaluation of whether there is a need for traffic control is performed first, and then the first service request is sent.

[0081] 204. In response to the first business request to be processed, query the first business scenario in which the user initiated the first business request.

[0082] To determine the specific delay time based on the actual situation of the scenario, this application embodiment, in response to the first business request to be processed, queries the first business scenario in which the user initiated the first business request. For example, if the first business request to be processed is an "online consultation request," then it can be determined that the user initiated the first business request in the "online consultation" business scenario. The technical solution in this application can be executed by an application program. The application program provides a front-end application to the user, who can download the front-end application on their terminal to use the services provided by the application program. The application program is backed up by a server, which can be an independent server or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms. It should be noted that the application program can be an application providing various physical or virtual goods purchase services, or an application providing communication and interaction services between users. This application does not limit the specific type and function of the application program.

[0083] 205. Extract the first scenario identifier of the first business scenario, generate a query request carrying the first scenario identifier, call the data transmission interface between the first server and the first server, and transmit the query request to the first server.

[0084] In this embodiment of the application, after determining the first business scenario, the application extracts the first scenario identifier of the first business scenario, generates a query request carrying the first scenario identifier, and calls the data transmission interface between the application and the first server to transmit the query request to the first server so that the first server can provide the traffic control parameters of the first business scenario.

[0085] The traffic control parameters specify how to perform rate limiting for the first business scenario. Each business scenario can be associated with a traffic control parameter, meaning that a scenario identifier is used to label the traffic control parameters, allowing the traffic control parameters associated with the corresponding business scenario to be queried through the scenario identifier. Specifically, the scenario identifier can be the scenario code of the business scenario; the traffic control parameters can include a preset control time point and a request quantity threshold. The preset control time point indicates the specific rate limiting time of the business scenario, for example, it can be 10:00 AM, so when the current time is 10:00 AM, it can be determined that the business scenario has a traffic control requirement; the request quantity threshold indicates the maximum number of business requests in the business scenario, for example, it can be 3000, so when the number of business requests currently initiated by the business scenario exceeds 3000, it can be determined that the business scenario has a traffic control requirement.

[0086] 206. Receive the traffic control parameters of the first business scenario from the first server, collect the current scenario information of the first business scenario, and compare the traffic control parameters with the current scenario information. When the comparison determines that the current scenario information matches the traffic control parameters, execute steps 207 to 209 below; when the comparison determines that the current scenario information does not match the traffic control parameters, execute step 210 below.

[0087] In this embodiment, after the first server queries the traffic control parameters associated with the first business scenario, it feeds the traffic control parameters back to the application. The application receives the traffic control parameters of the first business scenario from the first server, collects the current scenario information of the first business scenario, and compares the traffic control parameters with the current scenario information to determine whether the first business scenario requires traffic control. Since the traffic control parameters may specifically include preset control time points and request quantity thresholds, the application needs to use different methods to evaluate the traffic control requirements, as follows:

[0088] One approach is to extract a preset control time point from the flow control parameters. The application then compares this preset control time point with the current scene time included in the current scene information. Accordingly, when the preset control time point matches the current scene time, it can be determined that the current scene information matches the flow control parameters, meaning there is a flow control requirement. Conversely, when the preset control time point does not match the current scene time, it can be determined that the current scene information does not match the flow control parameters, meaning there is no flow control requirement. For example, assuming the preset control time point is 10:00 AM, if the current scene time included in the current scene information is 10:00 AM, it can be determined that the current scene information matches the flow control parameters, indicating a flow control requirement. However, if the current scene time included in the current scene information is 8:00 AM, it can be determined that the current scene information does not match the flow control parameters, indicating no flow control requirement. It should be noted that, considering some business scenarios require proactive measures to prevent potential high concurrency requests and avoid server downtime due to sudden traffic surges, in practical applications, a pre-control duration can be set in the traffic control parameters. Traffic control begins at a time point before the preset control time, where the time interval between the preset control time and the preset control time equals the pre-control duration, allowing for early risk prevention. For example, assuming the pre-control duration is 10 minutes and the preset control time is 10:00 AM, if the current scenario information includes a current time of 9:50 AM, it is determined that the current scenario information matches the traffic control parameters, indicating a traffic control requirement.

[0089] Another approach is to extract a request count threshold from the traffic control parameters and compare this threshold with the number of currently occurring requests included in the current scenario information. Accordingly, if the number of currently occurring requests is greater than or equal to the request count threshold, it is determined that the current scenario information matches the traffic control parameters, meaning there is a traffic control requirement; if the number of currently occurring requests is less than the request count threshold, it is determined that the current scenario information does not match the traffic control parameters, meaning there is no traffic control requirement. For example, assuming the request count threshold is 3000, if the number of currently occurring requests included in the current scenario information is 4000, it is determined that the current scenario information matches the traffic control parameters, meaning there is a traffic control requirement; while if the number of currently occurring requests included in the current scenario information is 2000, it is determined that the current scenario information does not match the traffic control parameters, meaning there is no traffic control requirement.

[0090] It should be noted that in practical applications, if the traffic control parameters include both a preset control time point and a request quantity threshold, then the existence of a traffic control requirement is determined when the current scenario information matches both the preset control time point and the request quantity threshold. However, if the traffic control parameters only include one of these, then the method corresponding to that parameter can be used for evaluation. This application does not specifically limit whether the traffic control parameters include both the preset control time point and the request quantity threshold.

[0091] Accordingly, when the comparison determines that the current scenario information matches the traffic control parameters, it is determined that there is a traffic control requirement. Therefore, steps 207 to 209 are executed to control the requested traffic. When the comparison determines that the current scenario information does not match the traffic control parameters, it is determined that there is no traffic control requirement. The first service request can be sent directly, i.e., step 210 is executed.

[0092] 207. When the comparison determines that the current scenario information matches the flow control parameters, it is determined that there is a flow control requirement in the first business scenario, and the first control ratio corresponding to the first business scenario is obtained.

[0093] In this embodiment, when the comparison determines that the current scenario information matches the traffic control parameters, it is determined that the first service scenario has a traffic control requirement. Therefore, the application obtains the first control ratio corresponding to the first service scenario and determines the specific delay duration for transmission according to the first control ratio. The control ratio indicates how much traffic in the service scenario needs to be limited. Each service scenario can have its control ratio preset, such as 50%, 60%, etc.

[0094] 208. Query the first average time consumption corresponding to the first business scenario, and select a random number as the first delay duration using the first control ratio and the first average time consumption.

[0095] Considering that sending requests to a server under heavy load actually takes a long time, a significant delay is needed to prevent further load accumulation. Therefore, in this embodiment, when determining the delay duration, the application also queries the first average latency corresponding to the first business scenario. The first average latency is the average transmission time for business requests initiated in the first business scenario. Subsequently, using the first control ratio and the first average latency, a random number is selected as the first delay duration. This ensures that the actual time spent sending the request is also considered in the delay duration calculation process, comprehensively considering multiple parameters to determine the delay duration and further guaranteeing its reasonableness. The specific process of selecting a random number as the first delay duration is as follows:

[0096] First, the application determines a preset coefficient and calculates the first difference between the preset coefficient and the first control ratio. Then, the application calculates the first ratio between the preset coefficient and the first difference, and calculates the first product of the first ratio and the first average time. Finally, it obtains a preset endpoint value, constructs a first value interval using the preset endpoint value and the first product as interval endpoints, and calls a random function to select a value within the first value interval, obtaining a random number as the first delay duration. Here, the preset coefficient can be set to 1, and the preset endpoint value can be set to 0. Assuming the first control ratio is 50% and the first average time is 30ms, the application first calculates 1-50%=50%, then calculates 1 / 50%=2, and finally calculates 2×30=60. The random function is then called to select a random number between 0 and 60, for example, 50, and 50ms is used as the first delay duration.

[0097] By selecting a random number to determine the delay duration, business requests for the same business scenario can be sent in a distributed manner. For example, in the example above, since the calculated first product is 60, the overall business requests are roughly distributed into 60 time points for sending, avoiding simultaneous sending of requests, greatly reducing concurrency, and reducing server pressure.

[0098] 209. Determine the request initiation time of the first business request. When it is detected that the time interval between the current time and the request occurrence time is equal to the first delay duration, send the first business request to the first server that provides services for the first business scenario, so that the first server can process the first business request.

[0099] In this embodiment of the application, after determining the first delay duration, the application determines the request initiation time of the first service request. When it detects that the time interval between the current time and the request occurrence time is equal to the first delay duration, it sends the first service request to the first server that provides services for the first service scenario, so that the first server processes the first service request and realizes the delayed sending of the first service request.

[0100] 210. When the comparison determines that the current scenario information does not match the traffic control parameters, it is determined that there is no traffic control requirement for the first business scenario, and the first business request is sent to the first server.

[0101] In this embodiment of the application, when the comparison determines that the current scenario information does not match the traffic control parameters, it is determined that there is no traffic control requirement for the first service scenario, and the first service request can be sent directly, that is, the first service request is sent to the first server.

[0102] The process described in steps 201 to 210 above is a process of delaying the sending of a single business request. However, in actual applications, a large number of users may simultaneously use the application, causing the application to receive multiple pending business requests at the same time. Some business processes within the application are critical; prolonged delays can impact subsequent processes. For example, in payment processing, the bank needs to perform deductions, and delays can hinder the bank's processing. Conversely, in product query processing, simply displaying the desired product to the user allows for a slight delay. Therefore, to ensure that critical business requests are sent promptly and to avoid prolonged delays that could hinder the execution of important business processes, this embodiment of the application can also set a scenario weight value for each business scenario. This scenario weight value is taken into account when calculating the delay duration, thereby preventing long delays from affecting important business processes. The specific process is as follows:

[0103] When multiple pending second service requests are received simultaneously, and each of these requests originates in a scenario with traffic control requirements, the application queries the second service scenario in which the user initiated the request. It then obtains the second control ratio and scenario weight value corresponding to the second service scenario, and queries the second average latency corresponding to the second service scenario. The second average latency is the average transmission time for service requests initiated within the second service scenario. The process of determining whether traffic control requirements exist and obtaining the control ratio is consistent with steps 206 to 207 described above, and will not be repeated here.

[0104] Next, the application uses the second control ratio, the second average latency, and the scene weight value to select a random number as the second delay duration for the second service request. Specifically, when determining the second delay duration, the application determines a preset coefficient, calculates the second difference between the preset coefficient and the second control ratio, calculates the second ratio between the preset coefficient and the second difference, calculates the second product of the second ratio and the second average latency, and calculates the sum of the second product and the scene weight value. Using the scene weight value and the sum as interval endpoints, a second value interval is formed. A random function is then called to select a value within the second value interval to obtain a random number as the second delay duration. The preset coefficient can be set to 1. Assume there are three second business requests, namely A, B, and C. A has the highest priority, with a corresponding scenario weight value of 0, a corresponding second control ratio of 20%, and a corresponding second average time of 10ms. B has the second highest priority, with a corresponding scenario weight value of 100, a corresponding second control ratio of 50%, and a corresponding second average time of 20ms. C has the lowest priority, with a corresponding scenario weight value of 500, a corresponding second control ratio of 75%, and a corresponding second average time of 30ms. When A, B, and C trigger flow control simultaneously, for A, calculate 0 + 10 × (1 / (1-0.2) = 12.5, and use a random function to select a random number between 0 and 12.5 as the second delay duration for A; for B, calculate 100 + 20 × (1 / (1-0.5) = 140, and use a random function to select a random number between 100 and 140 as the second delay duration for B; for C, calculate 500 + 20 × (1 / (1-0.75) = 580, and use a random function to select a random number between 500 and 580 as the second delay duration for C.

[0105] In this way, the request initiation time of the second business request is determined. When it is detected that the time interval between the current time and the request initiation time is equal to the second delay duration, the second business request is sent to the second server providing services for the second business scenario, so that the second server can process the second business request. Through the above process, high-priority businesses are executed first, and low-priority businesses are executed later, avoiding the dropping of requests due to short-term high concurrency, which would affect the user experience.

[0106] In summary, the execution process of the request traffic control method proposed in this application is summarized as follows: Figure 2BAs shown, when a user initiates a service request based on their terminal, the system checks if the terminal has an ongoing service request. If the query determines that the terminal has an ongoing service request, the user's current service request is suspended, and the current process ends. If the query determines that the terminal does not have an ongoing service request, the user's current service request is treated as the first service request to be processed, and it is determined whether the first service scenario in which the user initiated the first service request has a flow control requirement. If the first service scenario does not have a flow control requirement, the first service request is sent directly so that the first server providing services for the first service scenario can process the first service request and provide feedback on the processing result. If the first service scenario has a flow control requirement, a random number is selected as the first delay duration based on the first control ratio and the first average latency of the first service scenario. The sending of the first service request is delayed according to the first delay duration, and at the end of the delay, the first service request is sent to the first server so that the first server can process the first service request and provide feedback on the processing result.

[0107] The method provided in this application embodiment delays the sending of requests for different durations according to specific scenarios, thereby avoiding the simultaneous sending of a large number of requests and greatly reducing the number of concurrent requests. While achieving the purpose of traffic control, it can also prevent user requests from being dropped, reduce the risk of user access failure, and ensure normal user use.

[0108] Furthermore, as Figure 1 To specifically implement the method, this application provides a request traffic control device, such as... Figure 3 As shown, the device includes: a query module 301, an acquisition module 302, a selection module 303, and a sending module 304.

[0109] The query module 301 is used to respond to the first business request to be processed and query the first business scenario in which the user initiated the first business request.

[0110] The acquisition module 302 is used to acquire the first control ratio corresponding to the first business scenario when it is detected that there is a flow control requirement in the first business scenario;

[0111] The selection module 303 is used to query the first average time consumption corresponding to the first business scenario, and select a random number as the first delay duration using the first control ratio and the first average time consumption. The first average time consumption is the average time consumed when transmitting business requests initiated in the first business scenario.

[0112] The sending module 304 is used to determine the request initiation time of the first service request, and when it detects that the time interval between the current time and the time when the request occurred is equal to the first delay duration, it sends the first service request to the first server that provides services for the first service scenario, so that the first server processes the first service request.

[0113] In a specific application scenario, the query module 301 is further configured to, when detecting that the user has initiated a service request based on their terminal, query whether the terminal has an ongoing service request, wherein the ongoing service request is a service request that has been sent to the first server but has not received a processing result returned by the first server; if the query determines that the terminal has an ongoing service request, then the service request initiated by the user this time is put on hold and the current process ends; if the query determines that the terminal does not have an ongoing service request, then the service request initiated by the user this time is treated as the first service request to be processed.

[0114] In a specific application scenario, the acquisition module 302 is further configured to extract the first scenario identifier of the first business scenario, generate a query request carrying the first scenario identifier, and call the data transmission interface between the first server and the first server to transmit the query request to the first server; receive the traffic control parameters of the first business scenario fed back by the first server, collect the current scenario information of the first business scenario, and compare the traffic control parameters with the current scenario information; when the comparison determines that the current scenario information matches the traffic control parameters, it is determined that the first business scenario has a traffic control requirement; when the comparison determines that the current scenario information does not match the traffic control parameters, it is determined that the first business scenario does not have a traffic control requirement, and the first business request is sent to the first server.

[0115] In specific application scenarios, the acquisition module 302 is further configured to extract a preset control time point from the traffic control parameters, compare the preset control time point with the current scene time included in the current scene information, wherein when the preset control time point is consistent with the current scene time, it is determined that the current scene information matches the traffic control parameters; when the preset control time point is inconsistent with the current scene time, it is determined that the current scene information does not match the traffic control parameters; and / or, extract a request quantity threshold from the traffic control parameters, compare the request quantity threshold with the number of currently occurring requests included in the current scene information, wherein when the number of currently occurring requests is greater than or equal to the request quantity threshold, it is determined that the current scene information matches the traffic control parameters; when the number of currently occurring requests is less than the request quantity threshold, it is determined that the current scene information does not match the traffic control parameters.

[0116] In a specific application scenario, the selection module 303 is used to determine a preset coefficient, calculate a first difference between the preset coefficient and the first control ratio; calculate a first ratio between the preset coefficient and the first difference, and calculate a first product of the first ratio and the first average consumption time; obtain a preset endpoint value, construct a first value interval using the preset endpoint value and the first product as interval endpoints, and call a random function to select a value in the first value interval to obtain a random number as the first delay duration.

[0117] In specific application scenarios, the query module 301 is also used to query the second business scenario in which the user initiated the second business request when multiple second business requests to be processed are received at the same time and each of the multiple second business requests is initiated in a scenario where there is a flow control requirement.

[0118] The acquisition module 302 is also used to acquire the second control ratio and scenario weight value corresponding to the second business scenario;

[0119] The selection module 303 is also used to query the second average time consumption corresponding to the second business scenario. The second average time consumption is the average time consumed when transmitting business requests initiated in the second business scenario.

[0120] The selection module 303 is also used to select a random number as the second delay duration of the second service request by using the second control ratio, the second average time consumption and the scenario weight value;

[0121] The sending module 304 is further configured to determine the request initiation time of the second service request, and when it detects that the time interval between the current time and the request initiation time is equal to the second delay duration, send the second service request to the second server that provides services for the second service scenario, so that the second server can process the second service request.

[0122] In a specific application scenario, the selection module 303 is further used to determine a preset coefficient, calculate a second difference between the preset coefficient and the second control ratio; calculate a second ratio between the preset coefficient and the second difference, and calculate a second product between the second ratio and the second average consumption time; calculate the sum of the second product and the scene weight value, and use the scene weight value and the sum value as interval endpoints to form a second value interval, and call a random function to take a value in the second value interval to obtain a random number as the second delay duration.

[0123] The apparatus provided in this application embodiment, in response to a first service request to be processed, queries the first service scenario in which the user initiates the first service request. When a flow control requirement is detected in the first service scenario, it obtains the first control ratio corresponding to the first service scenario, queries the first average time spent transmitting service requests corresponding to the first service scenario, selects a random number as the first delay duration using the first control ratio and the first average time spent, and determines the request initiation time of the first service request. When it is detected that the time interval between the current time and the request occurrence time is equal to the first delay duration, the first service request is sent to the first server providing services for the first service scenario, so that the first server can process the first service request. It can perform different delays according to the specific scenario, avoid sending a large number of requests at the same time, greatly reduce the number of concurrent requests, achieve the purpose of flow control, and also prevent user requests from being dropped, reduce the risk of user access failure, and ensure normal user use.

[0124] It should be noted that other corresponding descriptions of the functional units involved in the request traffic control device provided in this application embodiment can be found in the following references. Figure 1 and Figures 2A to 2B The corresponding descriptions in [the document] will not be repeated here.

[0125] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0126] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0127] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

[0128] In an exemplary embodiment, see Figure 4 The invention also provides a computer device including a bus, a processor, a memory, and a communication interface. It may also include an input / output interface and a display device, wherein the various functional units can communicate with each other via the bus. The memory stores a computer program, and the processor executes the program stored in the memory to perform the request flow control method described in the above embodiments.

[0129] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the request traffic control method.

[0130] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented in hardware or by using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) and includes several instructions to cause a computer device (such as a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0131] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application.

[0132] Those skilled in the art will understand that the modules in the apparatus of the implementation scenario can be distributed within the apparatus of the implementation scenario as described, or they can be located in one or more apparatuses different from this implementation scenario, with corresponding changes. The modules of the above-described implementation scenario can be combined into one module, or they can be further divided into multiple sub-modules.

[0133] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of the implementation scenario.

[0134] The above disclosures are only a few specific implementation scenarios of this application. However, this application is not limited to these. Any variations that can be conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A method for controlling request traffic, characterized in that, include: In response to the first business request to be processed, query the first business scenario in which the user initiated the first business request; When a traffic control requirement is detected in the first business scenario, the first control ratio corresponding to the first business scenario is obtained; The first average latency corresponding to the first business scenario is queried. Using the first control ratio and the first average latency, a random number is selected as the first delay duration. The first average latency is the average transmission time of a business request initiated in the first business scenario. Selecting a random number as the first delay duration using the first control ratio and the first average latency includes: determining a preset coefficient; calculating a first difference between the preset coefficient and the first control ratio; calculating a first ratio between the preset coefficient and the first difference, and calculating a first product of the first ratio and the first average latency; obtaining a preset endpoint value; constructing a first value interval using the preset endpoint value and the first product as interval endpoints; and calling a random function to select a value within the first value interval to obtain a random number as the first delay duration. The request initiation time of the first service request is determined. When the time interval between the current time and the time when the request occurred is equal to the first delay duration, the first service request is sent to the first server that provides services for the first service scenario, so that the first server can process the first service request.

2. The method according to claim 1, characterized in that, Before querying the first business scenario in which the user initiated the first business request in response to the first business request, the method further includes: When it is detected that the user initiates a service request based on the terminal he holds, it is queried whether there is a service request in progress on the terminal. The service request in progress is a service request that has been sent to the first server and has not received a processing result returned by the first server. If the query determines that the terminal has an ongoing service request, then the service request initiated by the user this time will be put on hold, and the current process will end. If the query determines that there is no ongoing service request on the terminal, then the service request initiated by the user this time will be treated as the first service request to be processed.

3. The method according to claim 1, characterized in that, After responding to the first business request to be processed and querying the first business scenario in which the user initiated the first business request, the method further includes: Extract the first scenario identifier of the first business scenario, generate a query request carrying the first scenario identifier, and call the data transmission interface between the first server and the first server to transmit the query request to the first server; Receive the traffic control parameters of the first business scenario fed back by the first server, collect the current scenario information of the first business scenario, and compare the traffic control parameters with the current scenario information; When the comparison determines that the current scenario information matches the traffic control parameters, it is determined that the first business scenario has a traffic control requirement; When the comparison determines that the current scenario information does not match the traffic control parameters, it is determined that there is no traffic control requirement for the first service scenario, and the first service request is sent to the first server.

4. The method according to claim 3, characterized in that, The step of comparing the flow control parameters with the current scene information includes: A preset control time point is extracted from the flow control parameters. This preset control time point is compared with the current scene time included in the current scene information. If the preset control time point matches the current scene time, the current scene information is determined to match the flow control parameters. If the preset control time point does not match the current scene time, the current scene information is determined to not match the flow control parameters. And / or, A request quantity threshold is extracted from the traffic control parameters. The request quantity threshold is compared with the number of currently occurring requests included in the current scenario information. If the number of currently occurring requests is greater than or equal to the request quantity threshold, the current scenario information is determined to match the traffic control parameters. If the number of currently occurring requests is less than the request quantity threshold, the current scenario information is determined to not match the traffic control parameters.

5. The method according to claim 1, characterized in that, The method further includes: When multiple second business requests to be processed are received simultaneously, and each of the multiple second business requests is initiated in a scenario where there is a traffic control requirement, for each second business request, query the second business scenario in which the user initiated the second business request. Obtain the second control ratio and scenario weight value corresponding to the second business scenario, and query the second average time consumption corresponding to the second business scenario. The second average time consumption is the average time consumed when transmitting business requests initiated in the second business scenario. Using the second control ratio, the second average time consumption, and the scenario weight value, a random number is selected as the second delay duration of the second service request; The request initiation time of the second service request is determined. When the time interval between the current time and the request initiation time is detected to be equal to the second delay duration, the second service request is sent to the second server that provides services for the second service scenario, so that the second server can process the second service request.

6. The method according to claim 5, characterized in that, The step of selecting a random number as the second delay duration for the second service request using the second control ratio, the second average time consumption, and the scenario weight value includes: Determine a preset coefficient, and calculate the second difference between the preset coefficient and the second control ratio; Calculate the second ratio of the preset coefficient to the second difference, and calculate the second product of the second ratio and the second average time consumption; Calculate the sum of the second product and the scene weight value, use the scene weight value and the sum as interval endpoints to form a second value interval, and call a random function to take a value in the second value interval to obtain a random number as the second delay duration.

7. A control device for requesting traffic, characterized in that, include: The query module is used to respond to the first business request to be processed and query the first business scenario in which the user initiated the first business request. The acquisition module is used to acquire the first control ratio corresponding to the first business scenario when it is detected that there is a traffic control requirement in the first business scenario; The selection module is used to query the first average time consumption corresponding to the first business scenario, and select a random number as the first delay duration using the first control ratio and the first average time consumption. The first average time consumption is the average time consumed when transmitting business requests initiated in the first business scenario. The selection module is used to determine a preset coefficient, calculate a first difference between the preset coefficient and the first control ratio, calculate a first ratio between the preset coefficient and the first difference, and calculate a first product between the first ratio and the first average time consumption; obtain a preset endpoint value, construct a first value interval using the preset endpoint value and the first product as interval endpoints, and call a random function to select a value within the first value interval to obtain a random number as the first delay duration. The sending module is used to determine the request initiation time of the first service request, and when it detects that the time interval between the current time and the time when the request occurred is equal to the first delay duration, it sends the first service request to the first server that provides services for the first service scenario, so that the first server can process the first service request.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A 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 method according to any one of claims 1 to 6.

Images