A system current limiting method and apparatus

Abstract

This application provides a system rate limiting method and apparatus, relating to the field of financial technology. The method includes: determining the load status of the called system based on the request-response characteristics between the calling system and the called system, and obtaining the predicted throughput of the calling system in the current time frame based on the throughput data of the calling system in multiple historical time frames; then determining the throughput threshold of the calling system using the load status of the called system and the predicted throughput of the calling system, and using the throughput threshold to perform flow control on the calling system. This achieves rate limiting on the calling system side, effectively solving the IO resource occupation problem caused by repeated sending of call requests in traditional rate limiting schemes. Thus, it not only fully satisfies the call requests of the calling system, but also maximizes resource utilization while ensuring the stability of the called system.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a system flow limiting method and apparatus. Background Technology

[0002] Microservice architecture is a mainstream IT system architecture solution. When faced with unexpected traffic, microservice architecture employs rate limiting and circuit breaking technologies to limit the flow of data. Rate limiting and circuit breaking are the theoretical basis for ensuring that the system can provide impaired service in disaster situations. For example, in the e-commerce field, the called systems for product inquiries, order placement, and payments typically have a threshold for transactions per second (TPS). When the traffic of the calling system exceeds the TPS threshold, the called system rejects new calls from the calling system. When the traffic of the calling system is less than or equal to the TPS threshold, the called system allows new calls from the calling system.

[0003] When a call request from the calling system is rejected, the calling system will re-initiate the request, and the called system will most likely reject the request again. For the called system, repeatedly receiving call requests leads to the occupation of I / O resources, resulting in excessive system load. Summary of the Invention

[0004] This application provides a system rate limiting method and apparatus, which enables rate limiting on the calling system side to maximize resource utilization while ensuring the stability of the called system.

[0005] On the one hand, embodiments of this application provide a system rate limiting method, the method comprising:

[0006] Obtain the request-response characteristics between the calling system and the called system within the (i-1)th time frame;

[0007] Based on the request-response characteristics, the load status of the called system is determined; and based on the throughput data of the calling system in multiple historical time frames before the i-th time frame, the predicted throughput of the calling system in the i-th time frame is obtained, where i is a positive integer greater than 1.

[0008] Using the load status of the called system and the predicted throughput, the throughput threshold of the calling system in the i-th time frame is determined.

[0009] Based on the throughput threshold, flow control is performed on the call requests sent by the caller system to the callee system within the i-th time frame.

[0010] In this embodiment, the load status of the called system is determined based on the request-response characteristics between the calling system and the called system, and the predicted throughput of the calling system in the current time frame is obtained based on the historical throughput data of the calling system. Then, the load status of the called system and the predicted throughput of the calling system are used to determine the throughput threshold of the calling system, and the throughput threshold is used to perform flow control on the calling system. This achieves rate limiting on the calling system side, effectively solving the problem of IO resource occupation of the called system caused by the calling system repeatedly sending call requests in traditional rate limiting schemes. Thus, the call requests of the calling system are fully satisfied, and the resource utilization is maximized while ensuring the stability of the called system.

[0011] On one hand, embodiments of this application provide a system current limiting device, the device comprising:

[0012] The acquisition module is used to acquire the request-response characteristics between the caller system and the callee system within the (i-1)th time frame;

[0013] The prediction module is used to determine the load status of the called system based on the request-response characteristics; and to obtain the predicted throughput of the calling system in the i-th time frame based on the throughput data of the calling system in multiple historical time frames before the i-th time frame, where i is a positive integer greater than 1.

[0014] The processing module is used to determine the throughput threshold of the calling system in the i-th time frame by using the load status of the called system and the predicted throughput.

[0015] The control module is used to perform flow control on the call requests sent by the caller system to the callee system within the i-th time frame, based on the throughput threshold.

[0016] On one hand, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the above-described system current limiting method.

[0017] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the above-described system flow limiting method.

[0018] It should be noted that the above-described solution provided in the Summary of the Invention is merely one specific implementation of this application and not the application itself; correspondingly, the technical effects provided in the Summary of the Invention are merely the technical effects of the specific implementation and not all the technical effects of this application. Attached Figure Description

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

[0020] Figure 1 A schematic diagram of a system architecture provided in an embodiment of this application;

[0021] Figure 2 A flowchart illustrating a system current limiting method provided in this application embodiment. Figure 1 ;

[0022] Figure 3 A flowchart illustrating a system current limiting method provided in this application embodiment. Figure 2 ;

[0023] Figure 4 A schematic diagram illustrating a request-response feature provided in an embodiment of this application;

[0024] Figure 5 A schematic diagram of a request-response gradient curve provided for an embodiment of this application;

[0025] Figure 6 A schematic diagram illustrating the detection results of actual throughput as provided in an embodiment of this application;

[0026] Figure 7 A flowchart illustrating a system current limiting method provided in this application embodiment. Figure 3 ;

[0027] Figure 8 This is a schematic diagram of the structure of a system current limiting device provided in an embodiment of this application;

[0028] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0030] refer to Figure 1 This is a system architecture diagram applicable to the embodiments of this application. The system architecture includes at least a calling system 101 and a called system 102. The number of calling systems 101 can be one or more, and the number of called systems 102 can also be one or more. This application does not specifically limit the number of calling systems 101 and called systems 102.

[0031] The calling system 101 and the called system 102 correspond to different applications, which can be client applications, web applications, mini-program applications, etc. The calling system 101 and the called system 102 can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers 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 (CDNs), and big data and artificial intelligence platforms. The calling system 101 and the called system 102 can be directly or indirectly connected via wired or wireless communication; this application does not impose any restrictions on this connection.

[0032] The calling system 101 obtains business services provided by the called system 102 by sending a call request to the called system 102. For example, in a shopping scenario, the calling system 101 can send call requests to the called system 102 associated with product query, order placement, and payment respectively to obtain product query service, order placement service, and payment service. Furthermore, the system rate limiting method in this application is applicable to rate limiting scenarios between the calling system 101 and the entire called system 102, as well as to rate limiting scenarios between each business service within the calling system 101 and the called system 102.

[0033] based on Figure 1 The system architecture diagram shown in this application illustrates the flow of a system rate limiting method. Figure 2 As shown, the process of this method is executed by a computer device, which can be... Figure 1 The caller system 101 shown includes the following steps:

[0034] Step S201: Obtain the request-response characteristics between the calling system and the called system within the (i-1)th time frame.

[0035] Specifically, i is a positive integer greater than 1. During the interface traffic probing process, there will occasionally be normal fluctuations, which generally conform to a normal distribution. In order to shield the impact of these fluctuations, this application divides the time into multiple identical time slices according to the time sequence, and each time slice is a time frame.

[0036] In a microservice architecture, the calling system sends a request to the called system, and the called system returns a response message to the calling system based on the request. This process is called a Request Return (RR) process. Each time frame includes one or more Request Return processes.

[0037] The calling system uses the RR acquisition component to monitor all call response processes within each time frame, and obtains the request response characteristics within each time frame based on all call response processes within each time frame.

[0038] Step S202: Based on the request-response characteristics, determine the load status of the called system; and based on the throughput data of the calling system in multiple historical time frames before the i-th time frame, obtain the predicted throughput of the calling system in the i-th time frame.

[0039] Specifically, the request-response characteristics between the calling and called systems can indirectly reflect the throughput of the called system, and thus determine its load status. Furthermore, in practical applications, system throughput changes are strongly correlated with historical throughput. Therefore, by analyzing the characteristics of throughput data changes in the calling system over multiple historical time frames prior to the i-th time frame, the predicted throughput of the calling system in the i-th time frame can be obtained.

[0040] Step S203: Using the load status and predicted throughput of the called system, determine the throughput threshold of the calling system in the i-th time frame.

[0041] Specifically, it determines whether the called system can continue to meet the predicted throughput of the calling system under the current load conditions. If so, the predicted throughput or its increased value is used as the throughput threshold; otherwise, the decreased predicted throughput is used as the throughput threshold. The throughput threshold refers to the upper limit at which the calling system can send call requests to the called system within a time frame.

[0042] Step S204: Based on the throughput threshold, perform flow control on the call requests sent by the caller system to the callee system within the i-th time frame.

[0043] Specifically, rate limiting algorithms such as the leaky bucket algorithm and the token bucket algorithm are used to control the flow of call requests sent from the caller system to the callee system within the i-th time frame. If the sending rate of call requests (or the throughput within the i-th time frame) reaches the throughput threshold, new call requests within the i-th time frame are intercepted and sent again in the next time frame.

[0044] For example, such as Figure 3 As shown, the calling system corresponds to application A. The calling system can send call requests to both called system 1 and called system 2 to obtain corresponding business services. Called system 1 corresponds to application B, and called system 2 corresponds to application C. Both called system 1 and called system 2 can provide various business services to the calling system.

[0045] The calling system includes an RR (Request Rate) collection component, a throughput calculation component, and a rate limiting component. For the called system 1, the RR collection component collects the request-response characteristics between the calling system and the called system 1 within each time frame. For the current time frame, the throughput calculation component determines the load status of the called system 1 based on the request-response characteristics of the previous time frame. Based on the throughput data of the calling system in multiple historical time frames, the predicted throughput of the calling system in the current time frame is obtained. Then, using the load status of the called system 1 and the predicted throughput of the calling system, the throughput threshold of the calling system in the current time frame is determined. The rate limiting component performs flow control on the call requests sent by the calling system to the called system 1 in the current time frame based on the throughput threshold. The system flow control process for the called system 2 is the same as that for the called system 1, and will not be described again here.

[0046] In this embodiment, the load status of the called system is determined based on the request-response characteristics between the calling system and the called system, and the predicted throughput of the calling system in the current time frame is obtained based on the historical throughput data of the calling system. Then, the load status of the called system and the predicted throughput of the calling system are used to determine the throughput threshold of the calling system, and the throughput threshold is used to perform flow control on the calling system. This achieves rate limiting on the calling system side, effectively solving the problem of IO resource occupation of the called system caused by the calling system repeatedly sending call requests in traditional rate limiting schemes. Thus, the call requests of the calling system are fully satisfied, and the resource utilization is maximized while ensuring the stability of the called system.

[0047] Optionally, in step S201 above, this application uses at least the following implementation methods to determine the request-response characteristics between the calling system and the called system:

[0048] Count the number of requests or responses between the calling system and the called system within the (i-1)th time frame. Use the ratio of the duration of the (i-1)th time frame to the number of requests as the request-response characteristic; or, use the ratio of the duration of the (i-1)th time frame to the number of responses as the request-return characteristic. Both the ratio of the duration of the (i-1)th time frame to the number of requests and the ratio of the duration of the (i-1)th time frame to the number of responses represent the average request-response duration within the (i-1)th time frame.

[0049] For example, if the duration of a time frame is set to 1 second, and the number of requests between the calling system and the called system within a time frame is 10, then the average request response time within that time frame is 1 / 10 = 100ms.

[0050] In this embodiment, time is divided into multiple time frames according to the time sequence, and the average request response time within each time frame is used as the request response feature within each time frame. This avoids the impact of normal fluctuations in the interface traffic detection process on the load status of the called system, thereby improving the accuracy of traffic control.

[0051] Optionally, in step S202 above, this application embodiment employs at least the following implementation method to determine the load status of the called system based on request-response characteristics:

[0052] Based on the request-response characteristics within the (i-1)th time frame and the request-response characteristics within the (i-2)th time frame, the request-response gain within the (i-1)th time frame is determined. Then, based on the request-response gain and the duration of the (i-1)th time frame, the request-response gradient within the (i-1)th time frame is determined. Based on the correlation between the request-response gradient and a preset overload coefficient, the load state of the called system is determined.

[0053] Specifically, the difference between the average request response time in the (i-1)th time frame and the average request response time in the (i-2)th time frame is used as the request response gain in the (i-1)th time frame. The ratio of the request response gain in the (i-1)th time frame to the duration of the (i-1)th time frame is used as the request response gradient in the (i-1)th time frame. The value of the overload coefficient β is strongly related to the specific business scenario. In a microservice architecture, the typical latency is measured in milliseconds. Therefore, this application sets the overload coefficient β between 50ms and 500ms.

[0054] In some embodiments, if the request-response gradient is greater than the overload coefficient, the load state of the called system is determined to be high load. If the request-response gradient is less than or equal to the overload coefficient and greater than zero, the load state of the called system is determined to be low load. If the request-response gradient is less than or equal to zero, the load state of the called system is determined to be normal.

[0055] For example, such as Figure 4 As shown, the duration of a time frame is set to L = 1s; the average request response time within the (i-1)th time frame is T. i-1 This indicates that the average request response time within the i-th time frame is represented by T. i This indicates that the average request response time within the (i+1)th time frame is represented by T. i+1 The request-response gain within the (i-1)th time frame is expressed as Δ. i-1 This indicates that the request-response gain within the i-th time frame is expressed as Δ. i This indicates that the request-response gain within the (i+1)th time frame is expressed as Δ. i+1 The request-response gradient within the (i-1)th time frame is represented by D. i-1 This indicates that the request-response gradient within the i-th time frame uses D. i This indicates that the request-response gradient within the (i+1)th time frame uses D. i+1 express.

[0056] Among them, the request-response gain Δ i =T i -T i-1 The request-response gain Δ can be obtained using the same calculation method. i-1 and request-response gain Δ i+1 The request-response gradient uses D. i =Δ i / L(t), the request-response gradient D can be obtained using the same calculation method. i-1 And the request-response gradient uses D i+1 .

[0057] To more clearly understand the changes in the request-response gradient, this application plotted request-response gradient curves based on the request-response gradients in the 3rd, 4th, and 5th time frames, as shown below. Figure 5 As shown. In Figure 4 In the given equations, T2 = 100ms, T3 = 140ms, T4 = 220ms, and T5 = 360ms, then Δ3 = T3 - T2 = 40ms, Δ4 = T4 - T3 = 80ms, and Δ5 = T5 - T4 = 140ms. Furthermore, D3 = Δ3 / L = 40ms, D4 = Δ4 / L = 80ms, and D5 = Δ5 / L = 140ms.

[0058] Assuming an overload factor β = 100ms, if the request-response gradients in the 3rd and 4th time frames are both less than the overload factor β and greater than zero, then the load states in the 3rd and 4th time frames are both low-load states. If the request-response gradient in the 5th time frame is greater than the overload factor β, then the load state in the 5th time frame is a high-load state. Meanwhile, from... Figure 5 The request-response gradient curve shown also indicates that as the time sequence changes, the average request-response time gradually increases, and the request-response gradient becomes steeper, reflecting that the called system has actually gradually reached the critical point of throughput, and the load of the called system has begun to deteriorate.

[0059] In this embodiment, the request response gradient within a time frame is determined based on the average request response duration within adjacent time frames and the duration of the time frame. Then, the request response gradient is used as an evaluation metric for whether the called system is overloaded, thereby enabling proactive detection of the system throughput of the called system under a microservice architecture.

[0060] Optionally, in step S203 above, the embodiments of this application obtain the predicted throughput of the calling system in the i-th time frame at least in the following manner:

[0061] Throughput data from multiple historical time frames are input into a time series model for processing. Based on the throughput data from these historical time frames and the corresponding autocorrelation coefficients for each frame, the time series model yields the predicted throughput.

[0062] Specifically, the autocorrelation coefficient can be learned during the training of the time series model, and its value ranges from [0, 1]. The closer the historical time frame is to the current time frame, the larger the corresponding autocorrelation coefficient; the farther the historical time frame is from the current time frame, the smaller the corresponding autocorrelation coefficient. The throughput data within the historical time frame can be the throughput threshold within the historical time frame, or it can be the actual throughput detected in the historical time frame.

[0063] In some embodiments, the throughput data within multiple historical time frames are weighted and summed based on the autocorrelation coefficients corresponding to each of the multiple historical time frames to obtain candidate throughput. Then, the candidate throughput is adjusted using a preset constant term and zero-mean white noise to obtain the predicted throughput, wherein the value range of the zero-mean white noise is [-1, 1], and the value range of the constant term is [0, 1].

[0064] For example, a time series model can be represented by the following formula (1):

[0065]

[0066] Among them, X tε represents the predicted throughput within the t-th time frame. t This represents white noise with zero mean, where c represents a constant term, and X... t-i This represents the throughput threshold within the ti-th time frame, where p represents the model order and also the number of historical time frames. This represents the autocorrelation coefficient.

[0067] Set p=7, and in the 8th time frame, input the throughput thresholds from the first 7 time frames into the time series model represented by formula (1). The time series model uses the autocorrelation coefficients corresponding to each of the 7 time frames to perform a weighted sum of the throughput thresholds within the 7 time frames to obtain the candidate throughput. Then, the candidate throughput, zero-mean white noise, and constant term are added together to obtain the predicted throughput for the 8th time frame.

[0068] In this embodiment of the application, since the system throughput change and historical throughput are strongly correlated, the predicted throughput of the calling system in the current time frame can be obtained by using a time series model based on throughput data in multiple historical time frames. This allows for rate limiting of the calling system based on the predicted throughput and the load status of the called system, thereby providing good protection for the called system and improving the availability and stability of the entire system.

[0069] In some embodiments, if the called system is under high load, a shrinkage factor is used to adjust the predicted throughput to obtain a throughput threshold. If the called system is under low load, the predicted throughput is used as the throughput threshold. If the called system is under normal load, an expansion factor is used to adjust the predicted throughput to obtain a throughput threshold.

[0070] Specifically, a value range of [0.15, 0.20] for the contraction factor is more reasonable; the smaller the contraction factor, the more moderate the flow contraction. A value range of [0.05, 0.15] for the expansion factor is more reasonable; the smaller the expansion factor, the more moderate the flow expansion. Generally, the contraction factor is greater than the expansion factor to facilitate rapid recovery from congestion. In one possible implementation, the throughput threshold can be obtained using the following formula (2):

[0071]

[0072] Among them, A t X represents the throughput threshold. t σ represents the predicted throughput, τ represents the expansion factor, and τ represents the contraction factor.

[0073] When the called system is expanded, the load state of the called system changes from a high load state or a low load state to a normal state because the throughput that the called system can handle increases. Therefore, based on the predicted throughput output by the time series model, the sending speed of the call request can be gradually increased in subsequent time frames by the expansion factor to continuously approach the actual processing capacity of the called system after expansion.

[0074] When the called system scales down or the throughput of the called system decreases due to sudden traffic from other systems, the called system transitions from a low-load or normal state to a high-load state. Therefore, based on the predicted throughput output by the time series model, the sending speed of the call request can be gradually reduced in subsequent time frames by using a shrinkage factor to continuously approximate the actual processing capacity of the called system after expansion.

[0075] After obtaining the throughput threshold, a rate limiting component is used to control the flow of call requests sent from the caller system to the callee system within the current time frame, based on the throughput threshold. If the sending rate (throughput) of call requests within the current time frame reaches the throughput threshold, new call requests within the current time frame are intercepted and sent again in the next time frame, ensuring that the sending rate of call requests within each time frame is within the throughput threshold.

[0076] For example, the throughput threshold for the third time frame is 80, the throughput threshold for the fourth time frame is 130, and the throughput threshold for the fifth time frame is 60. The actual throughput of the calling system in the third, fourth, and fifth time frames is probed to obtain... Figure 6 The detection results are shown in the image. From Figure 6 It can be seen that the peak actual throughput in the third time frame is 80, the peak actual throughput in the fourth time frame is 130, and the peak actual throughput in the fifth time frame is 60. This demonstrates that the caller system's throughput is within the throughput threshold in each time frame.

[0077] In this embodiment, when the resources of the called system are sufficient, the throughput threshold of the calling system is automatically increased; when the called system is busy, the throughput threshold of the calling system is automatically decreased, thereby ensuring that the called system is in the best operating state, avoiding the occurrence of avalanche effect, and maximizing resource utilization while ensuring system stability.

[0078] To better explain the embodiments of this application, a system rate limiting method provided by the embodiments of this application is described below in conjunction with a specific implementation scenario. The process of this method can be described as follows: Figure 1The caller system shown in the diagram includes an RR acquisition component, a throughput calculation component, and a rate limiting component. The process includes the following steps: Figure 7 As shown:

[0079] Step S701, application starts.

[0080] Step S702: Read parameters.

[0081] Specifically, the parameters include the duration L of the time frame, the overload coefficient β, the model order p of the time series model, and the autocorrelation coefficient. Expansion factor σ and contraction factor τ.

[0082] Step S703: The call request is transmitted to the rate limiting component.

[0083] In step S704, the rate limiting component determines whether the current time frame has been updated. If so, step S705 is executed; otherwise, step S707 is executed.

[0084] Step S705: The rate limiting component obtains the throughput threshold corresponding to the current time frame from the throughput calculation component.

[0085] Step S706: The rate limiting component resets the counter using the throughput threshold corresponding to the current time frame.

[0086] In step S707, the current limiting component decrements the counter by 1.

[0087] In step S708, the rate limiting component determines whether the throughput of the current time frame exceeds the throughput threshold. If so, step S710 is executed; otherwise, step S709 is executed.

[0088] In step S709, the rate limiting component sends the call request to the called system.

[0089] In step S710, the current limiting component waits for the next time frame.

[0090] In some embodiments, the RR acquisition component and the throughput calculation component obtain the throughput threshold corresponding to each time frame through the following steps:

[0091] Step S711: The RR acquisition component acquires the request and response data of the current time frame.

[0092] In step S712, the RR acquisition component calculates the average RR duration within the current time frame based on the request-response data.

[0093] Step S713: The RR acquisition component caches the average RR duration within the current time frame.

[0094] Step S714: The throughput calculation component reads the average RR duration of the current time frame and the previous time frame.

[0095] In step S715, the throughput calculation component obtains the RR gain of the current time frame based on the obtained average RR duration.

[0096] Step S716: The throughput calculation component obtains the RR gradient of the current time frame based on the RR gain and duration of the current time frame.

[0097] In step S717, the throughput calculation component determines the load status of the called system based on the RR gradient and overload coefficient of the current time frame.

[0098] In step S718, the throughput calculation component inputs the throughput thresholds of the current time frame and the previous p-1 historical time frames into the time series model to obtain the predicted throughput for the next time frame.

[0099] In step S719, the throughput calculation component determines the throughput threshold for the next time frame based on the load status of the called system and the predicted throughput for the next time frame.

[0100] Step S720: The throughput calculation component saves the throughput threshold for the next time frame.

[0101] Let's elaborate with a specific example, setting each time frame size L = 1s, the overload factor β = 100ms, the model order of the time series model p = 7, and the autocorrelation coefficient of the time series model... The white noise for the time series model can be any random number in the range [-1, 1]. The constant term of the time series model is 0.5. The expansion factor σ = 0.1, and the contraction factor τ = 0.15.

[0102] When the caller starts up, since there are no historical time frames at this time, the default throughput threshold of 30 is used. Since the time series model has a model order of 7, the throughput threshold for the first 7 time frames is 30, and the load status of the called system is stable at a normal level.

[0103] Upon entering the 8th time frame, the throughput calculation component inputs the throughput thresholds of the 1st to 7th time frames into the time series model to predict the throughput of the 8th time frame: X8 = 0.5*30 + 30*0.25 + 0.1*30 + 0.07*30 + 0.05*30 + 0.02*30 + 0.01*30 + rand(-1,1) + 0.5 = 30.39. Since the load state of the calling system is normal, the throughput threshold A8 = (1+σ)*X8 = 33.42 can be obtained by using the above formula (2). After removing the decimal places, the peak throughput in the 8th time frame is limited to 33, that is, the rate limiting component ensures that the rate limiting peak in the 8th time frame is 33.

[0104] In the 8th time frame, the RR acquisition component collects the average RR duration within that time frame. Compared to the 7th time frame, the average RR duration within this time frame remains unchanged, meaning the RR gain in the 8th time frame is 0. Therefore, it can be deduced that the load status of the called system is normal.

[0105] Entering the 9th time frame, the throughput calculation component inputs the throughput thresholds of the 2nd to 8th time frames into the time series model to predict the throughput of the 9th time frame: X9 = 0.5*33 + 30*0.25 + 0.1*30 + 0.07*30 + 0.05*30 + 0.02*30 + 0.01*30 + rand(-1,1) + 0.5 = 30.42. Since the load state of the calling system is normal, the throughput threshold A9 = (1+σ)*X9 = 36.76 can be obtained by using the above formula (2). After removing the decimal places, the peak throughput in the 9th time frame is limited to 36, that is, the rate limiting component ensures that the rate limiting peak in the 9th time frame is 36.

[0106] Similarly, in the 20th time frame, the RR acquisition component collects an average RR duration of 220ms, and the RR gradient within that time frame is 80. Since the RR gradient in the 20th time frame is less than the overload coefficient β and greater than zero, the load state of the called system is low load.

[0107] Entering the 21st time frame, the throughput calculation component inputs the throughput thresholds from the 14th to the 20th time frames into the time series model to predict the throughput X for the 21st time frame. 21 =0.5*X 20 +X 19 *0.25+0.1*X 18 +0.07*X 17 +0.05*X 16 +0.02*X 15 +0.01*X14 +rand(-1,1)+0.5=0.5*81.3+75*0.25+0.1*72+0.07*66+0.05*64+0.02*59+0.01*53+rand(-1,1)+0.5=83.21. Since the caller system is in a low-load state, the throughput threshold A of the 21st time frame can be obtained by using the above formula (2). 21 =X 21 =83.21, after removing the decimal places, the peak throughput in the 21st time frame is limited to 83, that is, the rate limiting component ensures that the rate limiting peak in the 21st time frame is 83.

[0108] In the 21st time frame, the RR acquisition component collects the average RR duration within that time frame. Since this exceeds the upper limit that the called system can handle, the average RR duration in the 21st time frame continues to increase, reaching 360ms. At this point, the RR gradient within that time frame is 140. Because the RR gradient in the 21st time frame is greater than the overload coefficient β, the called system is in a high-load state.

[0109] Entering the 22nd time frame, the throughput calculation component inputs the throughput thresholds from the 15th to the 21st time frames into the time series model to predict the throughput X for the 22nd time frame. 22 =0.5*X 21 +X 20 *0.25+0.1*X 19 +0.07*X 18 +0.05*X 17 +0.02*X 16 +0.01*X 15 +rand(-1,1)+0.5=0.5*83+81.3*0.25+0.1*75+0.07*72+0.05*66+0.02*64+0.01*59+rand(-1,1)+0.5=79.5. Since the caller system is under high load, the throughput threshold A of the 22nd time frame can be obtained by using the above formula (2). 22 =(1-τ)*X 22 =67.5. After removing the decimal places, the peak throughput in the 22nd time frame is limited to 67. That is, the rate limiting component ensures that the rate limiting peak in the 22nd time frame is 67.

[0110] In the 22nd time frame, the RR acquisition component collects the average RR duration within that time frame. Since this duration is below the upper limit that the called system can handle, the average RR duration in the 22nd time frame decreases to 100ms, and the RR gradient within this time frame is -260. Because the RR gradient in the 22nd time frame is less than 0, the load status of the called system is normal.

[0111] Entering the 23rd time frame, the throughput calculation component inputs the throughput thresholds from the 16th to the 22nd time frames into the time series model to predict the throughput X for the 23rd time frame. 23 =0.5*X 22 +X 21 *0.25+0.1*X 20 +0.07*X 19 +0.05*X 18 +0.02*X 17 +0.01*X 16 +rand(-1,1)+0.5=0.5*67+83*0.25+0.1*81+0.07*75+0.05*72+0.02*66+0.01*64+rand(-1,1)+0.5=73.5. Since the load status of the calling system is normal, the throughput threshold A of the 23rd time frame can be obtained by using the above formula (2). 23 = (1+σ)*X 23 =80, which limits the peak throughput in the 23rd time frame to 80, meaning the rate limiting component ensures that the rate limiting peak in the 23rd time frame is 80.

[0112] In this embodiment, the load status of the called system is determined based on the request-response characteristics between the calling system and the called system, and the predicted throughput of the calling system in the current time frame is obtained based on the historical throughput data of the calling system. Then, the throughput threshold of the calling system is determined using the load status of the called system and the predicted throughput of the calling system, and the throughput threshold is used to perform flow control on the calling system. This achieves rate limiting on the calling system side, effectively solving the IO resource occupation problem caused by repeated sending of call requests in traditional rate limiting schemes. Thus, the call requests of the calling system are fully satisfied, and the resource utilization is maximized while ensuring the stability of the called system.

[0113] Based on the same technical concept, this application provides a schematic diagram of the structure of a system current limiting device, such as... Figure 8 As shown, the device 800 includes:

[0114] The acquisition module 801 is used to acquire the request-response characteristics between the caller system and the callee system within the (i-1)th time frame;

[0115] The prediction module 802 is used to determine the load status of the called system based on the request-response characteristics; and to obtain the predicted throughput of the calling system in the i-th time frame based on the throughput data of the calling system in multiple historical time frames before the i-th time frame, where i is a positive integer greater than 1.

[0116] Processing module 803 is used to determine the throughput threshold of the calling system in the i-th time frame by using the load status of the called system and the predicted throughput;

[0117] The control module 804 is used to perform flow control on the call requests sent by the caller system to the callee system within the i-th time frame based on the throughput threshold.

[0118] Optionally, the acquisition module 801 is specifically used for:

[0119] Count the number of requests or responses between the calling system and the called system within the (i-1)th time frame;

[0120] The ratio of the duration of the (i-1)th time frame to the number of requests is used as the request response feature; or, the ratio of the duration of the (i-1)th time frame to the number of responses is used as the request return feature.

[0121] Optionally, the prediction module 802 is specifically used for:

[0122] Based on the request-response characteristics in the (i-1)th time frame and the request-response characteristics in the (i-2)th time frame, the request-response gain in the (i-1)th time frame is determined.

[0123] Based on the request-response gain within the (i-1)th time frame and the duration of the (i-1)th time frame, the request-response gradient within the (i-1)th time frame is determined;

[0124] Based on the correlation between the request response gradient and the preset overload coefficient, the load status of the called system is determined.

[0125] Optionally, the prediction module 802 is specifically used for:

[0126] If the request response gradient is greater than the overload coefficient, then the load state of the called system is determined to be a high load state.

[0127] If the request response gradient is less than or equal to the overload coefficient and greater than zero, then the load state of the called system is determined to be a low load state.

[0128] If the request response gradient is less than or equal to zero, then the load status of the called system is determined to be normal.

[0129] Optionally, the prediction module 802 is specifically used for:

[0130] The throughput data within the multiple historical time frames are input into a time series model for processing.

[0131] The predicted throughput is obtained using the time series model based on the throughput data within the multiple historical time frames and the autocorrelation coefficients corresponding to each of the multiple historical time frames.

[0132] Optionally, the prediction module 802 is specifically used for:

[0133] Based on the autocorrelation coefficients corresponding to each of the multiple historical time frames, the throughput data within the multiple historical time frames are weighted and summed to obtain candidate throughput.

[0134] The candidate throughput is adjusted using a preset constant term and zero-mean white noise to obtain the predicted throughput.

[0135] Optionally, the processing module 803 is specifically used for:

[0136] If the load state of the called system is high load, then the predicted throughput is adjusted using a shrinkage factor to obtain the throughput threshold.

[0137] If the load status of the called system is low, then the predicted throughput is used as the throughput threshold.

[0138] If the load status of the called system is normal, the predicted throughput is adjusted using an expansion factor to obtain the throughput threshold.

[0139] In this embodiment, the load status of the called system is determined based on the request-response characteristics between the calling system and the called system, and the predicted throughput of the calling system in the current time frame is obtained based on the historical throughput data of the calling system. Then, the throughput threshold of the calling system is determined using the load status of the called system and the predicted throughput of the calling system, and the throughput threshold is used to perform flow control on the calling system. This achieves rate limiting on the calling system side, effectively solving the IO resource occupation problem caused by repeated sending of call requests in traditional rate limiting schemes. Thus, the call requests of the calling system are fully satisfied, and the resource utilization is maximized while ensuring the stability of the called system.

[0140] Based on the same technical concept, embodiments of this application provide a computer device, which can be... Figure 1 The calling system shown is, for example Figure 9 As shown, it includes at least one processor 901 and a memory 902 connected to at least one processor. In this embodiment, the specific connection medium between the processor 901 and the memory 902 is not limited. Figure 9 Taking the connection between processor 901 and memory 902 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.

[0141] In this embodiment of the application, the memory 902 stores instructions that can be executed by at least one processor 901. By executing the instructions stored in the memory 902, at least one processor 901 can perform the steps of the above-described system current limiting method.

[0142] The processor 901 is the control center of the computer device, capable of connecting various parts of the computer device via various interfaces and lines. It implements system current limiting by running or executing instructions stored in the memory 902 and accessing data stored in the memory 902. Optionally, the processor 901 may include one or more processing units. The processor 901 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 901. In some embodiments, the processor 901 and the memory 902 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.

[0143] The processor 901 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0144] Memory 902, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 902 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 902 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer device, but is not limited thereto. In the embodiments of this application, memory 902 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0145] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the above-described system flow limiting method.

[0146] Those skilled in the art will understand that embodiments of the present invention can be provided as methods or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0147] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer apparatus or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0148] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer device or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0149] These computer program instructions may also be loaded onto a computer device or other programmable data processing equipment to cause a series of operational steps to be performed on the computer device or other programmable equipment to produce a process implemented by the computer device, thereby providing instructions that execute on the computer device or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0150] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0151] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A system current limiting method, characterized in that, The method is applied to the calling system, and the method includes: Obtain the request-response characteristics between the calling system and the called system within the (i-1)th time frame, wherein the request-response characteristics are the average request-response duration between the calling system and the called system within the (i-1)th time frame; Based on the request-response characteristics, the load status of the called system is determined; and based on the throughput data of the calling system in multiple historical time frames before the i-th time frame, the predicted throughput of the calling system in the i-th time frame is obtained, where i is a positive integer greater than 1. Using the load status of the called system and the predicted throughput, a throughput threshold for the calling system in the i-th time frame is determined. If the load status of the called system is high, a contraction factor is used to adjust the predicted throughput to obtain the throughput threshold. If the load status of the called system is low, the predicted throughput is used as the throughput threshold. If the load status of the called system is normal, an expansion factor is used to adjust the predicted throughput to obtain the throughput threshold. The expansion factor controls the growth rate of the sending speed of the call request in subsequent time frames, and the contraction factor controls the decrease rate of the sending speed of the call request in subsequent time frames. The value range of the contraction factor is [0.15, 0.20], and the value range of the expansion factor is [0.05, 0.15]. Based on the throughput threshold, flow control is performed on the call requests sent by the calling system to the called system within the i-th time frame; The step of determining the load status of the called system based on the request-response characteristics includes: determining the request-response gain in the (i-1)th time frame based on the request-response characteristics in the (i-1)th time frame and the request-response characteristics in the (i-2)th time frame; determining the request-response gradient in the (i-1)th time frame based on the request-response gain and the duration of the (i-1)th time frame; and determining the load status of the called system based on the correlation between the request-response gradient and a preset overload coefficient.

2. The method as described in claim 1, characterized in that, The step of obtaining the request-response characteristics between the calling system and the called system within the (i-1)th time frame includes: Count the number of requests or responses between the calling system and the called system within the (i-1)th time frame; The ratio of the duration of the (i-1)th time frame to the number of requests is used as the request-response feature; or, the ratio of the duration of the (i-1)th time frame to the number of responses is used as the request-response feature.

3. The method as described in claim 1, characterized in that, The determination of the load status of the called system based on the correlation between the request response gradient and a preset overload coefficient includes: If the request response gradient is greater than the overload coefficient, then the load state of the called system is determined to be a high load state. If the request response gradient is less than or equal to the overload coefficient and greater than zero, then the load state of the called system is determined to be a low load state. If the request response gradient is less than or equal to zero, then the load status of the called system is determined to be normal.

4. The method as described in claim 1, characterized in that, The step of obtaining the predicted throughput of the calling system in the i-th time frame based on throughput data from multiple historical time frames prior to the i-th time frame includes: The throughput data within the multiple historical time frames are input into a time series model for processing. The predicted throughput is obtained using the time series model based on the throughput data within the multiple historical time frames and the autocorrelation coefficients corresponding to each of the multiple historical time frames.

5. The method as described in claim 4, characterized in that, The step of obtaining the predicted throughput based on the throughput data within the multiple historical time frames and the autocorrelation coefficients corresponding to the throughput data within each of the multiple historical time frames includes: Based on the autocorrelation coefficients corresponding to each of the multiple historical time frames, the throughput data within the multiple historical time frames are weighted and summed to obtain candidate throughput. The candidate throughput is adjusted using a preset constant term and zero-mean white noise to obtain the predicted throughput.

6. A system current limiting device, characterized in that, Applied to the calling system; the device includes: The acquisition module is used to acquire the request-response characteristics between the calling system and the called system within the (i-1)th time frame, wherein the request-response characteristics are the average request-response duration between the calling system and the called system within the (i-1)th time frame; The prediction module is used to determine the load status of the called system based on the request-response characteristics; and to obtain the predicted throughput of the calling system in the i-th time frame based on the throughput data of the calling system in multiple historical time frames before the i-th time frame, where i is a positive integer greater than 1. The processing module is used to determine the throughput threshold of the calling system in the i-th time frame by using the load status of the called system and the predicted throughput; if the load status of the called system is high load, the predicted throughput is adjusted using a shrinkage factor to obtain the throughput threshold; if the load status of the called system is low load, the predicted throughput is used as the throughput threshold; if the load status of the called system is normal, the predicted throughput is adjusted using an expansion factor to obtain the throughput threshold; the expansion factor is used to control the growth rate of the sending speed of the call request in subsequent time frames, and the shrinkage factor is used to control the decrease rate of the sending speed of the call request in subsequent time frames; the value range of the shrinkage factor is [0.15, 0.20], and the value range of the expansion factor is [0.05, 0.15]. The control module is used to perform flow control on the call requests sent by the caller system to the callee system within the i-th time frame based on the throughput threshold. The prediction module is specifically used for: Based on the request-response characteristics in the (i-1)th time frame and the request-response characteristics in the (i-2)th time frame, the request-response gain in the (i-1)th time frame is determined. Based on the request-response gain within the (i-1)th time frame and the duration of the (i-1)th time frame, the request-response gradient within the (i-1)th time frame is determined; Based on the correlation between the request response gradient and the preset overload coefficient, the load status of the called system is determined.

7. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, It stores a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the method according to any one of claims 1 to 5.

Images