Flow fine control method and system

Abstract

The invention relates to the technical field of communication, in particular to a flow fine control method and system.The method comprises the steps that firstly, flow data of a system are collected in real time, the flow data comprise request frequency, response time, CPU utilization rate, memory utilization rate and thread pool utilization rate indexes, and then the token generation rate is dynamically adjusted based on a flow trend analysis result; generating tokens at regular time according to the adjusted rate, storing the tokens in a token bucket, and checking the state of the token bucket when a request is received: if available tokens exist, consuming the tokens and processing the request, otherwise, refusing or delaying the request, and when the system load exceeds a preset threshold value, triggering a fusing mechanism and pausing a non-key request; according to the method, the request number, the response time, the CPU utilization rate, the memory utilization rate and the thread pool utilization rate are collected in real time, and a mechanism for dynamically adjusting the token generation rate is combined, so that the load change of the system can be accurately sensed, and the problem of dynamic response lag is effectively solved.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method and system for fine-grained traffic control. Background Technology

[0002] In the field of distributed system flow control, existing technologies generally use static token bucket algorithms to implement rate limiting. These algorithms generate tokens at a fixed rate and determine the request allowance policy based on token availability. Some improved solutions introduce basic monitoring metrics (such as QPS thresholds) to trigger rate limiting rule switching, or adjust the token issuance amount through a simple linear formula.

[0003] Because static rules or simple threshold mechanisms cannot detect instantaneous changes in system load, such as a sudden surge in CPU utilization caused by traffic spikes or response time degradation caused by thread pool blocking, token generation rate adjustments are often delayed by several seconds or even minutes. This causes the system to continue issuing tokens at an excessively high rate during peak traffic periods, thereby exacerbating the risk of service avalanche. Meanwhile, during low traffic periods, excessively strict rate limiting leads to idle resources. Tests show that when sudden traffic increases by 300%, traditional solutions require 8-12 seconds to reduce the token generation rate to a safe level, at which point the system error rate exceeds 40%.

[0004] Therefore, to address the above problems, this invention proposes a refined traffic control method and system. By dynamically coupling traffic characteristics with system resource status, it achieves elastic adjustment of the token rate at the millisecond level and intelligently triggers a graded circuit breaker mechanism under overload scenarios, fundamentally solving the problem of response lag. Summary of the Invention

[0005] To overcome the problem that the dynamic response capability of existing technologies lags behind real-time traffic fluctuations, this invention proposes a refined traffic control method and system.

[0006] The technical solution of this invention is: a method for fine-grained flow control, comprising the following steps: Real-time collection of system traffic data, including request frequency, response time, CPU utilization, memory utilization, and thread pool utilization metrics; The token generation rate is dynamically adjusted based on traffic trend analysis results. Tokens are generated periodically according to the adjusted rate and stored in the token bucket; When receiving a request, check the token bucket status: if there are available tokens, consume the tokens and process the request; otherwise, reject or delay the request. When the system load exceeds a preset threshold, the circuit breaker mechanism is triggered, suspending non-critical requests.

[0007] Preferably, the dynamic adjustment of the token generation rate includes: when the request frequency is detected to be lower than a preset first threshold and the CPU utilization is lower than 50%, the token generation rate is increased linearly by 10%-30% of the base rate; when the response time exceeds the warning value specified in the service level agreement or the thread pool utilization reaches more than 80%, a step-by-step speed reduction strategy is used, reducing the current rate by 20%-40% each time, and the interval between two adjacent speed reduction operations is not less than 5 seconds; if the system load is lower than the recovery threshold for 10 seconds, the token generation rate is gradually pulled back to the initial base value, and the increase in each pullback process does not exceed 15%.

[0008] Preferably, the token generation process includes: triggering token generation at fixed intervals using an independent high-precision timer, with the number of tokens generated calculated using the dynamic formula N=BaseRate×(1-LoadFactor), where BaseRate is a baseline rate set based on the system's historical peak throughput, and LoadFactor is a real-time calculated load factor, which is the weighted average of the current memory utilization and thread pool utilization, with a weight ratio of 3:2. When a sudden increase in network latency is detected, a penalty factor of 0.1-0.3 is temporarily added to reduce the number of tokens generated until the latency returns to normal levels.

[0009] Preferably, the request processing procedure includes: allocating independent token buckets for different service types, with the core service token bucket having a fixed capacity of 40% of the total capacity and never being exhausted, while non-core services share the remaining 60% of the token pool. When a core service request arrives, it prioritizes consuming tokens from its dedicated token bucket. If the remaining amount in that token bucket is less than 10%, it is allowed to borrow redundant tokens from the non-core token bucket. Non-core requests can only consume tokens when the total remaining tokens in the system exceed a preset security threshold; otherwise, they directly enter a delay queue and wait for at least 200 milliseconds before retrying.

[0010] Preferably, the method further includes: receiving rate intervention commands manually input by the administrator through a graphical configuration interface; manually set parameters can immediately override the output value of the dynamically adjusted module; and automatically switching back to dynamic mode after the manual mode lasts for more than 30 minutes. When the circuit breaker mechanism is triggered, the system automatically records complete traffic metrics, resource usage data, and service call chain logs for 3 minutes before and after the trigger time, generates a protection report containing root cause analysis suggestions, and pushes notifications to operation and maintenance personnel through preset alarm policies. At the same time, it forces the token generation rate of non-core services to be reduced to zero until the load drops below the safety threshold.

[0011] As a preferred embodiment, a fine-grained flow control system includes: The traffic monitoring module collects request frequency, response time, and system load metrics in real time. The dynamic adjustment module calculates and adjusts the token generation rate based on monitoring data. The token generation module generates tokens at the adjusted rate and writes them to the token bucket. The request processing module verifies token availability and performs request pass / reject operations. The configuration management module provides a manual parameter configuration interface and a visual panel for the circuit breaker status.

[0012] Preferably, the traffic monitoring module includes a lightweight probe cluster and a trend analysis engine. The lightweight probe cluster collects local request frequency, response time, and thread pool status data in real time through kernel-level packet capture technology. The probes maintain state synchronization through a heartbeat mechanism. The trend analysis engine uses a sliding window with a configurable duration of 5-60 seconds to statistically analyze traffic characteristics. When the standard deviation of the request volume within the window exceeds twice the historical average, it is determined to be a traffic mutation point. It also combines an exponential smoothing algorithm to predict the load peak in the next 15 seconds. The prediction results are input into the dynamic adjustment module in real time.

[0013] Preferably, the token generation module includes a rate controller and a high-concurrency token bucket. The rate controller is a PID controller that receives rate instructions from the dynamic adjustment module and converts the rate deviation value into a timer trigger interval adjustment amount. The high-concurrency token bucket uses a lock-free circular queue structure. The queue slots access tokens through CAS atomic operations. The time taken for a single operation is stable at 10-50 microseconds. The queue capacity supports dynamic expansion during runtime and can be expanded up to 3 times the initial capacity. The expansion operation is completed in batches during periods of low token consumption.

[0014] Preferably, the request processing module includes a token verifier and a hierarchical processing unit. The token verifier intercepts and extracts the service identifier before request routing and locates the corresponding token bucket through hash mapping. The hierarchical processing unit allocates independent token channels for core financial transaction services and reserves 40% of the total token quota. When the core channel tokens are insufficient, it automatically borrows no more than 20% of the redundant tokens from the non-core bucket. Non-core e-commerce requests must wait for the public token pool to reach more than 30% before consumption. Low-priority media streaming requests are forcibly delayed for 300 milliseconds before entering the secondary verification queue.

[0015] Preferably, the dynamic adjustment module includes a circuit breaker trigger and an adaptive regulator. The circuit breaker trigger sends a circuit breaker command to the request processing module and closes the non-core service token channel when the CPU utilization is >90% for 30 seconds or the memory overflow error rate is >5 times per minute. The adaptive regulator stores traffic pattern data for the most recent 72 hours, generates a rate limiting parameter prediction model through LSTM neural network training, and dynamically optimizes the load coefficient weight ratio and step-down speed reduction in the rate adjustment algorithm every 2 hours. The optimization results take effect after being verified by A / B testing.

[0016] The beneficial effects of this invention are: 1. This invention can accurately sense changes in system load by collecting real-time request counts, response times, CPU utilization, memory utilization, and thread pool utilization, and by combining a mechanism for dynamically adjusting the token generation rate, thereby effectively solving the problem of dynamic response lag.

[0017] 2. By monitoring traffic metrics in real time and dynamically adjusting the token generation rate, the system can quickly reduce token issuance when traffic surges, avoiding request backlog and service avalanche caused by delayed adjustments in traditional solutions. When the system load exceeds a preset threshold, the system automatically triggers a circuit breaker mechanism to prioritize core services and suspend non-critical requests, thereby preventing overall service unavailability due to resource exhaustion. During periods of low load, the system automatically increases the token generation rate, thereby avoiding unnecessary request restrictions, making full use of system resources, and improving overall throughput. Attached Figure Description

[0018] Figure 1 The diagram shown illustrates the workflow of this invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] This invention provides an embodiment: a method for fine-grained flow control, comprising the following steps: The system's request frequency, response time, CPU utilization, memory utilization, and thread pool utilization are collected in real time by a traffic monitoring module. Based on the collected data, the current traffic trend is dynamically analyzed and token rate adjustment instructions are generated. The token generation module generates tokens periodically according to the adjusted rate and stores them in a token bucket. When the request processing module receives a service request, it checks the availability of tokens in the token bucket. If an available token exists, it immediately consumes the token and allows the request; otherwise, it rejects or delays the request. At the same time, the dynamic adjustment module continuously monitors the system load status. When CPU or memory utilization exceeds a preset threshold, a circuit breaker mechanism is automatically triggered to suspend the processing of non-core requests. This invention achieves millisecond-level dynamic adaptation of traffic control and system load. Compared with static rate limiting schemes, it reduces the system error rate under burst traffic by more than 60%. At the same time, the intelligent circuit breaker mechanism improves the availability guarantee of core services to 99.99%, and increases resource utilization by 35%-50% during low traffic periods.

[0021] Furthermore, the dynamic adjustment of the token generation rate includes: when the traffic monitoring module detects that the request frequency is lower than a preset first threshold and the CPU utilization is lower than 50%, the dynamic adjustment module increases the token generation rate linearly to accelerate token issuance and thus improve system throughput. When the response time exceeds the warning value specified by the SLA or the thread pool utilization reaches 80% or more, the dynamic adjustment module immediately starts a step-by-step speed reduction strategy, gradually reducing the current token generation rate by 20%-40%, and ensuring the stability of the speed reduction operation through a 5-second time interval, thereby avoiding drastic rate drops. In the event of severe fluctuations, if the system load remains below the recovery threshold for 10 seconds, the token generation rate will automatically be reverted to the initial baseline value. The reverting process will use a gradual increase of no more than 15% to prevent traffic rebound. This invention, through quantitative adjustment ratios and a tiered control mechanism, enables the token generation rate to accurately match the real-time load status of the system. In the event of sudden traffic surges, the response time of the rate limiting strategy can be shortened from 8-12 seconds in traditional solutions to 1-3 seconds. At the same time, it avoids resource idleness caused by excessive rate limiting, reduces the system throughput fluctuation range by more than 60%, and the tiered speed reduction design effectively prevents service jitter caused by sudden rate drops.

[0022] Furthermore, the token generation process includes: triggering token generation at fixed intervals using an independent high-precision timer; the number of tokens generated is calculated using the dynamic formula N=BaseRate×(1-LoadFactor), where BaseRate is a baseline rate set based on the system's historical peak throughput, and LoadFactor is a real-time calculated load factor, the weighted average of current memory utilization and thread pool utilization, with a weight ratio of 3:2. When a sudden increase in network latency is detected, a temporary penalty factor of 0.1-0.3 is applied to reduce the number of tokens generated until the latency returns to normal. This invention quantifies system load indicators into precise mathematical parameters, achieving dynamic matching between the token generation rate and the system's actual carrying capacity. When memory utilization reaches 70%, it can automatically reduce the number of tokens generated by 30-45%, and suppress sudden traffic by 40-60% during periods of deteriorating network latency. Simultaneously, due to the use of an independent timer triggering mechanism, it avoids the token generation delay problem caused by excessive system load in traditional solutions, while ensuring that the timeliness error of rate limiting control is always less than 50 milliseconds, enabling the system to maintain stable service quality even under high load.

[0023] Furthermore, the request processing process includes: allocating independent token buckets for different service types; the core service token bucket capacity is fixed at 40% of the total capacity and never runs out; non-core services share the remaining 60% of the token pool; when a core service request arrives, it first consumes tokens from its dedicated token bucket; if the remaining amount in that token bucket is less than 10%, it is allowed to borrow redundant tokens from the non-core token bucket; non-core requests can only consume tokens when the total remaining tokens in the system exceed a preset security threshold; otherwise, they directly enter a delay queue and wait for at least 200 milliseconds before retrying. This invention, through hierarchical quotas and dynamic borrowing mechanisms, ensures that core services can still obtain a minimum of 40%+20% token guarantee under high load, while avoiding excessive consumption of system resources by non-core requests, thus achieving the best balance between service hierarchical protection and efficient resource utilization.

[0024] Furthermore, the system receives manually input rate intervention commands from administrators through a graphical configuration interface. Manually set parameters can immediately override the output values ​​of the dynamically adjusted module. The system automatically switches back to dynamic mode after 30 minutes in manual mode. When the circuit breaker mechanism is triggered due to system load exceeding the threshold, the system automatically records complete traffic metrics, resource usage data, and service call chain logs for 3 minutes before and after the trigger. A built-in analysis engine generates a system protection report containing root cause analysis and handling suggestions. Simultaneously, multi-level alarms (SMS / email / DingTalk) are pushed to operations personnel according to preset policies. During circuit breaker operation, the system forcibly reduces the token generation rate of non-core services to zero until the load drops below the safety threshold, while maintaining a minimum guaranteed rate for core services. This invention, through a closed-loop processing mechanism of "automatic recording - intelligent analysis - tiered response," enables operations personnel to quickly locate the root cause of overload. The 30-minute automatic rollback mechanism avoids long-term performance impacts caused by human error. Combined with circuit breaker suppression measures for non-core services, it significantly improves the availability of core services during overload, reduces fault recovery time by more than 60%, and significantly improves the controllability and recovery efficiency of the system under abnormal conditions.

[0025] A fine-grained flow control system includes: The traffic monitoring module collects request frequency, response time, and system load metrics in real time. The dynamic adjustment module calculates and adjusts the token generation rate based on monitoring data. The token generation module generates tokens at the adjusted rate and writes them to the token bucket. The request processing module verifies token availability and performs request pass / reject operations. The configuration management module provides a manual parameter configuration interface and a visual panel for the circuit breaker status.

[0026] Furthermore, the traffic monitoring module includes a lightweight probe cluster and a trend analysis engine. The lightweight probe cluster collects local request frequency, response time, and thread pool status data in real time through kernel-level packet capture technology. The probes maintain state synchronization through a heartbeat mechanism. The trend analysis engine uses a sliding window with a configurable time length of 5-60 seconds to statistically analyze traffic characteristics. When the standard deviation of the request volume within the window exceeds twice the historical average, it is determined to be a traffic mutation point. It also combines an exponential smoothing algorithm to predict the load peak in the next 15 seconds. The prediction results are input into the dynamic adjustment module in real time.

[0027] Furthermore, the token generation module includes a rate controller and a high-concurrency token bucket. The rate controller is a PID controller that receives rate instructions from the dynamic adjustment module and converts the rate deviation value into a timer trigger interval adjustment amount. The high-concurrency token bucket uses a lock-free circular queue structure. The queue slots store and retrieve tokens through CAS atomic operations. The time taken for a single operation is stable at 10-50 microseconds. The queue capacity supports dynamic expansion during runtime and can be expanded up to 3 times the initial capacity. The expansion operation is completed in batches during the low token consumption period.

[0028] Furthermore, the request processing module includes a token verifier and a hierarchical processing unit. The token verifier intercepts and extracts the service identifier before request routing and locates the corresponding token bucket through hash mapping. The hierarchical processing unit allocates independent token channels for core financial transaction services and reserves 40% of the total token quota. When the core channel tokens are insufficient, it automatically borrows no more than 20% of the redundant tokens from the non-core bucket. Non-core e-commerce requests must wait for the public token pool to reach more than 30% before consumption. Low-priority media streaming requests are forcibly delayed for 300 milliseconds before entering the secondary verification queue.

[0029] Furthermore, the dynamic adjustment module includes a circuit breaker trigger and an adaptive regulator. The circuit breaker trigger sends a circuit breaker command to the request processing module and closes the non-core service token channel when the CPU utilization is >90% for 30 seconds or the memory overflow error rate is >5 times per minute. The adaptive regulator stores traffic pattern data for the most recent 72 hours, generates a rate limiting parameter prediction model through LSTM neural network training, and dynamically optimizes the load coefficient weight ratio and step-down speed reduction in the rate adjustment algorithm every 2 hours. The optimization results take effect after being verified by A / B testing.

[0030] Please see Figure 1 Furthermore, the workflow of this invention will be described as follows: The system first collects the request frequency, response time, CPU utilization, memory utilization and thread pool utilization of each node in real time through a distributed probe cluster. It uses a sliding window algorithm to calculate traffic trends. When the standard deviation of the request frequency exceeds twice the historical average, it is marked as a traffic mutation point. At the same time, it uses an exponential smoothing algorithm to predict the load peak in the next 15 seconds. All monitoring data is transmitted to the dynamic adjustment module with a latency of milliseconds.

[0031] The dynamic adjustment module calculates the load factor (60% weight for memory utilization + 40% weight for thread pool utilization) based on the received monitoring data. When the load factor exceeds 0.7, a step-by-step speed reduction strategy is initiated, reducing the current token generation rate by 20-40% each time with a 5-second interval. When a sudden increase in network latency is detected, a penalty factor of 0.1-0.3 is temporarily added. 40% of the token quota is always reserved for core services, and a 20% redundant token borrowing mechanism for non-core buckets is activated when the remaining amount in its dedicated token bucket is less than 10%.

[0032] The PID controller controls the token distribution rhythm by adjusting the trigger interval of the high-precision timer according to the rate command issued by the dynamic adjustment module. The generated tokens are then stored in the token bucket of the lockless circular queue structure. The queue uses CAS atomic operations to achieve millisecond-level access (10-50μs / time). When the traffic continues to increase, the queue capacity will be dynamically expanded, with a maximum expansion of 3 times. The expansion operation is completed in batches during the low period of token consumption to avoid performance fluctuations.

[0033] After the token validator in the API gateway layer intercepts a request, it first identifies the service type (core / non-core). Core requests directly consume the dedicated token bucket, while non-core requests need to verify whether the total token balance in the system exceeds 20%. When there are insufficient tokens, core requests can borrow redundant tokens from the non-core bucket, while non-core requests enter a delay queue and wait for 200ms to retry. If the CPU usage is detected to be >90% for 30 seconds, a circuit breaker is triggered, and the token issuance for all non-core requests is immediately suspended.

[0034] After the circuit breaker is triggered, the system automatically records complete operational data for the three minutes before and after the circuit breaker is triggered. This data includes traffic metrics, resource snapshots, and call chain logs. The system analyzes the data using an LSTM model to generate a root cause report and simultaneously pushes three-level alarms (SMS -> Email -> DingTalk) to operations and maintenance personnel. Administrators can manually override the rate parameters through a graphical interface. All manually set parameters will automatically fail and revert to dynamic mode after 30 minutes. When the load drops to a safe threshold, the system will gradually restore the issuance of non-core service tokens at a rate of 15% per minute.

[0035] Furthermore, the present invention provides an embodiment for e-commerce promotional scenarios: During the "Double 11" promotion on e-commerce platforms, the system detected a surge in instantaneous request volume from 5,000 QPS to 25,000 QPS and CPU utilization exceeding 85%. The dynamic adjustment module immediately initiated a three-tiered speed reduction (30% per instance), reducing the token generation rate from 8,000 tokens / second to 2,744 tokens / second within 3 seconds. Simultaneously, it triggered a 40% token reservation mechanism for core transaction services, ensuring that the success rate of core interfaces such as payment orders remained at 99.92%. Non-core services such as product reviews were automatically placed in a delayed queue. During this period, over 20,000 token verifications per second were achieved through CAS atomic operations of the circular token bucket. The system load dropped back below the safety threshold within 10 seconds, reducing order loss by 46% compared to traditional solutions.

[0036] Furthermore, this invention provides an embodiment for a financial system disaster recovery scenario: When the bank's core transaction system is subjected to a DDoS attack, the traffic monitoring module detects abnormal request characteristics and dynamically adjusts the module to load a pre-trained LSTM model. Within 200 milliseconds, the token generation rate of suspicious IP segments is reduced to zero, while maintaining a 50% base token quota for legitimate transaction requests. The circuit breaker mechanism automatically records attack characteristics and generates protection strategy suggestions. As a result, even when the system is subjected to more than 500% of the normal traffic, the average response time of the core transfer business is still controlled within 300ms. The attack defense response speed is 8 times faster than traditional solutions.

[0037] Furthermore, the present invention provides an embodiment in a cloud computing resource scheduling scenario: During the nighttime idle period of computing resources on a certain cloud platform, when the CPU utilization rate is less than 30%, the system automatically increases the token generation rate to the baseline value of 150%, thereby allowing batch job tasks to fully utilize idle resources. When business requests suddenly surge during the morning peak, the dynamic adjustment module immediately triggers the penalty factor (0.25) and restricts the issuance of tokens for non-critical tasks by monitoring the thread pool utilization rate in real time, which rises from 40% to 90% within 10 seconds. This reduces resource contention for the core virtual machine creation service by 70%. At the same time, by utilizing the dynamic expansion feature of the token bucket, the processing capacity is smoothly expanded from 2000 QPS to 6000 QPS within 1 minute.

[0038] By taking the above steps and collecting real-time data on request count, response time, CPU utilization, memory utilization, and thread pool utilization, combined with a mechanism that dynamically adjusts the token generation rate, the system load changes can be accurately detected, thus solving the problem of dynamic response lag in existing technologies.

Claims

1. A method of flow refinement control, characterized by, The method comprises the following steps: Real-time acquisition of system traffic data, including request frequency, response time, CPU utilization, memory utilization, and thread pool utilization indicators; Dynamic adjustment of token generation rate based on traffic trend analysis results; Timely generation of tokens at the adjusted rate and storage in the token bucket; When receiving a request, check the token bucket status: if there are available tokens, consume the tokens and process the request, otherwise reject or delay the request; When the system load exceeds the preset threshold, trigger the fuse mechanism to suspend non-critical requests.

2. The method of claim 1, wherein, The dynamic adjustment of the token generation rate includes: when the request frequency is monitored to be lower than the preset first threshold and the CPU utilization is lower than 50%, the token generation rate is increased by a linear proportion, and the increase amplitude is 10%-30% of the base rate; when the response time exceeds the warning value specified in the service level agreement or the thread pool utilization rate reaches 80% or above, a stepwise speed reduction strategy is used, each time the current rate is reduced by 20%-40%, and the interval between adjacent two speed reduction operations is not less than 5 seconds; if the system load continues to be lower than the recovery threshold for 10 seconds, the token generation rate is gradually adjusted to the initial base value, and the adjustment process increases by no more than 15% each time.

3. The method of claim 1, wherein, The token generation process includes: triggering token generation by an independent high-precision timer at a fixed period, and the generation quantity is calculated by a dynamic formula N=BaseRate×(1-LoadFactor), wherein BaseRate is the base rate set according to the historical peak throughput of the system, and LoadFactor is the real-time calculated load factor, which is the weighted average value of the current memory utilization and thread pool utilization, and the weight ratio is 3:2, and when a sudden increase in network delay is detected, a penalty factor of 0.1-0.3 is temporarily added to reduce the generation quantity of tokens until the delay returns to normal level.

4. The method of claim 1, wherein, The request processing process includes: allocating independent token buckets for different service types, the capacity of the core service token bucket is fixed at 40% of the total capacity and never depleted, and the remaining 60% of the token pool is shared by non-core services, when a core service request arrives, tokens are consumed from its exclusive token bucket, if the remaining amount of the token bucket is less than 10%, the redundant tokens of the non-core token bucket can be borrowed, and non-core requests can only consume tokens when the total token remaining amount exceeds the preset safety threshold, otherwise they directly enter the delay queue and wait for at least 200 milliseconds before retrying.

5. The method of claim 1, wherein, The method further comprises: receiving the rate intervention instructions manually input by the administrator through the graphical configuration interface, the manually set parameters can immediately override the output values of the dynamic adjustment module, and the manual mode is automatically switched back to the dynamic mode after more than 30 minutes, when the fuse mechanism is triggered, the system automatically records the complete traffic indicators, resource occupation data and service call chain logs within 3 minutes before and after the triggering time, generates a protection report containing root cause analysis suggestions, and pushes a notification to the operation and maintenance personnel through the preset alarm strategy, and forcibly sets the token generation rate of non-core services to zero until the load decreases below the safety threshold.

6. A flow refinement control system employing a flow refinement control method according to any one of claims 1 to 6, characterized by The method comprises the following steps: A traffic monitoring module that acquires request frequency, response time, and system load indicators in real time; The dynamic adjustment module calculates a token generation rate adjustment strategy based on the monitoring data; The token generation module generates tokens at the adjusted rate and writes them into the token bucket; The request processing module checks token availability and performs request pass / reject operations; The configuration management module provides a manual parameter configuration interface and a fuse state visualization panel.

7. The flow refinement control system of claim 6, wherein: The traffic monitoring module includes a lightweight probe cluster and a trend analysis engine. The lightweight probe cluster collects local request frequency, response time, and thread pool state data in real time through kernel-level packet capture technology. The probes keep state synchronization through a heartbeat mechanism. The trend analysis engine uses a sliding window with a configurable length of 5-60 seconds to calculate traffic characteristics. When the standard deviation of the request volume in the window exceeds twice the historical mean, it is determined to be a traffic mutation point. In combination with the exponential smoothing algorithm, the peak load in the next 15 seconds is predicted. The prediction result is input into the dynamic adjustment module in real time.

8. The flow refinement control system of claim 6, wherein: The token generation module includes a rate controller and a high-concurrency token bucket. The rate controller receives the rate instruction from the dynamic adjustment module and converts the rate deviation value into a timer trigger interval adjustment amount. The high-concurrency token bucket uses a ring queue structure with lock-free design. The queue slots access tokens through CAS atomic operations. The time consumption of a single operation is stable at 10-50 microseconds. The queue capacity supports dynamic expansion at runtime, and can be expanded to 3 times the initial capacity. The expansion operation is completed in batches during the low consumption period of tokens.

9. The flow refinement control system of claim 6, wherein: The request processing module includes a token verifier and a hierarchical processing unit. The token verifier intercepts and extracts service identifiers before request routing, locates the corresponding token bucket through hash mapping, and the hierarchical processing unit allocates independent token channels for financial transaction core services and fixes 40% of the total token quota. When the core channel token is insufficient, it automatically borrows no more than 20% of the redundant tokens from the non-core bucket. E-commerce non-core requests need to wait for the public token pool to reach more than 30% before being allowed to consume. Media stream low-priority requests are forced to delay for 300 milliseconds before entering the secondary verification queue.

10. The flow refinement control system of claim 6, wherein: The dynamic adjustment module includes a fuse trigger and an adaptive regulator. When the CPU utilization rate is continuously greater than 90% for 30 seconds or the memory overflow error rate is greater than 5 times per minute, the fuse trigger sends a fuse instruction to the request processing module and closes the non-core service token channel. The adaptive regulator stores traffic pattern data for the last 72 hours, generates a flow limiting parameter prediction model through LSTM neural network training, dynamically optimizes the load coefficient weight ratio and step-down amplitude in the rate adjustment algorithm every 2 hours, and the optimization result takes effect after A / B test verification.

Images