Flow limiting method and system for burst flow, electronic equipment and medium

Abstract

The invention discloses a traffic limiting method and system for burst traffic, electronic equipment and a medium, and the method specifically comprises the steps: obtaining an access request, extracting a lightweight feature of the access request, and determining an instant reputation weight according to the lightweight feature; based on the instant reputation weight and the real-time load factor, obtaining a dynamic request price corresponding to the access request; and comparing the dynamic request price with a budget limit of an associated account of the access request, and determining whether to accept the access request according to a comparison result. According to the method provided by the embodiment of the invention, a dynamic decision-making mechanism fusing the reputation of the access request and the system load is constructed, the defect that a traditional static flow limiting strategy cannot adaptively distinguish the request risk and cannot be linked with the system state for regulation and control is overcome, and the stability of the system under burst flow is more guaranteed.

Description

Technical Field

[0001] This invention relates to the fields of data processing and network communication, and in particular to a method, system, electronic device, and medium for limiting burst traffic. Background Technology

[0002] In scenarios such as e-commerce platform promotions, ticket-buying sprees, or breaking news events, network service systems often experience a surge in access requests far exceeding normal levels within a short period—a phenomenon known as traffic spikes. To ensure the stable operation of backend services and the effective utilization of system resources, rate limiting systems are typically deployed as the first line of defense. Existing rate limiting solutions mainly employ static strategies (such as fixed thresholds), whose fundamental flaw lies in their simplistic and rigid decision-making logic. This makes it impossible to reasonably distinguish between legitimate and malicious requests and allocate appropriate system resources when faced with sudden traffic spikes. Summary of the Invention

[0003] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention proposes a method, system, electronic device, and medium for limiting burst traffic, providing a way to rationally allocate data during burst traffic events.

[0004] A method for limiting burst traffic according to a first aspect embodiment of the present invention includes: Obtain access requests and extract lightweight features of the access requests, and determine instant reputation weights based on the lightweight features; Based on the instant reputation weight and real-time load factor, obtain the dynamic request price corresponding to the access request; The price of the dynamic request is compared with the budget limit of the account associated with the access request, and a decision is made on whether to accept the access request based on the comparison result.

[0005] The embodiments of the present invention have at least the following beneficial effects: The burst traffic limiting method provided by the present invention determines the real-time reputation weight of access requests by extracting features, calculates the dynamic request price by combining it with real-time load factors, and finally compares the price with the account budget to decide whether to accept the access request. This method constructs a dynamic decision-making mechanism that integrates the reputation of access requests and system load, solving the shortcomings of traditional static rate limiting strategies that cannot adaptively distinguish request risks and adjust in conjunction with system status, thus making the system more stable under burst traffic.

[0006] According to some embodiments of the present invention, the step of obtaining an access request and extracting lightweight features of the access request, and determining an instant reputation weight based on the lightweight features, includes: Extract the lightweight features of the access request, wherein the lightweight features include whether the device fingerprint identifier appears for the first time, the IP address affiliation, the registration duration of the associated account, and the number of requests within a preset time period; The lightweight features are input into a linear weighted logistic regression model, and the instantaneous reputation weights are output by the linear weighted logistic regression model.

[0007] According to some embodiments of the present invention, after the steps of obtaining the access request and extracting the lightweight features of the access request, and determining the instant reputation weight based on the lightweight features, the method further includes: If the instant reputation weight corresponding to the access request is lower than the preset reputation threshold, then based on the exploration and utilization strategy, the access request is exploratoryly allowed to obtain exploration feedback signals; Based on the exploration feedback signal, the weight parameters of the linear weighted logistic regression model are adjusted in real time.

[0008] According to some embodiments of the present invention, the step of performing exploratory clearance on the access request to obtain exploratory feedback signals includes: Add a tracking identifier to the access request and allow it to pass; obtain positive or negative feedback signals based on the processing results of the downstream services of the access request. Alternatively, a human verification can be returned to the source of the access request, and a positive or negative feedback signal can be obtained based on the result of the human verification.

[0009] According to some embodiments of the present invention, the step of obtaining the dynamic request price corresponding to the access request based on the instant reputation weight and the real-time load factor includes: Obtain the system monitoring metrics of the system server and perform normalization processing to generate the real-time load factor; The instantaneous reputation weight is processed based on a monotonically decreasing function to obtain the reputation adjustment coefficient; The dynamic request price is generated based on the reputation adjustment coefficient and the real-time load factor.

[0010] According to some embodiments of the present invention, the step of determining whether to accept the access request based on the comparison result includes: If the budget of the associated account of the access request is not lower than the dynamic request price, the access request is allowed and the dynamic request price is deducted from the budget. If the budget limit of the associated account for the access request is lower than the dynamic request price, the access request is rejected.

[0011] According to some embodiments of the present invention, after the step of deducting the dynamic request price from the budget amount, the method further includes: When the preset reset conditions are met, the budget limit of the associated account is reset based on the historical average credit weight of the associated account.

[0012] A burst flow limiting system according to a second aspect embodiment of the present invention includes: The reputation scoring module acquires access requests and extracts lightweight features of the access requests, and determines real-time reputation weights based on the lightweight features. The dynamic pricing module is used to obtain the dynamic request price corresponding to the access request based on the instant reputation weight and real-time load factor. The access control module is used to compare the price of the dynamic request with the budget limit of the account associated with the access request, and decide whether to accept the access request based on the comparison result.

[0013] An electronic device according to a third aspect of the present invention includes a memory and a processor, the memory being used to store at least one program, and the processor being used to load the at least one program to execute the burst traffic limiting method described in the above-described aspect embodiments.

[0014] A computer-readable storage medium according to a fourth aspect of the present invention includes a memory and a processor, the memory being configured to store at least one program, and the processor being configured to load the at least one program to perform the burst traffic limiting method described in the above-described aspect embodiments.

[0015] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0016] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart of a method for limiting burst traffic according to an embodiment of the present invention; Figure 2 This is a structural diagram of a flow limiting system for burst traffic according to an embodiment of the present invention; Figure 3 This is a structural diagram of an electronic device provided in another embodiment of the present invention. Detailed Implementation

[0017] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0018] In the description of this invention, "several" means one or more, "multiple" means two or more, "greater than," "less than," "exceeding," etc. are understood to exclude the stated number, and "above," "below," "within," etc. are understood to include the stated number. If "first," "second," etc. are used in the description, they are only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance or implicitly indicating the number of indicated technical features or the order of the indicated technical features.

[0019] The concepts involved in this invention are explained below: Token Bucket Algorithm: This algorithm simulates the system's processing capacity by using a virtual "bucket" that generates tokens at a constant rate. Each arriving request must acquire and consume one (or a fixed number) tokens from the bucket before it can be allowed to proceed. If there are not enough tokens in the bucket, the request is immediately rejected or put on hold. The Sigmoid function is an S-shaped function that maps any real number to the interval (0, 1).

[0020] Please refer to Figures 1-2 , Figure 1 This is a flowchart of a method for limiting burst traffic according to an embodiment of the present invention. This embodiment discloses a method for limiting burst traffic, which includes, but is not limited to, the following steps: Step S100: Obtain the access request and extract the lightweight features of the access request, and determine the instant reputation weight based on the lightweight features. It should be noted that an access request refers to a network request initiated by a client or user terminal, aimed at calling or obtaining backend services, data, or resources, such as API calls, HTTP requests, or business operation instructions. In this embodiment of the invention, an access request specifically refers to any network transaction that needs to be determined by the rate limiting system to determine whether it is allowed to reach the backend service. When an access request reaches the server's gateway, the server will extract the lightweight features of the access request. Specifically, the lightweight features in this embodiment of the invention are relevant data that can be quickly extracted directly from the access request without complex calculations or external queries. In step S100, based on the real-time reputation weight obtained from the lightweight features, the trustworthiness of the associated account of the access request is characterized, realizing real-time risk quantification assessment of a single request.

[0021] Step S200: Based on the instant reputation weight and real-time load factor, obtain the dynamic request price corresponding to the access request; It should be noted that the real-time load factor includes server system resource-related parameters such as CPU utilization, memory usage, or the length of the request processing queue. Step S200 integrates the instantaneous reputation weight for assessing the request's reputation status with the real-time load factor for assessing the system-level resource status to generate a dynamic request price that adapts to request risk and system pressure, enabling dynamic adaptive adjustment of the rate limiting intensity. This allows the system server to automatically raise the service threshold to protect system stability when the load increases, and lower the threshold to improve resource utilization efficiency when the load decreases.

[0022] Step S300: Compare the dynamic request price with the budget limit of the associated account for the access request, and decide whether to accept the access request based on the comparison result.

[0023] It should be noted that the budget allocation mechanism in this embodiment of the invention is similar to the token bucket algorithm, but fundamentally different. In the traditional token bucket, each request consumes a fixed number of tokens, and the decision is simply a Boolean judgment of "have / have not have" tokens. However, in this embodiment of the invention, the request consumes a dynamic request price calculated based on the real-time reputation weight of the associated account and the real-time load factor of the system server. The decision becomes an assessment of whether the budget of the associated account is sufficient to cover the real-time cost. This fundamental difference upgrades the rate limiting method from simple rate control to a multi-dimensional decision-making method that integrates the reputation of the access account and the system load. This solves the problem that traditional static rate limiting strategies, which use fixed thresholds, cannot adaptively differentiate request risks and adjust in conjunction with system status, thus ensuring greater stability of the system under sudden traffic surges.

[0024] Furthermore, step S100 in the above-described embodiments also includes, but is not limited to, the following steps: Step S110: Extract the lightweight features of the access request, wherein the lightweight features include whether the device fingerprint identifier appears for the first time, the IP address affiliation, the registration duration of the associated account, and the number of requests within a preset time period; Step S120: Input the lightweight features into the linear weighted logistic regression model, and the linear weighted logistic regression model outputs the instantaneous reputation weights.

[0025] It should be noted that in steps S110 to S120, by selecting lightweight features with low computational overhead and using a linear weighted logistic regression model with few parameters and fast inference, the original request features are mapped to a standardized reputation score (i.e., instant reputation weight) within millisecond-level latency. This ensures that the risk identification process itself will not become a bottleneck for system performance under high concurrency traffic, and provides real-time and reliable input for the subsequent dynamic pricing process.

[0026] In one embodiment of the invention, the scoring model may employ a linear weighted logistic regression model, whose weight parameters are updated in real time by an online learning mechanism. Specifically, the instantaneous reputation weight... The calculation method is as follows: ...Form ①, in, Used to characterize whether a device fingerprint appears for the first time (Boolean value, first time = 1, repeat = 0). Used to characterize the reputation level of the region to which an IP belongs (for example, it can be divided into three levels, each with a different numerical mapping, such as 1.0 / 0.6 / 0.3). This is used to represent the normalized value of account registration duration (e.g., unit: days, 0~1). Used to characterize the inverse of the short-term request interval (reflecting operation frequency), a, b, c, and d are the weight parameters for the corresponding parameters. Here, is the Sigmoid function, and e is the bias term of the model.

[0027] In addition, after step S100 in the above-described embodiments, the following steps are included, but are not limited to: Step S130: If the real-time reputation weight corresponding to the access request is lower than the preset reputation threshold, then based on the exploration and exploitation strategy, the access request is allowed to proceed in an exploratory manner in order to obtain exploration feedback signals. Step S140: Adjust the weight parameters of the linear weighted logistic regression model in real time based on the exploration feedback signal.

[0028] It should be noted that in steps S130-S140, when the immediate reputation weight corresponding to an access request obtained based on the linear weighted logistic regression model is lower than the preset reputation threshold, it indicates that the model's risk assessment has a high degree of uncertainty. At this point, the system does not directly reject the access request, but instead initiates exploratory access, allowing the system server to actively obtain exploratory feedback signals (positive or negative) corresponding to the access request execution process. These exploratory feedback signals are used to adjust the weight parameters of the logistic regression model in real time, thereby achieving real-time adjustment of the weights of each parameter in the linear weighted logistic regression model. This mechanism enables the method provided in this embodiment of the invention not only to combat malicious attacks, but also to effectively prevent widespread false rejections caused by initial model bias when facing novel benign traffic patterns triggered by a large number of benign users that the model has not yet encountered. This improves the system's adaptability to the evolution of normal traffic patterns and service availability while ensuring security.

[0029] In one embodiment of the present invention, the exploration decision module adopts an ε-greedy multi-armed slot machine algorithm, randomly selecting low-reputation requests with a probability ε (e.g., 0.05) to perform exploration operations. Specifically, it executes a conventional exploitation strategy with a probability of (1-ε); updates the expected returns of each action with the exploration results (positive and negative feedback); and adjusts ε in real time after updating the strategy so that it gradually decays to 0.01 after the system stabilizes.

[0030] Furthermore, step S130 in the above-described embodiments also includes, but is not limited to, the following steps: Step S131: Add a tracking identifier to the access request and allow it to pass. Obtain a positive or negative feedback signal based on the processing result of the downstream business of the access request. Step S132, or, return human verification to the source of the access request, and obtain positive or negative feedback signals based on the result of the human verification.

[0031] It should be noted that the exploration operations in steps S131-S132 may include: directly allowing the request while attaching a tracking identifier to it. Subsequently, if the session corresponding to the request successfully completes the core business (such as submitting an order), the business system will asynchronously send a positive feedback signal; if the request is judged as malicious behavior by the downstream risk control system, a negative feedback signal will be sent. A human-machine recognition challenge, such as a simple graphic CAPTCHA or a proof-of-work-based computation task, is returned to the source of the access request; if the client corresponding to the associated account successfully completes the challenge, a positive feedback signal is generated, otherwise a negative feedback signal is generated. It can be understood that after obtaining a positive feedback signal, the server will correspondingly increase the weight parameters related to the request feature in the linear weighted logistic regression model, thereby increasing the immediate reputation weight of such requests; conversely, after obtaining a negative feedback signal, it will decrease the corresponding weight parameters to reduce the immediate reputation weight of such requests.

[0032] In one embodiment of the present invention, the system server uses online logistic regression as a reputation estimator, with single-sample asynchronous updates. The updates are completed asynchronously in the message channel and take effect immediately, ensuring high concurrency feasibility.

[0033] Furthermore, step S200 in the above-described embodiments also includes, but is not limited to, the following steps: Step S210: Obtain the system monitoring indicators of the system server and perform normalization processing to generate the real-time load factor; Step S220: The instant reputation weight is processed based on a monotonically decreasing function to obtain the reputation adjustment coefficient; Step S230: Generate the dynamic request price based on the reputation adjustment coefficient and the real-time load factor.

[0034] It should be noted that step S210 normalizes heterogeneous monitoring metrics such as CPU utilization, memory usage, and request queue length ratio into a scalar factor representing the system stress level; step S220 uses a monotonically decreasing function to convert the instantaneous reputation weight representing request risk into a negatively correlated adjustment coefficient, i.e., the higher the risk, the lower the coefficient; step S230 merges these two independent variables, which are derived from system state and request attributes respectively, to obtain a dynamic request price that simultaneously responds to resource supply and risk demand, thus achieving an adaptive balance between system load and business security in the rate limiting strategy.

[0035] In one embodiment of the present invention, the load factor base(load) can be obtained by linearly normalizing system monitoring metrics. For example: base(load)=f×CPU_ratio+g×Mem_ratio+h×Qlen_norm······Equation ②, In Equation ②, CPU_ratio is the CPU utilization rate, Mem_ratio is the memory usage rate, Qlen_norm is the proportion of the request queue length, and f, g, and h are the preset adjustable weights of the corresponding parameters.

[0036] Furthermore, the dynamic request price p is obtained as follows: p = base(load) × f( Formula ③ Where f( ) is about A monotonically decreasing function, for example, f(w) = exp(k × (1- k is an adjustment constant, which allows for the implementation of reputation weights. The lower the value, the higher the price p; the higher the system load base (load), the higher the base price.

[0037] Furthermore, this embodiment of the invention also includes a protection mode based on a real-time load factor, whereby the final dynamic request price is doubled when the base (load) is greater than a preset threshold.

[0038] Furthermore, step S300 in the above-described embodiments also includes, but is not limited to, the following steps: Step S310: If the budget of the associated account of the access request is not lower than the dynamic request price, the access request is allowed and the dynamic request price is deducted from the budget. Step S320: If the budget limit of the associated account for the access request is lower than the dynamic request price, the access request is rejected.

[0039] It should be noted that in this embodiment of the invention, each access request's associated account has an initial budget limit T. Steps S310 and S320, based on the binary judgment condition of "whether the budget limit is sufficient to pay the dynamic price," combine all dynamic variables (instant reputation weight) generated in the above embodiments. The real-time load factor (base(load)) and dynamic request price (p) are transformed into final, deterministic, and executable control commands (allow or deny). Upon allowing the request, the corresponding cost is deducted in real time, updating the account balance of the associated account to Tp. This mechanism ensures that the budget consumption of an account strictly corresponds to resource usage, thereby achieving precise resource allocation and control based on real-time accounting at the system level.

[0040] Understandably, the budget limit T is related to a user's long-term reputation history, but independent of the immediate reputation weight w of a single access request. The system can set higher initial token limits for users with high long-term reputation during the user registration or behavior accumulation phase. ,like: =T_base×(1+ ×w_avg)······Form ④, In formula ④, The preset adjustment coefficient is used; w_avg is the average reputation weight of the past N visits. In each real-time rate limiting decision, T is compared with the current... Independent comparison, current It is not included in the calculation of w_avg.

[0041] In addition, after step S310 in the above-described embodiments, the following steps are included, but are not limited to: Step S311: When the preset reset conditions are met, the budget limit of the associated account is reset based on the historical average credit weight of the associated account.

[0042] It should be noted that steps S311-S312 replenish the budget T of the associated account after deducting the dynamic request price p, to ensure that the next visit by a bona fide visitor is not affected. Specifically, after the traffic returns to normal levels, it is reset based on the average reputation weight of the past N visits (i.e., the historical average reputation weight), that is, the budget Tp of the associated account after deducting the dynamic request price is smoothly replenished in the short term through formula ④. .

[0043] Reference Figure 2 , Figure 2This invention provides another embodiment of a burst traffic limiting system, which is used to execute the burst traffic limiting method of the above-described aspects of the invention. The system includes: The reputation scoring module acquires access requests and extracts lightweight features of the access requests, and determines real-time reputation weights based on the lightweight features. The dynamic pricing module is used to obtain the dynamic request price corresponding to the access request based on the instant reputation weight and real-time load factor. The access control module is used to compare the price of the dynamic request with the budget limit of the account associated with the access request, and decide whether to accept the access request based on the comparison result.

[0044] It should be noted that the reputation scoring module is used to obtain access requests from clients and realize real-time risk quantification for individual access requests; the dynamic pricing module integrates this risk with the global system load status to form a dynamic cost; and the access control module executes the final economic accounting decision based on the cost-budget model.

[0045] Furthermore, this embodiment of the invention also includes an exploration decision module and a model update module. The exploration decision module is activated at the initial stage of system startup. For requests whose calculated real-time reputation weight is lower than a preset reputation threshold, the exploration decision module, based on a multi-armed slot machine strategy, decides to perform an exploration operation with a small probability. The exploration operation obtains exploration feedback signals by either allowing the access request or returning human-machine verification to the associated user. The model update module is responsible for asynchronously processing the above feedback signals. This module uses the received exploration feedback signals (positive or negative) as labels, the feature vector of the corresponding request as training samples, and uses online learning algorithms (such as online logistic regression) to adjust the weight parameters of the reputation scoring model in real time.

[0046] The following is an overall embodiment of the present invention: When an access request arrives at the gateway, the reputation scoring module is activated first. This module extracts lightweight features of the request, such as: whether the device fingerprint identifier is appearing for the first time, whether the requesting IP address belongs to a known cloud service provider or data center, the time interval distribution of consecutive requests within a short time window, and the registration duration of the user account associated with the request. Subsequently, the module performs a weighted calculation on the above features based on an internally stored scoring model and outputs an initial reputation weight. ,in The range of values ​​can be normalized to [0, 1].

[0047] Next, the dynamic pricing module intervenes. This module retrieves the initial reputation weight calculated in the previous step. , and obtain a real-time load factor base(load) from the system monitoring service. This load factor can be proportional to the CPU usage rate of the system, the memory occupancy rate, or the length of the request processing queue. The dynamic request price p can be calculated by the formula p = base(load) × f( ), where f( ) is a monotonically decreasing function of , for example, f(w) = exp(k × (1 - )), and k is an adjustment constant. In this way, the lower the reputation weight , the higher the price p; the higher the system load base(load), the higher the base price.

[0048] At the initial stage of system startup, the exploration decision module is activated. For requests with an initially calculated reputation weight w lower than a preset threshold (such as 0.3), this module decides to perform exploration operations on them with a small probability (such as ε = 0.05) according to the Multi-armed Bandit strategy. Exploration operations may include: (1) Directly release the request and attach a tracking identifier to it. Subsequently, if the session corresponding to this request finally successfully completes the core business (such as submitting an order), the business system will asynchronously send a positive feedback signal; if the request is determined to be malicious by the downstream risk control system, a negative feedback signal will be sent.

[0049] (2) Return a human-machine recognition challenge to the request source, such as a simple graphic verification code or a calculation task based on Proof-of-Work. If the user successfully completes the challenge, a positive feedback signal will be generated.

[0050] The model update module is responsible for asynchronously processing the above feedback signals. This module uses the received feedback signal (positive or negative) as a label, uses the feature vector of the corresponding request as a training sample, and uses an online learning algorithm (such as online logistic regression) to adjust the weight parameters of the reputation scoring model in real time. The updated model parameters will take effect immediately and be used for the scoring of subsequent requests.

[0051] Finally, the access control module makes the final decision. For each request (whether it is a high-reputation request or a low-reputation request not selected as an exploration object), this module will obtain its calculated dynamic request price p and query the token balance T held by the user account associated with this request. If T >= p, it is determined that the request passes, the request is accepted, and the account balance is updated to T - p. If T < p, the request is rejected, and a status code indicating that the service is busy (such as HTTP429) can be returned to the client.

[0052] Through the above implementation methods, the present invention constructs an intelligent rate limiting closed-loop system that can sense, learn and adapt to traffic changes in real time, thereby optimizing the allocation of resources among requests of different reputation levels while ensuring system stability.

[0053] like Figure 3 As shown, Figure 3 This is a structural diagram of an electronic device provided in one embodiment of the present invention. The present invention also provides an electronic device, comprising: The processor 801 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 802 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 802 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 802 and is called and executed by the processor 801 to execute the burst traffic limiting method of the embodiments of this application. The 803 input / output interface is used to implement information input and output. The communication interface 804 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 805 transmits information between various components of the device (e.g., processor 801, memory 802, input / output interface 803, and communication interface 804); The processor 801, memory 802, input / output interface 803, and communication interface 804 are connected to each other within the device via bus 805.

[0054] It should be noted that the electronic device executing the rate limiting method for burst traffic in the embodiments of the present invention includes, but is not limited to, independent servers, server clusters, virtual computing instances in cloud service platforms, and edge computing servers. The client issuing the access request includes any electronic device that can be used to execute the method, such as mobile devices and computer devices. The present invention does not impose specific limitations on this.

[0055] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof. The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate, and may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0056] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically include computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0057] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A method for limiting burst traffic, characterized in that, include: Obtain access requests and extract lightweight features of the access requests, and determine instant reputation weights based on the lightweight features; Based on the instant reputation weight and real-time load factor, obtain the dynamic request price corresponding to the access request; The price of the dynamic request is compared with the budget limit of the account associated with the access request, and a decision is made on whether to accept the access request based on the comparison result.

2. The method for limiting burst traffic according to claim 1, characterized in that, The steps of obtaining access requests and extracting lightweight features from the access requests, and determining real-time reputation weights based on the lightweight features, include: Extract the lightweight features of the access request, wherein the lightweight features include whether the device fingerprint identifier appears for the first time, the IP address affiliation, the registration duration of the associated account, and the number of requests within a preset time period; The lightweight features are input into a linear weighted logistic regression model, and the instantaneous reputation weights are output by the linear weighted logistic regression model.

3. The method for limiting burst traffic according to claim 1, characterized in that, After the steps of obtaining the access request and extracting the lightweight features of the access request, and determining the instant reputation weight based on the lightweight features, the method further includes: If the instant reputation weight corresponding to the access request is lower than the preset reputation threshold, then based on the exploration and utilization strategy, the access request is exploratoryly allowed to obtain exploration feedback signals; Based on the exploration feedback signal, the weight parameters of the linear weighted logistic regression model are adjusted in real time.

4. The method for limiting burst traffic according to claim 3, characterized in that, The step of performing exploratory clearance on the access request to obtain exploratory feedback signals includes: Add a tracking identifier to the access request and allow it to pass; obtain positive or negative feedback signals based on the processing results of the downstream services of the access request. Alternatively, a human verification can be returned to the source of the access request, and a positive or negative feedback signal can be obtained based on the result of the human verification.

5. The method for limiting burst traffic according to claim 1, characterized in that, The step of obtaining the dynamic request price corresponding to the access request based on the real-time reputation weight and real-time load factor includes: Obtain the system monitoring metrics of the system server and perform normalization processing to generate the real-time load factor; The instantaneous reputation weight is processed based on a monotonically decreasing function to obtain the reputation adjustment coefficient; The dynamic request price is generated based on the reputation adjustment coefficient and the real-time load factor.

6. The method for limiting burst traffic according to claim 1, characterized in that, The step of deciding whether to accept the access request based on the comparison result includes: If the budget of the associated account of the access request is not lower than the dynamic request price, the access request is allowed and the dynamic request price is deducted from the budget. If the budget limit of the associated account for the access request is lower than the dynamic request price, the access request is rejected.

7. The method for limiting burst traffic according to claim 6, characterized in that, After the step of deducting the dynamic request price from the budget amount, the method further includes: When the preset reset conditions are met, the budget limit of the associated account is reset based on the historical average credit weight of the associated account.

8. A flow limiting system for sudden traffic surges, characterized in that, include: The reputation scoring module acquires access requests and extracts lightweight features of the access requests, and determines real-time reputation weights based on the lightweight features. The dynamic pricing module is used to obtain the dynamic request price corresponding to the access request based on the instant reputation weight and real-time load factor. The access control module is used to compare the price of the dynamic request with the budget limit of the account associated with the access request, and decide whether to accept the access request based on the comparison result.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory being used to store at least one program, and the processor being used to load the at least one program to execute the burst traffic limiting method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the burst traffic limiting method as described in any one of claims 1 to 7.

Images