Service processing method and device and electronic equipment
By classifying service requests by level and differentiating tokens, the problem of system crashes caused by sudden traffic surges in cloud computing platforms has been solved, achieving smooth traffic transition and improved system stability.
Patent Information
- Application Number
- CN202511715050.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-21
- Publication Date
- 2026-01-30
AI Technical Summary
In cloud computing platforms and distributed systems, sudden traffic surges can easily lead to system performance degradation or even crashes. Existing fixed-window rate limiting methods cannot effectively cope with the problem of sudden traffic increases.
By classifying service requests into different levels and implementing differentiated processing strategies based on different token levels, including immediate processing, delayed processing, and rejection processing, high-priority requests are prioritized, and the token generation rate is dynamically adjusted to adapt to load changes.
It achieves a smooth transition during traffic surges, avoids system crashes, optimizes resource utilization, improves system stability and response speed, and ensures timely processing of high-priority requests.
Smart Images
Figure CN121441990A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer network technology, and in particular to a service processing method, apparatus and electronic device. Background Technology
[0002] Currently, in cloud computing platforms and distributed systems, service startup and load warm-up often face problems such as traffic surges and system overload. To address these issues, related technologies employ a fixed window rate limiting method, where new requests are rejected when the number of requests within the window exceeds a set threshold. However, this method is prone to severe performance degradation or even system crashes during sudden traffic spikes. Summary of the Invention
[0003] This application provides a service processing method, apparatus, and electronic device to address the problem that a sudden increase in traffic can easily lead to a severe decline in system performance or even system crash.
[0004] To solve the above-mentioned technical problems, this application is implemented as follows:
[0005] In a first aspect, embodiments of this application provide a service processing method, the method comprising:
[0006] When the system is in the first state and a service request is received, the level of the service request is determined;
[0007] The service request is processed based on the token according to a first processing strategy corresponding to the level of the service request;
[0008] The first processing strategy is a strategy among multiple processing strategies that corresponds to the level of the service request, and the multiple processing strategies include different processing priorities for the service request.
[0009] Secondly, embodiments of this application provide a service processing apparatus, the apparatus comprising:
[0010] The determination module is used to determine the level of the service request when the system is in the first state and a service request is received;
[0011] The processing module is used to process the service request based on the token according to a first processing strategy corresponding to the level of the service request;
[0012] The first processing strategy is a strategy among multiple processing strategies that corresponds to the level of the service request, and the multiple processing strategies include different processing priorities for the service request.
[0013] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of the service processing method described in the first aspect.
[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the service processing method described in the first aspect.
[0015] Fifthly, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the service processing method as described in the first aspect.
[0016] In this embodiment, the system can perform differentiated scheduling of service requests with different priorities, thereby enabling high-priority requests to be processed in a timely manner and reducing the possibility of severe performance degradation or even system crash. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is one of the flowcharts of a service processing method provided in the embodiments of this application;
[0019] Figure 2 This is a second flowchart of a service processing method provided in an embodiment of this application;
[0020] Figure 3 This is a schematic diagram of the structure of a service processing device provided in an embodiment of this application;
[0021] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0023] This application provides a service processing method, apparatus, and electronic device to solve the problem of degraded system performance.
[0024] See Figure 1 , Figure 1 This is a flowchart of a service processing method provided in an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:
[0025] Step 101: When the system is in the first state and a service request is received, determine the level of the service request;
[0026] Step 102: Process the service request based on the token according to the first processing strategy corresponding to the level of the service request;
[0027] The first processing strategy is a strategy among multiple processing strategies that corresponds to the level of the service request, and the multiple processing strategies include different processing priorities for the service request.
[0028] The first state includes the transition from the service warm-up state to the stable state, and the second state can be the normal state of the service. In the normal state, the service runs more stably.
[0029] The system can determine its state based on service load metrics. These metrics can be determined by service and request processing capacity (e.g., the number of successfully processed requests per unit time reaches a regular threshold, no request drops or latency spikes), resource utilization (e.g., CPU, memory, etc. are stable within a reasonable range), and token consumption and replenishment balance (token consumption and generation rates match over a long period, with no backlog or shortage). Moreover, these metrics can remain stable for a period of time.
[0030] When the system is in the first state, if a service request is received, the level of the service request is determined, the corresponding first processing strategy is determined according to the level of the service request, and the service request is processed based on the token.
[0031] Service requests can be categorized by importance, urgency, etc., with each categorization corresponding to a different processing strategy and priority. Upon receiving a service request, it is processed according to the corresponding strategy. For example, service requests for core, important, or urgent business operations have higher priority, while service requests for ordinary business operations have lower priority.
[0032] In some implementations, tokens of corresponding priorities can be assigned according to the priority of service requests, so that high-priority service requests are processed first, while low-priority service requests are delayed or rejected.
[0033] In some implementations, a corresponding token type or tag is assigned based on the level of the service request in order to determine the corresponding processing strategy;
[0034] In some implementations, different flow control algorithms (such as the leaky bucket algorithm) are used to determine the processing strategy corresponding to the service request;
[0035] In some implementations, different request queuing and scheduling strategies are used to determine the processing strategy corresponding to the service request.
[0036] The above processing strategies may include the processing priority of service requests and the processing method of service requests, such as discarding service requests or processing them immediately.
[0037] Traditional rate limiting methods cannot smoothly transition the system to a high-load state during traffic surges, easily leading to resource waste, request loss, or even system crashes. Furthermore, the inflexible traffic scheduling during service warm-up prevents dynamic adjustments based on actual load.
[0038] In this embodiment of the application, when the system is in the first state, the system is in the warm-up stage or has poor stability. Service requests are prioritized and differentiated according to their level, thereby reducing system crashes caused by sudden traffic surges and achieving a smooth traffic transition during the service startup phase.
[0039] This approach ensures that high-priority traffic is processed first, while low-priority traffic is processed gradually when the system load is light, avoiding traffic spikes seen in traditional methods. By controlling the inbound rate of service requests, it effectively prevents momentary overload issues during service startup and load increases. Precise traffic control avoids traffic surges and system crashes common in traditional methods, ensuring smooth service startup and load transition. Fine-grained traffic control optimizes the use of system resources, preventing service crashes or latency caused by traffic spikes. It not only optimizes traffic allocation but also improves system stability, especially during peak service load periods, ensuring efficient request processing and stable operation.
[0040] The system can schedule traffic of different priorities in an orderly manner. Under high load, low priority traffic can be delayed or dropped, thereby ensuring the timely processing of high priority requests and effectively avoiding system crashes or severe performance degradation that may occur in traditional rate limiting methods.
[0041] Optionally, processing the service request based on the token according to a first processing strategy corresponding to the level of the service request includes:
[0042] Retrieve a token of the first target level corresponding to the level of the service request from the token bucket;
[0043] Based on the first target level of the token, the first processing strategy is determined among the multiple processing strategies;
[0044] The service request is processed according to the first processing strategy;
[0045] The tokens in the token bucket are divided into at least two levels that correspond one-to-one with the level of the service request. The first target level is one of the at least two levels, and the tokens of each level are used to indicate a processing strategy for the service request.
[0046] The tokens in the token bucket can be divided into multiple levels, and the level of the token corresponds one-to-one with the level of the service request. Each level of token is pre-defined to indicate the processing strategy for the corresponding service request.
[0047] Upon receiving a service request, obtain the token level corresponding to the level of the service request, i.e., the token of the first target level.
[0048] For example, a service request may have four levels, and a token may correspond one-to-one with each of the four levels. If the service request is at level one, then the token level is also level one. If there are not enough tokens at level one, then the service request at level one will be assigned to a token at level two; if there are not enough tokens at level two, then the service request at level one will be assigned to a token at level three, and so on.
[0049] In some implementations, the token's level is determined based on the token's markings;
[0050] In some implementations, the level of a token is determined by its color;
[0051] In some implementations, the token's level is determined based on the token's type.
[0052] The priority and processing method for service requests are determined based on the token's level.
[0053] For example, tokens can be divided into four levels, with different levels indicating the priority and processing method for service requests. The processing priorities, from highest to lowest, are Level 1, Level 2, Level 3, and Level 4. Levels 1 and 2 involve processing service requests immediately or after a short wait, while Levels 3 and 4 involve delaying or discarding service requests.
[0054] By setting different token levels, different processing priorities and traffic allocations for service requests can be implemented, reducing resource waste.
[0055] Optionally, obtaining a token for a first target level corresponding to the level of the service request from the token bucket includes:
[0056] Based on the pre-defined correspondence between the service request level and the token level, a token of the second target level corresponding to the service request level is obtained from the token bucket. The second target level is one of the at least two levels.
[0057] If there are insufficient tokens for the second target level, a token of the first target level that is adjacent to the second target level and has a lower priority than the second target level is obtained from the token bucket.
[0058] The first target level and the second target level are any two of at least two levels.
[0059] The service request level is pre-defined and corresponds one-to-one with the token level. That is, a first-level service request corresponds to a first-level token, and a second-level service request corresponds to a second-level token.
[0060] Upon receiving a service request at the first level, a token of the first level (i.e., the second target level) corresponding to the service request level is obtained from the token bucket according to the above correspondence. If there are insufficient tokens at the first level, a token of the second level (i.e., the first target level) which is one level lower than the first level is obtained, and the service request is processed according to the service request processing strategy corresponding to the second level.
[0061] It can improve the processing priority of important service requests, realize differentiated processing of different traffic, and reduce system crashes caused by traffic bursts.
[0062] Optionally, the at least two levels include a first level, a second level, a third level, and a fourth level in descending order of priority;
[0063] The processing strategy corresponding to the first level is: process service requests immediately;
[0064] The processing strategy corresponding to the second level is as follows: when the system has sufficient operating resources, the service request is processed immediately; when the system has insufficient operating resources, the service request is processed after a first preset time period, where the first preset time period is less than the target value.
[0065] The processing strategy corresponding to the third level is: if the system's operating resources are insufficient, the service request will be delayed for a second preset time before processing or rejected, where the second preset time is greater than the target value.
[0066] The processing strategy corresponding to the fourth level is to refuse to process service requests when the system's operating resources are insufficient.
[0067] The processing strategy for Level 1 tokens is to process service requests immediately. If a Level 1 service request is received and there are sufficient Level 1 tokens, it will be processed according to the corresponding Level 1 processing strategy.
[0068] In this context, "token sufficiency" can be understood as the number of tokens required to process a service request meeting the service request's needs. For example, for a single service request, which requires 1 token of the corresponding level, if the number of tokens of that level in the token bucket is greater than or equal to 1, then token sufficiency is considered sufficient.
[0069] Let's take the example of processing tokens in a token bucket that include four colors.
[0070] When a first-level service request arrives at the system, it is processed according to the priority of the four token colors. The specific processing logic is as follows:
[0071] Service requests corresponding to green tokens (Level 1) are processed first. Service request processing formula: P G =G r / G t .
[0072] Among them, G r G represents the current number of green tokens. t Indicates the number of green tokens required for the request.
[0073] If P G If the value is ≥1, the processing strategy for the green token is: process the service request corresponding to the green token immediately.
[0074] If there are insufficient green tokens, the service request will be transferred to the yellow token (second level) for processing. Service request processing formula: P Y =Y r / Y t .
[0075] Among them, Y r Y represents the current number of yellow tokens. t This indicates the number of yellow tokens required for a service request.
[0076] If P Y If the value is ≥1, the processing strategy for the yellow token is as follows: if the system's operating resources (such as the server's CPU, memory, network bandwidth, etc.) are sufficient, process the service request corresponding to the yellow token; otherwise, wait briefly (i.e. wait for the first preset time) before processing.
[0077] If there are insufficient yellow tokens, the service request will be transferred to the red token (third level) for processing. The processing strategy for the red token is: when the system's operating resources are insufficient, processing will be delayed (for a second preset time) or even discarded.
[0078] If there are not enough red tokens, the service request will be transferred to the blue token (level 4) for processing. The processing strategy for the blue token is: in the case of extreme load (such as when the system is severely under-resourced or the load exceeds the severe load threshold), the request will be dropped directly to alleviate the system load.
[0079] By employing the methods described above, we can increase the processing priority of critical service requests, achieve differentiated processing of different traffic types, and reduce system crashes caused by traffic surges. This enables smooth system startup, avoids system overload, and improves service stability and response speed.
[0080] Optionally, each token includes a marker indicating the token's level; determining the first processing strategy among the multiple processing strategies based on the first target level of the token includes:
[0081] Based on the token's markings, the token's level is determined to be the first target level;
[0082] The first processing strategy is determined among the multiple processing strategies based on the first target level of the token.
[0083] The tokens can be marked with color codes or other tags used by the user to indicate different categories. Tags are pre-set to indicate the token's level, and each tag corresponds to a specific processing strategy.
[0084] For example, tokens can be divided into four levels: green, yellow, red, and blue, with each level corresponding to different service request priorities and processing methods.
[0085] Green: High-priority traffic, processed directly when sufficient tokens are available.
[0086] Yellow: Medium priority traffic. If sufficient resources are available, it will be processed immediately; otherwise, it will wait briefly.
[0087] Red: Low-priority traffic, which may be delayed or even dropped when resources are scarce.
[0088] Blue: Extremely low priority traffic, which can be discarded under extreme load.
[0089] By setting different token levels, different processing priorities and traffic allocations for service requests can be implemented, enabling fine-grained traffic control and reducing resource waste.
[0090] Optionally, the at least two levels include a third target level and a fourth target level, wherein the processing priority corresponding to the third target level is higher than the processing priority corresponding to the fourth target level;
[0091] When the system load is at the first load value, the proportion of the tokens of the fourth target level is the first proportion value;
[0092] When the system load is the second load value, the proportion of the tokens of the fourth target level is the second proportion value;
[0093] Wherein, the ratio is the ratio of the tokens of the fourth target level to all tokens in the token bucket; the second load value is greater than the first load value, and the second ratio value is greater than the first ratio value.
[0094] The third and fourth target levels represent two priorities from at least two levels. The third target level indicates high priority, and the fourth target level indicates low priority.
[0095] When the system load is at the first load level, the load is relatively small, and the initial token ratio can be set. The token ratio for the fourth target level is the proportion of fourth target level tokens in the token bucket to the total number of tokens in the token bucket.
[0096] When the system load is at the second level, the increased load can increase the proportion of tokens at the fourth target level.
[0097] For example, when the load is 30%, the proportion of tokens in the third target level is greater than the proportion of tokens in the fourth target level. When the load rises to 60%, the proportion of tokens in the fourth target level is increased so that the proportion of tokens in the fourth target level is greater than the proportion of tokens in the third target level.
[0098] Among them, the third target level and the fourth target level are two levels obtained by classifying the token into multiple levels. In practical applications, if the token is divided into multiple levels, the multiple levels can be divided into two categories corresponding to high priority and low priority, which correspond to the third target level and the fourth target level, respectively.
[0099] The third and fourth target levels can also be any two of multiple levels. For example, if the token is divided into four levels, the third target level can be any of the high priority levels, and the fourth target level can be any of the low priority levels.
[0100] For example, by dynamically adjusting the proportions of tokens of different colors, system traffic can be optimally scheduled during peak load periods and warm-up phases. During initialization, the proportions of the four token colors are set as follows:
[0101] Green Token (G): 50%
[0102] Yellow token (Y): 30%
[0103] Red token (R): 15%
[0104] Blue Token (B): 5%
[0105] The formula for generating tokens of each color is as follows:
[0106] G=T×0.5, Y=T×0.3, R=T×0.15, B=T×0.05
[0107] The proportions of the four tokens are dynamically adjusted based on the real-time system load. When the load increases, the proportion of blue and red tokens is increased to prioritize control of low-priority traffic.
[0108] Since tokens of the fourth target level have a lower processing priority, the number of service requests processed can be increased by increasing the proportion of low-priority tokens.
[0109] Adjusting the proportion of different token levels based on real-time traffic demand optimizes resource allocation, thereby balancing the load and preventing system overload.
[0110] Optionally, if the system load exceeds a preset threshold, the service request corresponding to the first token is delayed or dropped with a higher priority than the service request corresponding to the second token.
[0111] The first token and the second token are two tokens in the token bucket, and the level corresponding to the first token is lower than the level corresponding to the second token.
[0112] When the system load is high, exceeding a preset threshold, low-priority service requests are prioritized for delay or dropping. For example, among the four colored tokens mentioned above, low-priority traffic corresponding to red tokens is prioritized for delay or even dropping. This means that low-priority traffic is managed first to reduce its consumption of system resources, thereby freeing up resources for high-priority traffic and preventing system overload and crashes.
[0113] Optionally, the system generates tokens at a rate lower than that in the first state than in the second state, and the system load in the first state is lower than that in the second state.
[0114] The second state can be the state of the system after it has stabilized, where the system's operating resources are relatively stable.
[0115] When the system is in the first state, it is in the warm-up phase or has poor stability. The token generation rate is lower than that in the second state. Service requests are processed based on the tokens, which realizes a smooth transition in the service warm-up phase. Furthermore, it processes requests according to the corresponding priorities under different loads, which can improve resource allocation under different loads and improve the utilization of system resources.
[0116] In some implementations, when the system is in its first state, the token generation rate can be correlated with the load size. The system can initialize the token bucket capacity and token generation rate based on the expected load and resource conditions. The token bucket capacity can be adjusted in real time according to the load.
[0117] In this way, in the first state, the token generation rate can dynamically change according to the load size to adapt to load changes during the warm-up period, thereby achieving a smooth service transition. Furthermore, it can dynamically adjust traffic priorities and resource allocation strategies to improve service stability during the startup phase and peak load periods.
[0118] Optionally, the method further includes:
[0119] When the system is in its first state, tokens are generated at the rate corresponding to the following formula:
[0120] T = R × △t
[0121] Where T is the total number of tokens generated per unit time;
[0122] R is the token generation rate;
[0123] △t is the time interval for token generation.
[0124] The token generation rate and time interval mentioned above can be determined based on the actual load.
[0125] In this way, in the first state, the token generation rate can dynamically change according to the load size to adapt to load changes during the warm-up period, thereby achieving a smooth service transition. The ability to dynamically adjust the token generation rate allows for flexible adjustment based on the actual load.
[0126] During load warm-up, the system dynamically adjusts the token generation rate based on traffic and load, enabling services to reach normal operating status in a shorter time and preventing excessive consumption of system resources. This smooth service warm-up mechanism significantly improves system response speed and resource utilization efficiency.
[0127] To facilitate understanding of the solutions in this application, specific embodiments are provided below as examples.
[0128] like Figure 2 As shown, it includes the following steps:
[0129] Initialize the token bucket: Before the service starts, the token bucket capacity and token generation rate are initialized based on the expected system load and resource conditions. At this time, the token generation rate is low to avoid the service being overloaded with too many requests prematurely.
[0130] Dynamic token generation rate: The token generation rate can be dynamically adjusted based on the actual traffic load. For example, the token generation rate is slower when traffic is low and faster when traffic surges to smoothly handle the traffic.
[0131] Service preheating: During the service preheating phase, the token generation rate in the token bucket gradually increases, and the token bucket capacity is adjusted according to the real-time load. The service starts smoothly during this phase, avoiding sudden high load surges.
[0132] When the token bucket capacity is saturated, the system sets a maximum waiting time to ensure that requests do not remain in a waiting state for an extended period.
[0133] Request arrival processing: When a request arrives, the system first checks if the token bucket has enough tokens. If so, the tokens are consumed and the request is processed; otherwise, the request is delayed or rejected according to a policy to avoid system overload.
[0134] Service restored. Once the system stabilizes and returns to normal operation, the token bucket generation rate returns to its normal value, and the system enters normal operating mode.
[0135] The solution described in this application is applicable to large-scale distributed systems, especially in scenarios requiring high-load warm-up, such as cloud computing platforms and internet service platforms. By implementing differentiated traffic control, a smooth service startup can be effectively achieved, preventing system crashes, delays, or performance degradation due to overload.
[0136] See Figure 3 , Figure 3 This is a schematic diagram of the structure of a service processing device provided in an embodiment of this application, such as... Figure 3 As shown, the service processing device 300 includes:
[0137] The determining module 301 is used to determine the level of the service request when the system is in the first state and a service request is received;
[0138] Processing module 302 is used to process the service request based on the token according to a first processing strategy corresponding to the level of the service request;
[0139] The first processing strategy is a strategy among multiple processing strategies that corresponds to the level of the service request, and the multiple processing strategies include different processing priorities for the service request.
[0140] Optionally, the processing module 302 includes:
[0141] The acquisition submodule is used to acquire a token of the first target level corresponding to the level of the service request from the token bucket;
[0142] A determining submodule is configured to determine the first processing strategy among the multiple processing strategies based on the first target level of the token;
[0143] A processing submodule is used to process the service request according to the first processing strategy;
[0144] The tokens in the token bucket are divided into at least two levels that correspond one-to-one with the level of the service request. The first target level is one of the at least two levels, and the tokens of each level are used to indicate a processing strategy for the service request.
[0145] Optionally, the acquisition submodule is specifically used for:
[0146] Based on the pre-defined correspondence between the service request level and the token level, a token of the second target level corresponding to the service request level is obtained from the token bucket. The second target level is one of the at least two levels.
[0147] If there are insufficient tokens for the second target level, a token of the first target level that is adjacent to the second target level and has a lower priority than the second target level is obtained from the token bucket.
[0148] Optionally, the at least two levels include a first level, a second level, a third level, and a fourth level in descending order of priority;
[0149] The processing strategy corresponding to the first level is: process service requests immediately;
[0150] The processing strategy corresponding to the second level is as follows: when the system has sufficient operating resources, the service request is processed immediately; when the system has insufficient operating resources, the service request is processed after a first preset time period, where the first preset time period is less than the target value.
[0151] The processing strategy corresponding to the third level is: if the system's operating resources are insufficient, the service request will be delayed for a second preset time before processing or rejected, where the second preset time is greater than the target value.
[0152] The processing strategy corresponding to the fourth level is to refuse to process service requests when the system's operating resources are insufficient.
[0153] Optionally, each token includes a marker indicating the token's level; the determining submodule is specifically used for:
[0154] Based on the token's markings, the token's level is determined to be the first target level;
[0155] The first processing strategy is determined among the multiple processing strategies based on the first target level of the token.
[0156] Optionally, the at least two levels include a third target level and a fourth target level, wherein the processing priority corresponding to the third target level is higher than the processing priority corresponding to the fourth target level;
[0157] When the system load is at the first load value, the proportion of the tokens of the fourth target level is the first proportion value;
[0158] When the system load is the second load value, the proportion of the tokens of the fourth target level is the second proportion value;
[0159] Wherein, the ratio is the ratio of the tokens of the fourth target level to all tokens in the token bucket; the second load value is greater than the first load value, and the second ratio value is greater than the first ratio value.
[0160] Optionally, if the system load exceeds a preset threshold, the service request corresponding to the first token is delayed or dropped with a higher priority than the service request corresponding to the second token.
[0161] The first token and the second token are two tokens in the token bucket, and the level corresponding to the first token is lower than the level corresponding to the second token.
[0162] Optionally, the system generates tokens at a rate lower than that in the first state than in the second state, and the system load in the first state is lower than that in the second state.
[0163] Optionally, the device further includes:
[0164] The generation module is configured to generate tokens at a rate corresponding to the following formula when the system is in the first state:
[0165] T = R × △t
[0166] Where T is the total number of tokens generated per unit time;
[0167] R is the token generation rate;
[0168] △t is the time interval for token generation.
[0169] Service processing device 300 is capable of Figure 1 The various processes implemented in the method embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.
[0170] like Figure 4 As shown, this application embodiment also provides an electronic device 400, including: a processor 401, a memory 402, and a program stored in the memory 402 and executable on the processor 401. When the program is executed by the processor 401, it implements the various processes of the above-described service processing method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.
[0171] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described service processing method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.
[0172] This application also provides a computer program product, including computer instructions, which, when executed by a processor, implement the above-described... Figure 1 The various processes of the method embodiments shown can achieve the same technical effect, and will not be described again here to avoid repetition.
[0173] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0174] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0175] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.
Claims
1. A service processing method characterized by comprising: The method comprises: In the case that the system is in the first state and a service request is received, determining a level of the service request; Processing the service request based on a token according to a first processing strategy corresponding to the level of the service request; The first processing strategy is a strategy corresponding to the level of the service request in a plurality of processing strategies, and the plurality of processing strategies comprise different processing priorities of service requests.
2. The method of claim 1, wherein, The processing of the service request based on the token according to the first processing strategy corresponding to the level of the service request comprises: Obtaining a token of a first target level corresponding to the level of the service request in a token bucket; Determining the first processing strategy in the plurality of processing strategies according to the first target level of the token; Processing the service request according to the first processing strategy; The tokens in the token bucket are divided into at least two levels corresponding to the level of the service request one by one, the first target level is one of the at least two levels, and the token of each level is used to indicate a processing strategy of a service request.
3. The method of claim 2, wherein, The obtaining of the token of the first target level corresponding to the level of the service request in the token bucket comprises: According to a predetermined corresponding relationship between the level of the service request and the level of the token, obtaining a token of a second target level corresponding to the level of the service request in the token bucket, the second target level being one of the at least two levels; In the case that the token of the second target level is insufficient, obtaining a token of a first target level adjacent to the second target level and having a lower priority than the second target level in the token bucket.
4. The method according to claim 2 or 3, characterized in that, The at least two levels comprise a first level, a second level, a third level and a fourth level in descending order of priority; The processing strategy corresponding to the first level is to process the service request immediately; The processing strategy corresponding to the second level is to process the service request immediately in the case that the running resources of the system are sufficient; In the case that the running resources of the system are insufficient, the service request is processed after a first preset time period, and the first preset time period is less than a target value; The processing strategy corresponding to the third level is to process or reject the processing of the service request after a second preset time period in the case that the running resources of the system are insufficient, and the second preset time period is greater than the target value; The processing strategy corresponding to the fourth level is to reject the processing of the service request in the case that the running resources of the system are insufficient.
5. The method of claim 2, wherein, Each token comprises a mark for indicating the level of the token; The determination of the first processing strategy in the plurality of processing strategies according to the first target level of the token comprises: Based on the mark of the token, it is determined that the level of the token is the first target level; The first processing strategy is determined in the plurality of processing strategies according to the first target level of the token.
6. The method of claim 2, wherein, The at least two levels comprise a third target level and a fourth target level, and the processing priority corresponding to the third target level is higher than the processing priority corresponding to the fourth target level. In a case where the system load is a first load value, a proportion of the tokens of the fourth target level is a first proportion value; In a case where the system load is a second load value, a proportion of the tokens of the fourth target level is a second proportion value; The proportion is a ratio of the tokens of the fourth target level to all tokens in the token bucket; the second load value is greater than the first load value, and the second proportion value is greater than the first proportion value.
7. The method of claim 6, wherein, In a case where the system load is greater than a preset threshold, a processing priority of a service request corresponding to a first token is greater than a processing priority of a service request corresponding to a second token; The first token and the second token are two tokens in the token bucket, and a level corresponding to the first token is lower than a level corresponding to the second token.
8. The method according to any one of claims 1 to 3, characterized in that, The system generates tokens at a rate in the first state that is less than a rate in a second state, and a system load in the first state is less than a system load in the second state.
9. The method of claim 8, wherein, The method further includes: In a case where the system is in a first state, tokens are generated at a rate corresponding to the following formula: T = R x Δt T is a total number of tokens generated per unit time; R is a token generation rate; Δt is a time interval for token generation.
10. A service processing apparatus characterized by comprising: The method includes: A determination module is configured to determine a level of a service request in a case where the system is in a first state and the service request is received; A processing module is configured to process the service request according to a first processing strategy corresponding to the level of the service request based on a token; The first processing strategy is a strategy corresponding to the level of the service request in a plurality of processing strategies, and the plurality of processing strategies include different processing priorities for service requests.
11. An electronic device, comprising: The method includes: A processor, a memory, and a program stored on the memory and executable on the processor, the program being executed by the processor to implement the steps of the service processing method according to any one of claims 1 to 9.
12. A computer-readable storage medium, characterized in that, The computer program is stored on the computer readable storage medium and is executed by the processor to implement the steps of the service processing method according to any one of claims 1 to 9.
13. A computer program product, characterised in that, The computer program is stored on the computer readable storage medium and is executed by the processor to implement the steps of the service processing method according to any one of claims 1 to 9.