Distributed counting interface current limiting method based on Redsson under high concurrency

Abstract

The invention discloses a distributed counting interface flow limiting method based on Redsson under high concurrency, relates to the technical field of flow monitoring, and solves the problems that flow limiting fails due to competitive conditions under a high concurrency scene, implementation complexity is increased due to manual management of counter reset, and a system is unavailable due to a flow limiting service fault. The interface flow limiting method comprises the following steps: acquiring an HTTP (Hyper Text Transport Protocol) request of a back-end interface through an interceptor, counting and extracting data features of the HTTP request by utilizing a dynamic time window, and generating an interface flow feature vector; constructing a flow-limiting self-learning monitoring model according to the interface flow feature vector; carrying out multi-modal traffic classification and self-adaptive traffic-limiting label generation on the HTTP request by utilizing a traffic-limiting self-learning monitoring model; performing dynamic current limiting parameter configuration and elastic capacity expansion and contraction on each back-end interface according to the self-adaptive current limiting label; and carrying out global consistency verification on the request times of the back-end interface and the dynamic full-limit current limiting value, and then scheduling an interceptor to carry out current limiting on the back-end interface.

Description

Technical Field

[0001] The present invention relates to the technical field of traffic monitoring, and in particular to an interface current limiting method based on Redisson distributed counting under high concurrency. Background Art

[0002] With the prevalence of microservice architectures, traditional single-node rate limiting (such as semaphores or thread pool isolation) is unable to achieve global traffic control in a multi-node environment. For example, when scheduled tasks are deployed across multiple machines, concurrently pulling data can cause a surge in pressure on downstream services, and single-node rate limiting cannot calculate the total number of requests across nodes. In this case, a rate limiting mechanism that can coordinate across machines is needed to ensure that the overall request rate of the cluster is controllable.

[0003] Redis's high performance, atomic operations, and distributed nature make it an ideal platform for implementing distributed rate limiting. Redisson, a Java client for Redis, encapsulates complex operations (such as Lua script execution), simplifying the development process. Its RRateLimiter interface uses a token bucket algorithm combined with Redis's key expiration mechanism to achieve precise rate control within a time window.

[0004] Beyond gateway-level rate limiting (such as Spring Cloud Gateway) or platform-level tools (such as Sentinel), businesses often need to independently control rate limiting logic. For example, this requires dynamically adjusting the QPS thresholds for different interfaces or supporting bursty traffic scenarios. Redisson's rate limiter allows you to dynamically set the token generation rate and bucket capacity using the trySetRate() method, without relying on an external monitoring platform, providing greater flexibility.

[0005] Patent No. CN202211018936.8 discloses a method, device, electronic device and readable storage medium for real-time traffic monitoring. After obtaining the data traffic reported by each client, each data traffic is added to the created redisson delay queue, and the addition time when each data traffic is added is recorded. For each data traffic, the expiration time is obtained based on the addition time and the set delay time, and the data traffic is moved to the created blocking queue when the expiration time of the data traffic arrives. At the same time, the traffic information of the data traffic in the redisson delay queue is obtained by real-time monitoring. In the above scheme, each data traffic leaves the queue according to the delay time after being added to the redisson delay queue. The window corresponding to the redisson delay queue remains unchanged. With the data traffic as a reference, the window slides in reverse in real time. There is no problem of monitoring loopholes, which can ensure the accuracy of traffic monitoring.

[0006] Patent No. CN202211345923.1 discloses a method, system, device and storage medium for implementing distributed business locks. The method includes: in response to receiving a request to call a lock interface to add a distributed exclusive lock or a distributed shared lock to a resource, using Redisson to add a distributed lock to the resource; in response to the successful locking of the Redisson distributed lock, querying whether there is other lock data; in response to the absence of other lock data, directly adding a distributed exclusive lock or a distributed shared lock to the resource; and in response to the existence of other lock data, determining whether to perform the operation of adding a distributed exclusive lock or a distributed shared lock to the resource based on the duration and scope of the other lock data. The above invention provides shared locks and exclusive locks based on the Redisson distributed lock, thereby realizing the functions of distributed shared locks and distributed exclusive locks.

[0007] However, the existing single-machine current limiting and basic distributed current limiting used in the above patents cannot achieve unified current limiting in a distributed environment under high concurrency scenarios. The current limiting logic itself may become a system performance bottleneck and is difficult to adapt to the expansion needs of distributed systems. Current limiting fails due to competition conditions in high concurrency scenarios, manual management of counter reset increases the implementation complexity, and current limiting service failure causes system unavailability. Summary of the Invention

[0008] The purpose of the present invention is to provide an interface current limiting method based on Redisson's distributed counting under high concurrency, which can ensure the high availability of the current limiting service by combining the distributed characteristics of Redis and the efficient encapsulation of Redisson; utilize global unified current limiting to overcome the limitations of single-machine current limiting and realize unified current limiting in a distributed environment.

[0009] The present invention utilizes the following technical solutions: A method for limiting interface current based on Redisson distributed counting under high concurrency, comprising the following steps: S1: Obtain HTTP requests from the backend interface through the interceptor, and use dynamic time window statistics and extract data features of HTTP requests to generate interface traffic feature vectors; S2: Build a current limiting self-learning monitoring model based on the interface traffic feature vector; S3: Utilizes the rate limiting self-learning monitoring model to perform multimodal traffic classification and generate adaptive rate limiting labels for HTTP requests. S4: Dynamically configure current limiting parameters and elastically scale capacity for each backend interface based on the adaptive current limiting label. S5: Perform a global consistency check on the number of requests to the backend interface and the dynamic global current limit value, and then schedule the interceptor to limit the current of the backend interface.

[0010] Preferably, step S1 includes the following steps: S11: intercept the HTTP request of the backend interface through the interceptor, extract the interface identifier, request timestamp, backend address code and request traffic data; S12: Use Redisson's RAtomicLong and RMapCache to perform distributed statistics on HTTP requests and obtain the number of requests; S13: Split the dynamic time window into several sub-time windows based on the multi-level time slice mechanism. RBatch is used to update the request counts of each sub-time window in batches in parallel based on the time window expiration mechanism. S14: Store the request counts for each sub-time window in the Redis Cluster and dynamically adjust the window length using the trySetRate interface of RRateLimiter. At the same time, compress the request traffic data of the historical sub-time windows and store it in the time series database. S15: Calculate the error rate, concurrency, throughput, number of threads, time per second, transactions per second, and response time of HTTP requests in real time through sub-time windows to generate interface traffic feature vectors.

[0011] Preferably, the feature extraction layer of the current limiting self-learning monitoring model uses a time series feature algorithm to calculate the mean, variance and autocorrelation coefficient of the interface traffic feature vector in each sub-time window, and uses a cumulative sum algorithm to perform burst detection on the interface traffic feature vector; the learning and training layer is based on the sparse expert model architecture and, according to a preset time interval, it iterates the interface traffic feature vector, mean, variance and autocorrelation coefficient in combination with preset training rules for several times, and uses the FTRL optimizer to update the weight parameters, and uses Redisson's RTopic publish-subscribe mode to synchronize the weight parameters to obtain a comprehensive weight matrix; the inference output layer uses the ONNX Runtime tool in combination with the code solver MathCoder to deploy and infer the comprehensive weight matrix.

[0012] Preferably, step S3 includes the following steps: S31: The learning and training layers of the current limiting self-learning monitoring model include the residual network, InceptionV3 network, and DarkNet network; S32: extracting data features from the request traffic data of the HTTP request to obtain a traffic feature value; S33: Input the traffic feature values into the residual network, the InceptionV3 network, and the DarkNet network respectively for gradient iterative training to obtain a first traffic feature matrix, a second traffic feature matrix, and a third traffic feature matrix; S34: The first traffic feature matrix, the second traffic feature matrix, and the third traffic feature matrix are combined with a voting weight mechanism to obtain an interface traffic feature vector. S35: Combine the interface traffic feature vector with the confidence threshold, input it into the inference output layer, and perform inference mapping with the comprehensive weight matrix to obtain the interface traffic category. The interface traffic category includes normal, suspicious, and malicious. S36: Automatically generates graded traffic limiting labels based on the interface traffic category; graded traffic limiting labels include unlimited, gradient traffic limiting threshold, and global traffic limiting ban; S37: Shared interface traffic categories and hierarchical current limiting tags through Redisson's RSetCache.

[0013] Preferably, in step S4, if the hierarchical current limiting label is unlimited, the back-end interface sampling time of each sub-time window is extended; if the hierarchical current limiting label is a gradient current limiting threshold, the request count of each sub-time window is elastically calculated to obtain the number of requests in the dynamic time window, and at the same time, the token bucket rate is dynamically modified using the trySetRate interface of RRadateLimiter in Redisson, and the limited sub-time window and back-end interface are updated through RLock; if the hierarchical current limiting label is a global current limiting ban, the current limiting trigger rate of the back-end interface is judged: if the current limiting trigger rate is less than or equal to 30%, the current back-end interface scanning capacity is maintained; if the current limiting trigger rate is greater than 30%, the Kubernetes API is automatically called to expand the current back-end interface scanning capacity, and synchronized to the dynamic time window through Redisson's RSemaphore.

[0014] Preferably, in step S5, if the error between the number of requests and the dynamic global current limiting value is greater than or equal to 5%, a 429 status code and a retry time are sent to the back-end interface, and the request is directly rejected and recorded in the blacklist. The back-end address code is filtered through Redisson's RBitSet, and then the interceptor is scheduled to limit the back-end interface, and the limited back-end interface request is forwarded to the static cache server; if the error between the number of requests and the dynamic global current limiting value is less than 5%, the request traffic data is stored through Redisson's RTimeSeries.

[0015] The present invention combines the distributed nature of Redis with the efficient encapsulation of Redisson to ensure the high availability of the current limiting service. It utilizes global unified current limiting to overcome the limitations of single-machine current limiting and achieve unified current limiting in a distributed environment. It avoids competition conditions in high-concurrency scenarios through atomic operations and ensures the accuracy of the current limiting logic. It simplifies the management of time windows by automatically resetting the counter through Redis's TTL. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0017] Figure 1 This is the principle block diagram of the interface current limiting method; Figure 2 This is a flowchart of the interface current limiting method. DETAILED DESCRIPTION

[0018] The present invention is described in detail below with reference to the accompanying drawings and embodiments: like Figure 1-Figure 2 As shown, the interface current limiting method based on Redisson distributed counting under high concurrency described in the present invention includes the following steps in sequence: S1: Obtain HTTP requests from the backend interface through the interceptor, and use dynamic time window statistics and extract data features of HTTP requests to generate interface traffic feature vectors; S2: Build a current limiting self-learning monitoring model based on the interface traffic feature vector; S3: Utilizes the rate limiting self-learning monitoring model to perform multimodal traffic classification and generate adaptive rate limiting labels for HTTP requests. S4: Dynamically configure current limiting parameters and elastically scale capacity for each backend interface based on the adaptive current limiting label. S5: Perform a global consistency check on the number of requests to the backend interface and the dynamic global current limit value, and then schedule the interceptor to limit the current of the backend interface.

[0019] In the present invention, step S1 includes the following steps: S11: intercept the HTTP request of the backend interface through the interceptor, extract the interface identifier, request timestamp, backend address code and request traffic data; S12: Use Redisson's RAtomicLong and RMapCache to perform distributed statistics on HTTP requests and obtain the number of requests; In this example, RAtomicLong implements atomic addition and subtraction operations based on Redis's INCR and DECR commands. This prevents data inconsistencies in counting operations in high-concurrency scenarios. Due to Redis's distributed nature, RAtomicLong can be used for atomic counting across multiple nodes, making it ideal for distributed systems. Thanks to Redis's high performance, RAtomicLong excels when handling highly concurrent requests.

[0020] RMapCache is a Redis-based distributed mapping structure, similar to the Java Map interface, for storing key-value pairs. It combines the mapping functionality of RMap with the cache expiration feature, allowing you to set an expiration time for each key-value pair. Once the data expires, the key-value pair is automatically removed from the cache. Based on Redis's hash structure, RMapCache delivers high performance when handling large amounts of data and high concurrency.

[0021] S13: Split the dynamic time window into several sub-time windows based on the multi-level time slice mechanism. RBatch is used to update the request counts of each sub-time window in batches in parallel based on the time window expiration mechanism. In this embodiment, RBatch is an important tool in Redisson for batch processing of Redis commands. Through pipeline and transaction technology, it can effectively reduce network latency and improve system performance.

[0022] S14: Store the request counts for each sub-time window in the Redis Cluster and dynamically adjust the window length using the trySetRate interface of RRateLimiter. At the same time, compress the request traffic data of the historical sub-time windows and store it in the time series database. In this example, Redis Cluster is the official distributed solution provided by Redis, primarily used to address performance and capacity bottlenecks in single-node Redis instances. Redisson's RRateLimiter is a distributed rate limiter used to control resource access frequency. In scenarios where rate limiting is required, call the trySetRate API to obtain a token. If true is returned, execution is allowed; if false is returned, execution is denied or other processing is performed.

[0023] S15: Calculate the error rate, concurrency, throughput, number of threads, time per second, transactions per second, and response time of HTTP requests in real time through sub-time windows to generate interface traffic feature vectors.

[0024] In the present invention, the feature extraction layer of the current limiting self-learning monitoring model uses a time series feature algorithm to calculate the mean, variance and autocorrelation coefficient of the interface traffic feature vector in each sub-time window, and uses a cumulative sum algorithm to perform burst detection on the interface traffic feature vector; the learning and training layer is based on the sparse expert model architecture and, according to a preset time interval, it iterates the interface traffic feature vector, mean, variance and autocorrelation coefficient in combination with preset training rules for several times, and uses the FTRL optimizer to update the weight parameters, and uses Redisson's RTopic publish-subscribe mode to synchronize the weight parameters to obtain a comprehensive weight matrix; the inference output layer uses the ONNX Runtime tool in combination with the code solver MathCoder to deploy and infer the comprehensive weight matrix.

[0025] In this embodiment, RTopic is a component based on the publish / subscribe (pub / sub) model implemented by Redis, and is used to implement message publishing and subscription in a distributed system.

[0026] In the present invention, step S3 includes the following steps: S31: The learning and training layers of the current limiting self-learning monitoring model include the residual network, InceptionV3 network, and DarkNet network; S32: extracting data features from the request traffic data of the HTTP request to obtain a traffic feature value; S33: Input the traffic feature values into the residual network, the InceptionV3 network, and the DarkNet network respectively for gradient iterative training to obtain a first traffic feature matrix, a second traffic feature matrix, and a third traffic feature matrix; S34: The first traffic feature matrix, the second traffic feature matrix, and the third traffic feature matrix are combined with a voting weight mechanism to obtain an interface traffic feature vector. S35: Combine the interface traffic feature vector with the confidence threshold, input it into the inference output layer, and perform inference mapping with the comprehensive weight matrix to obtain the interface traffic category. The interface traffic category includes normal, suspicious, and malicious. In this embodiment, normal traffic refers to regular interactive data initiated by legitimate users or systems that meets business expectations and has a reasonable request frequency, protocol specifications, and data format. For example, legitimate users' web browsing, standard API calls, and standard protocol communication between devices; Suspicious traffic is traffic that deviates from normal behavior patterns but has not yet been clearly determined to be malicious. It may contain potential risks or tentative attack behaviors. For example: frequent API calls in a short period of time, abnormal port access, non-standard protocol requests, etc.; Malicious traffic is traffic with clear attack intent or destructive behavior, designed to steal data, disrupt services, or bypass security mechanisms. Examples include SQL injection, DDoS attacks, brute force cracking, malware propagation, etc. S36: Automatically generates graded traffic limiting labels based on the interface traffic category; graded traffic limiting labels include unlimited, gradient traffic limiting threshold, and global traffic limiting ban; In this embodiment, "unrestricted" means no active restriction measures are imposed on the interface or service traffic, allowing all requests to pass at their natural rate. This is suitable for scenarios with sufficient system resources and no need for traffic control. Gradient throttling is a multi-level threshold strategy that dynamically adjusts the throttling level based on traffic pressure. For example: Primary Threshold: triggers an alarm or delays request processing (such as delayed response to an API request); Intermediate Threshold: partially rejects requests (such as dropping 20% of traffic from an overclocked IP); Advanced Threshold: strictly limits the rate (such as reducing the number of requests per second to 50% of the system's carrying capacity). Global traffic limiting and blocking is an extreme protection measure that completely blocks traffic on a specific interface or globally. It is suitable for emergency scenarios such as malicious attacks and resource exhaustion.

[0027] S37: Shared interface traffic categories and hierarchical current limiting tags through Redisson's RSetCache.

[0028] In this embodiment, RSetCache is a distributed cache collection based on Redis. It inherits from RSet and adds a cache elimination mechanism to support setting expiration time for elements in the collection.

[0029] In the present invention, in step S4, if the hierarchical current limiting label is unlimited, the backend interface sampling time of each sub-time window is extended; if the hierarchical current limiting label is a gradient current limiting threshold, the request count of each sub-time window is elastically calculated to obtain the number of requests in the dynamic time window, and at the same time, the token bucket rate is dynamically modified using the trySetRate interface of RRadateLimiter in Redisson, and the limited sub-time window and backend interface are updated through RLock; if the hierarchical current limiting label is a global current limiting ban, the current limiting trigger rate of the backend interface is judged: if the current limiting trigger rate is less than or equal to 30%, the current backend interface scanning capacity is maintained; if the current limiting trigger rate is greater than 30%, the Kubernetes API is automatically called to expand the current backend interface scanning capacity, and synchronized to the dynamic time window through Redisson's RSemaphore.

[0030] In this example, RLock is a powerful and easy-to-use distributed lock suitable for a variety of distributed scenarios. Through a simple API, locks can be quickly acquired and released. It also supports features such as reentrancy and fair locking, effectively improving the reliability and concurrency control capabilities of distributed systems. RSemaphore is a distributed semaphore mechanism based on Redis, similar to Semaphore in Java, but supports distributed environments.

[0031] In the present invention, in step S5, if the error between the number of requests and the dynamic global current limit value is greater than or equal to 5%, a 429 status code and a retry time are sent to the back-end interface, and the request is directly rejected and recorded in the blacklist. The back-end address code is filtered through Redisson's RBitSet, and then the interceptor is scheduled to limit the back-end interface, and the limited back-end interface request is forwarded to the static cache server; if the error between the number of requests and the dynamic global current limit value is less than 5%, the request traffic data is stored through Redisson's RTimeSeries.

[0032] In this implementation, RTimeSeries allows users to store data points associated with timestamps in Redis. Each data point contains a timestamp and a value. Data can be retrieved based on a time range or the number of recent data points, making it suitable for real-time monitoring and data analysis. Data is stored using Redis's sorted sets, ensuring efficient data insertion and retrieval.

[0033] RBitSet is a distributed and scalable bit vector (BitSet) tool based on Redis, used to efficiently store and operate binary data.

[0034] Example: The interceptor intercepts HTTP requests from the backend interface and extracts the interface identifier, request timestamp, backend address code, and request traffic data. Redisson's RAtomicLong and RMapCache are used to perform distributed statistics on HTTP requests to obtain the number of requests. The dynamic time window is split into several sub-time windows based on the multi-level time slice mechanism, and RBatch is used to batch and parallelly update the request counts of each sub-time window based on the time window expiration mechanism. The request counts of each sub-time window are stored in the Redis Cluster, and the trySetRate interface of RRateLimiter is used to dynamically adjust the window length. At the same time, the request traffic data of the historical sub-time windows is compressed and stored in the time series database. The error rate, concurrency, throughput, number of threads, time per second, transactions per second, and response time of HTTP requests are calculated in real time through the sub-time windows to generate the interface traffic feature vector. The feature extraction layer of the current limiting self-learning monitoring model uses a time series feature algorithm to calculate the mean, variance, and autocorrelation coefficient of the interface traffic feature vectors in each sub-time window, and uses a cumulative sum algorithm to perform burst detection on the interface traffic feature vectors. The learning and training layer, based on the sparse expert model architecture, iterates the interface traffic feature vectors, mean, variance, and autocorrelation coefficient according to preset time intervals and combines them with preset training rules for several training iterations. The weight parameters are updated using the FTRL optimizer and synchronized using Redisson's RTopic publish-subscribe model to obtain a comprehensive weight matrix. The inference output layer uses the ONNX Runtime tool combined with the code solver MathCoder to deploy and infer the comprehensive weight matrix. The learning and training layer of the current limiting self-learning monitoring model includes a residual network, an InceptionV3 network, and a DarkNet network. The request traffic data of HTTP requests is subjected to data feature extraction to obtain traffic feature values; the traffic feature values are respectively input into the residual network, InceptionV3 network and DarkNet network for gradient iterative training to obtain the first traffic feature matrix, the second traffic feature matrix and the third traffic feature matrix; the first traffic feature matrix, the second traffic feature matrix and the third traffic feature matrix are fused with the voting weight mechanism to obtain the interface traffic feature vector; the interface traffic feature vector is combined with the confidence threshold, input into the inference output layer and the comprehensive weight matrix for inference mapping to obtain the interface traffic category; the interface traffic categories include normal, suspicious and malicious; according to the interface traffic category, unlimited, gradient flow limiting thresholds and global flow limiting bans are automatically generated; Through Redisson's RSetCache shared interface traffic category and hierarchical current limiting label: if the hierarchical current limiting label is unlimited, the backend interface sampling time of each sub-time window is extended; if the hierarchical current limiting label is a gradient current limiting threshold, the request count of each sub-time window is elastically measured to obtain the number of requests in the dynamic time window. At the same time, the trySetRate interface of RSetLimiter in Redisson is used to dynamically modify the token bucket rate, and the limited sub-time window and backend interface are updated through RLock; if the hierarchical current limiting label is a global current limiting ban, the current limiting trigger rate of the backend interface is judged: if the current limiting trigger rate is less than or equal to 30%, the current backend interface scanning capacity is maintained; if the current limiting trigger rate is greater than 30%, the Kubernetes API is automatically called to expand the current backend interface scanning capacity, and synchronized to the dynamic time window through Redisson's RSemaphore.

[0035] Perform a global consistency check on the number of requests to the backend interface and the dynamic global current limit value: If the error between the number of requests and the dynamic global current limit value is greater than or equal to 5%, a 429 status code and a retry time are sent to the backend interface, and the request is directly rejected and recorded in the blacklist. The backend address code is filtered through Redisson's RBitSet, and then the interceptor is scheduled to limit the backend interface, and the limited backend interface requests are forwarded to the static cache server; If the error between the number of requests and the dynamic global current limit value is less than 5%, the request traffic data is stored through Redisson's RTimeSeries.

Claims

1. A method for limiting interface current based on distributed counting using Redisson under high concurrency, characterized by: The method comprises the following steps in sequence: S1: Obtain HTTP requests from the backend interface through the interceptor, and use dynamic time window statistics and extract data features of HTTP requests to generate interface traffic feature vectors; S2: Build a current limiting self-learning monitoring model based on the interface traffic feature vector; S3: Utilizes the rate limiting self-learning monitoring model to perform multimodal traffic classification and generate adaptive rate limiting labels for HTTP requests. S4: Dynamically configure current limiting parameters and elastically scale capacity for each backend interface based on the adaptive current limiting label. S5: Perform a global consistency check on the number of requests to the backend interface and the dynamic global current limit value, and then schedule the interceptor to limit the current of the backend interface.

2. The interface current limiting method based on Redisson distributed counting under high concurrency according to claim 1 is characterized in that: The step S1 includes the following steps: S11: intercept the HTTP request of the backend interface through the interceptor, extract the interface identifier, request timestamp, backend address code and request traffic data; S12: Use Redisson's RAtomicLong and RMapCache to perform distributed statistics on HTTP requests and obtain the number of requests; S13: Split the dynamic time window into several sub-time windows based on the multi-level time slice mechanism. RBatch is used to update the request counts of each sub-time window in batches in parallel based on the time window expiration mechanism. S14: Store the request counts for each sub-time window in the Redis Cluster and dynamically adjust the window length using the trySetRate interface of RRateLimiter. At the same time, compress the request traffic data of the historical sub-time windows and store it in the time series database. S15: Calculate the error rate, concurrency, throughput, number of threads, time per second, transactions per second, and response time of HTTP requests in real time through sub-time windows to generate interface traffic feature vectors.

3. The interface current limiting method based on Redisson distributed counting under high concurrency according to claim 1 is characterized in that: The feature extraction layer of the current limiting self-learning monitoring model uses a time series feature algorithm to calculate the mean, variance and autocorrelation coefficient of the interface traffic feature vector in each sub-time window, and uses a cumulative sum algorithm to perform burst detection on the interface traffic feature vector; the learning and training layer is based on a sparse expert model architecture and, according to a preset time interval, it iterates the interface traffic feature vector, mean, variance and autocorrelation coefficient in combination with preset training rules for several times, while using an FTRL optimizer to update the weight parameters and using Redisson's RTopic publish-subscribe mode to synchronize the weight parameters to obtain a comprehensive weight matrix; the inference output layer uses the ONNX Runtime tool in combination with the code solver MathCoder to deploy and infer the comprehensive weight matrix.

4. The interface current limiting method based on Redisson distributed counting under high concurrency according to claim 1 is characterized in that: The step S3 includes the following steps: S31: The learning and training layers of the current limiting self-learning monitoring model include the residual network, InceptionV3 network, and DarkNet network; S32: extracting data features from the request traffic data of the HTTP request to obtain a traffic feature value; S33: Input the traffic feature values into the residual network, the InceptionV3 network, and the DarkNet network respectively for gradient iterative training to obtain a first traffic feature matrix, a second traffic feature matrix, and a third traffic feature matrix; S34: The first traffic feature matrix, the second traffic feature matrix, and the third traffic feature matrix are combined with a voting weight mechanism to obtain an interface traffic feature vector. S35: Combine the interface traffic feature vector with the confidence threshold, input it into the inference output layer, and perform inference mapping with the comprehensive weight matrix to obtain the interface traffic category. The interface traffic category includes normal, suspicious, and malicious. S36: Automatically generates graded traffic limiting labels based on the interface traffic category; graded traffic limiting labels include unlimited, gradient traffic limiting threshold, and global traffic limiting ban; S37: Shared interface traffic categories and hierarchical current limiting tags through Redisson's RSetCache.

5. The interface current limiting method based on Redisson distributed counting under high concurrency according to claim 1 is characterized in that: In step S4, if the hierarchical current limiting label is unlimited, the backend interface sampling time of each sub-time window is extended; if the hierarchical current limiting label is a gradient current limiting threshold, the request count of each sub-time window is elastically calculated to obtain the number of requests in the dynamic time window, and at the same time, the token bucket rate is dynamically modified using the trySetRate interface of RRadateLimiter in Redisson, and the limited sub-time window and backend interface are updated through RLock; if the hierarchical current limiting label is a global current limiting ban, the current limiting trigger rate of the backend interface is judged: if the current limiting trigger rate is less than or equal to X%, the current backend interface scanning capacity is maintained; if the current limiting trigger rate is greater than X%, the Kubernetes API is automatically called to expand the current backend interface scanning capacity, and synchronized to the dynamic time window through Redisson's RSemaphore.

6. The interface current limiting method based on Redisson distributed counting under high concurrency according to claim 1 is characterized in that: In step S5, if the error between the number of requests and the dynamic global current limit value is greater than or equal to Y%, a 429 status code and a retry time are sent to the back-end interface, and the request is directly rejected and recorded in the blacklist. The back-end address code is filtered through Redisson's RBitSet, and then the interceptor is scheduled to limit the back-end interface, and the limited back-end interface request is forwarded to the static cache server; if the error between the number of requests and the dynamic global current limit value is less than Y%, the request traffic data is stored through Redisson's RTimeSeries.

Images