Method for limiting interface access times through custom annotation

Abstract

The invention provides a method for limiting the number of access times of an interface through user-defined annotations, belongs to the field of software engineering, and aims at easily setting the limitation of the number of access times in a specific time period by adding the user-defined annotations on an interface method. And when the interface is called, the system automatically checks the access frequency limit set in the annotation, and carries out corresponding processing according to the actual situation. Once the number of access times exceeds a set value, the system automatically rejects subsequent requests, so that the influence of excessive access on the system performance is effectively avoided.

Description

Technical Field

[0001] The present invention relates to the field of software engineering, and in particular to a method for limiting the number of interface accesses through custom annotations. Background Art

[0002] With the vigorous development of information technology and the Internet industry, especially the popularization of the Internet and mobile Internet, data interaction has become increasingly frequent. As a bridge for data interaction, the performance and stability of the interface are crucial to the operation of the entire system. However, in practical applications, it is often encountered that the interface is frequently accessed, resulting in a decrease in system performance. Therefore, how to limit the number of accesses to the interface and improve the stability and performance of the system has become an urgent problem to be solved.

[0003] At present, some technical solutions have been proposed and implemented to limit the number of interface accesses. However, these solutions often have poor flexibility and insufficient scalability, and cannot adapt to the needs of different business scenarios. For example, some solutions set the number of accesses through hard coding. Once the value needs to be adjusted, the code needs to be modified and redeployed. Some solutions provide dynamic adjustment functions, but often require complex configuration and management of the system, which increases the difficulty and cost of use. Summary of the invention

[0004] In order to solve the above technical problems, the present invention provides a method for limiting the number of interface accesses through custom annotations.

[0005] The technical solution of the present invention is:

[0006] A method to limit the number of interface accesses through custom annotations, including

[0007] Dynamically limit the number of interface accesses through custom annotations. According to the differences in interface performance and data, limit the number of accesses to different interfaces in different cycles to control the number of requests to the server.

[0008] 1) Customize annotations to extract common logic.

[0009] 2) Use Redis to store time periods and access count limits.

[0010] 3) Each interface can customize the time period and access limit, which enhances scalability.

[0011] By using custom annotations, you can code once and use it everywhere, which improves code reusability and makes it easier to use. You don’t need to consider its internal implementation, you just need to declare the annotation.

[0012] Distributed cache systems such as Redis are used to store and update access counts and access times, and distributed locks are used to ensure the atomicity of updating counts, making the code more robust and able to support distributed environments with better persistence and scalability.

[0013] Each interface can customize the request limit and time period when declaring this annotation. In addition to the default limit and time period provided in the aspect, it also supports customization in each interface, which improves the flexibility of this annotation.

[0014] Furthermore,

[0015] Defining custom annotations

[0016] First, define a custom annotation; this annotation is used to identify the interface method that needs to be current limited, and allows the setting of several properties, such as the time period, the maximum number of requests allowed within the period, and other key parameters;

[0017] Support setting annotation default parameters;

[0018] It supports custom annotations on each interface. For interfaces with different performance and access volume, different access times in different cycles can be set to ensure the specificity and scalability of interface access.

[0019] A custom aspect is designed for the aspect-oriented programming framework. The task of this aspect is to intercept and monitor methods marked with custom annotations to ensure that the number of interface requests within a specific time period does not exceed the set threshold. In the aspect, a pre-notification will be implemented as a key strategy. The pre-notification will be triggered before the target method is actually executed. Through the pre-notification, the request count within the current time period is checked, and based on this, it is determined whether the request is allowed to continue executing.

[0020] Going further,

[0021] The pre-notification logic ensures that the current limiting strategy can be accurately executed before the interface is called. When it is detected that the number of requests exceeds the threshold, measures can be taken to ensure the stability and security of the system.

[0022] Aspect design adjusts the current limiting strategy according to different business scenarios and performance requirements by configuring different time periods and thresholds for the number of access requests allowed.

[0023] Furthermore,

[0024] Choose Redis or in-memory data structures as backend storage; each interface and corresponding time period is mapped to a unique key, with time information embedded in the key to ensure time control; when a request is received, the number of requests in the current time period will be retrieved through this key;

[0025] At the same time, Redis's atomic operations are used to ensure the correct increment of the number of requests to avoid data inconsistency problems caused by concurrent access.

[0026] Through Redis cluster or sentinel configuration, high availability and failover are achieved to ensure continuous and stable operation of the system. In addition, monitoring and alarm mechanisms are implemented to track changes in the number of interface requests in a timely manner and take corresponding actions when necessary. The statistical commands and other monitoring tools provided by Redis can assist in collecting the required data.

[0027] Going further,

[0028] When the number of requests exceeds the limit, the request is rejected directly and a status code is returned to inform the client that the request is too frequent. The client handles the request accordingly based on the status code.

[0029] Another way to process is to put the request in a queue and wait for processing; use a message queue to implement queuing and asynchronous processing of requests.

[0030] According to the actual needs and performance requirements of the system, select a suitable message queue system and set the queue length and processing speed;

[0031] Dynamically adjust according to the actual load of the system; monitor the message queue in real time; send alarm notifications in time when a certain indicator exceeds the preset threshold so as to promptly discover and solve the problem; set up a retry mechanism for messages that fail to be processed;

[0032] For messages that cannot be processed after multiple retries, failure processing is required. When the system load is too high or the message queue processing speed cannot keep up with the request speed, a degradation strategy is used to reduce system pressure.

[0033] Going further,

[0034] After each successful request, the number of requests for the corresponding interface within the time period is updated. Redis is used as the storage, and the interface name and the start timestamp of the time period are used as the name of the Redis key. This is achieved by increasing the count on the key corresponding to the interface in Redis.

[0035] Use scheduled tasks or Redis's key expiration mechanism: If you use scheduled tasks, set a timer to regularly check and reset expired keys; if you use Redis's key expiration mechanism, set an expiration time for each key. When a key expires, Redis will automatically delete the key, thereby resetting the number of requests; at the same time, use Redis's TTL command to query the remaining lifetime of the key for logical processing.

[0036] When the system starts or before a certain time period begins, preload the initial count data of the interface into Redis to reduce the delay of the first request; use the sliding window algorithm or token bucket algorithm to implement current limiting;

[0037] At the same time, logs and monitoring are added to record all successful requests, rejected requests, and any operations related to current limiting and expiration processing; or real-time monitoring of Redis performance indicators, interface request quantity, and rejection rate indicators.

[0038] When the Redis load is too high or the storage space is insufficient, more Redis instances are automatically added to share the load; this is achieved by using the automatic scaling function of the Redis cluster or cloud service.

[0039] The present invention is not only highly flexible and scalable, but also can be dynamically adjusted according to actual business needs. Through custom annotations, developers can easily achieve precise control of the number of interface accesses to meet the needs of different scenarios. At the same time, the method can also effectively reduce the system burden, improve the overall operating efficiency, and provide strong support for the digital transformation of enterprises.

[0040] The beneficial effects of the present invention are

[0041] Using custom annotations to implement a current limiting mechanism for the number of interface accesses is an elegant and efficient system design strategy that can not only significantly improve the stability and scalability of the system, but also ensure high availability and user experience of the service. By combining AOP programming technology and a distributed cache system, a current limiting framework with precise control and flexible configuration can be implemented.

[0042] Specifically, custom annotations serve as a declarative interface for current limiting rules, allowing developers to embed current limiting requirements into interface methods in an intuitive and easy-to-read way. The AOP framework is responsible for dynamically intercepting and processing these annotations at runtime and performing current limiting operations through aspect logic.

[0043] In the implementation of current limiting, the efficient storage and expiration mechanism of the distributed cache system (such as Redis) is fully utilized to record and track the number of visits to each interface. This design not only ensures the real-time and accuracy of the current limiting state, but also enables the sharing and synchronization of the state in a multi-instance environment, thereby ensuring the consistency and reliability of the current limiting mechanism.

[0044] In addition, the current limiting framework also provides flexible configuration options, allowing developers to adjust current limiting rules and parameters according to actual needs. Whether adjusting the current limiting times, time period, or choosing other current limiting algorithms, it can be achieved by modifying annotation properties or configuration files without modifying business code.

[0045] In general, the interface current limiting mechanism implemented by custom annotations and AOP technology not only improves the robustness and performance of the system, but also reduces development costs and maintenance difficulties. It is a high-end and high-end system design solution suitable for various high-concurrency and high-performance Web application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 It is a schematic diagram of the workflow of the present invention. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0048] The present invention provides a method for dynamically limiting the number of interface accesses through custom annotations. In many high-concurrency scenarios, such as the limited-time purchase business of some e-commerce websites and the hot news access business of social media, a large number of requests for access to the system interface are often encountered. At the same time, the user access experience and the high availability of the system must be taken into account. It is necessary to ensure that the system will not crash and can continue to operate stably, and to improve the user experience, and it is not necessary to frequently get stuck or display data cannot be refreshed. Therefore, in order to balance the two, developers need to accurately and efficiently solve the core problem of controlling the frequency of interface calls in distributed systems. By using custom annotations to dynamically limit the number of interface accesses, developers can customize flexible current limiting strategies for interfaces for complex business scenarios and changing needs. According to the differences in interface performance and data, the number of accesses in different cycles can be limited for different interfaces, thereby controlling the number of requests to the server and ensuring the robustness and high availability of system calls. The specific scheme is as follows:

[0049] 1. Define custom annotations

[0050] First, define a custom annotation named @RateLimit. This annotation is used to identify the interface method that needs to be rate-limited, and allows multiple properties to be set, such as the time period, the maximum number of requests allowed, etc. Developers can finely set key parameters such as the time period and the maximum number of requests allowed within the period. These parameters are based on actual business needs and provide strong support for the formulation of rate-limiting strategies.

[0051] It also supports setting annotation default parameters. For example, developers can set the default parameters to a time period of 1 minute and a maximum number of requests of 1,000. In this way, by simply adding this annotation to the interface, the interface can be accessed only a thousand times within one minute. The default parameter setting avoids the repetitive work of marking the time period, the number of allowed requests and other parameters for each interface.

[0052] It also supports custom annotations on each interface. For interfaces with different performance and access volume, different access times in different cycles can be set to ensure the specificity and scalability of interface access. In this way, annotations can clearly convey the interface's current limiting requirements and improve the readability of the interface.

[0053] 2. Implementing aspects (AOP)

[0054] Next, we will use an aspect-oriented programming (AOP) framework such as Spring AOP or AspectJ to design a custom aspect. The main task of this aspect is to intercept and monitor methods marked with the @RateLimit annotation to ensure that the number of requests to the interface does not exceed the set threshold within a specific time period.

[0055] In the aspect, implement a before advice as the key strategy. Before advice will be triggered before the target method is actually executed, which provides an excellent opportunity to execute the current limiting logic. Through before advice, you can accurately check the request count in the current time period and determine whether to allow the request to continue to execute.

[0056] The design of the pre-notification logic is to ensure that the current limiting strategy can be accurately executed before the interface is called, which is crucial to preventing malicious requests and application overload. When the number of requests exceeds the threshold, a series of measures can be taken, such as denial of service, redirection to alternative resources, or asking users to try again later, to ensure the stability and security of the system.

[0057] In addition, aspect design will also take into account flexibility and configurability. By configuring different time periods and thresholds for the number of access requests allowed, the current limiting strategy can be adjusted according to different business scenarios and performance requirements. This flexibility enables the current limiting mechanism to adapt to the ever-changing application requirements and provide more comprehensive and refined interface control.

[0058] Therefore, by using AOP frameworks such as Spring AOP or AspectJ and combining them with the pre-advice mechanism, an efficient, flexible and reliable aspect can be built.

[0059] 3. Storage and detection request times

[0060] In order to efficiently store and check the number of requests for each interface, you can carefully choose Redis or in-memory data structures as the backend storage. Redis, as a distributed cache system, is an ideal choice for handling large-scale concurrent requests due to its excellent scalability and persistence. In scenarios that require high performance and fast response, in-memory data structures can also provide excellent performance, but you may need to pay attention to their memory consumption.

[0061] In the specific implementation, Redis hash structure will be used to build a flexible and efficient storage mechanism. Each interface and corresponding time period will be mapped to a unique key, and the time information will be embedded in the key to ensure accurate time control. When a request is received, the number of requests in the current time period will be quickly retrieved through this key.

[0062] At the same time, we will make full use of Redis's atomic operations to ensure the correct increment of the number of requests and avoid data inconsistency problems caused by concurrent access.

[0063] In terms of scalability, the distributed nature of Redis can easily cope with the challenges of high concurrency. Through Redis cluster or sentinel configuration, high availability and failover can be achieved to ensure the continuous and stable operation of the system. In addition, a strict monitoring and alarm mechanism will be implemented to track changes in the number of interface requests in a timely manner and take corresponding actions when necessary. The statistical commands and other monitoring tools provided by Redis will help collect the required data and provide strong support for decision-making.

[0064] In summary, by carefully selecting the storage backend, using the hash structure and atomic operations of Redis, and combining considerations such as scalability, monitoring, and alarms, we can build an efficient, reliable, and flexible interface request frequency storage and inspection system to provide applications with powerful interface current limiting management capabilities.

[0065] 4. Flexible and diverse over-limit handling methods

[0066] When the number of requests exceeds the limit, you can choose to directly reject the request and return the HTTP 429Too ManyRequests status code to inform the client that the request is too frequent. In this way, the client can process accordingly based on the status code, such as delaying retries or displaying prompt information. For example, when getting a text message verification code, in order to limit each user to only receive one within five minutes, the user will be prompted and the verification code can be sent again after five minutes. However, this processing method is only applicable to scenarios where users want to obtain data or use functions in a timely manner. If the user does not need a timely response in business scenarios such as downloading a large number of files at the same time, another processing method can be introduced, that is, a message queue.

[0067] Another way to handle it is to put the request in a queue and wait for processing. This method can avoid directly rejecting the request, but it may increase the response time of the system. You can use message queues (such as RabbitMQ, Kafka, etc.) to implement request queuing and asynchronous processing. This can achieve peak reduction of interface requests, reduce the number of instantaneous or short-term large requests, and put them in the queue for slow processing.

[0068] At the same time, it should be noted that you should first choose a suitable message queue and select a suitable message queue system according to the actual needs and performance requirements of the system, because different message queue systems have different characteristics and applicable scenarios, and you need to choose according to the actual situation. In order to avoid the message queue being too long, causing system resources to be exhausted, or the processing speed being too slow, causing users to wait too long, you need to set a reasonable queue length and processing speed.

[0069] It is also necessary to make dynamic adjustments based on the actual load of the system. Monitor the message queue in real time, including indicators such as queue length, processing speed, and error rate. When an indicator exceeds the preset threshold, send an alarm notification in time to detect and solve the problem in time. For messages that fail to be processed due to various reasons, a retry mechanism needs to be set.

[0070] For messages that cannot be processed after multiple retries, failure processing is required, such as logging, sending alarm notifications, etc. When the system load is too high or the message queue processing speed cannot keep up with the request speed, you can consider using some downgrade strategies to reduce system pressure. For example, you can shut down some non-core functions and limit some users' requests.

[0071] In summary, by combining the two strategies of directly rejecting and returning HTTP 429 status code and using message queues for request queuing and asynchronous processing, the most appropriate processing method can be selected according to the actual needs and performance requirements of the system. At the same time, through optimization measures and monitoring and alarm mechanisms, the stability of the system and user experience can be ensured.

[0072] 5. Accurate control of automatic expiration

[0073] After each successful request, the number of requests for the corresponding interface within the time period needs to be updated. Redis is used as storage, and the interface name and the start timestamp of the time period are used as the name of the Redis key. This is achieved by adding a count to the key corresponding to the interface in Redis. Due to the single-threaded model of Redis, there will be no concurrency issues when multiple requests update the same key at the same time.

[0074] To implement expiration processing, you can use a scheduled task or Redis's key expiration mechanism. If you use a scheduled task, you can set a timer to regularly check and reset expired keys. If you use Redis's key expiration mechanism, you can set an expiration time for each key. When a key expires, Redis will automatically delete the key, thereby resetting the number of requests. At the same time, you can also use Redis's TTL command to query the remaining life span of a key so that you can perform logical processing when necessary.

[0075] You can also preload the initial count data of some commonly used interfaces into Redis when the system starts or before a certain time period starts to reduce the delay during the first request. In addition to simple counting and expiration mechanisms, you can also consider using a sliding window algorithm to achieve more accurate current limiting. The sliding window algorithm can dynamically adjust the current limiting threshold based on the number of requests within the time window. Another common current limiting algorithm is the token bucket algorithm. It allows the system to generate tokens at a constant rate and put these tokens into a bucket. Each request consumes a token to be processed. When there are no tokens in the bucket, the request will be rejected.

[0076] At the same time, logging and monitoring are also required. All successful requests, rejected requests, and any operations related to current limiting and expiration processing should be recorded in detail in the log. You can also use monitoring tools (such as Prometheus, Grafana, etc.) to monitor Redis performance indicators, interface request quantity, rejection rate and other key indicators in real time.

[0077] When the Redis load is too high or the storage space is insufficient, more Redis instances should be automatically added to share the load. This can be achieved by using the automatic scaling function of Redis cluster or cloud services. When the system is under severe pressure, some non-core functions should be gracefully downgraded to ensure the stability and availability of core functions.

[0078] In summary, the present invention realizes the dynamic limitation of the number of interface accesses through custom annotations and AOP technology. The solution has high flexibility, scalability and high availability, can effectively control the calling frequency of the interface, and protect the system from malicious attacks and overload.

[0079] This method allows developers to easily set access limits within a specific time period by adding custom annotations to interface methods. When the interface is called, the system will automatically check the access limit set in the annotation and handle it accordingly based on the actual situation. Once the number of accesses exceeds the set value, the system will automatically reject subsequent requests, effectively avoiding the impact of excessive access on system performance.

[0080] The above description is only a preferred embodiment of the present invention, which is only used to illustrate the technical solution of the present invention, and is not used to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A method for limiting the number of interface accesses through custom annotations, characterized in that: Dynamically limit the number of interface accesses through custom annotations. According to the differences in interface performance and data, the number of accesses to different interfaces in different periods is limited to control the number of requests to the server.

2. The method according to claim 1, characterized in that Defining custom annotations First, define a custom annotation; this annotation is used to identify the interface method that needs to be current limited, and allows the setting of several properties, such as the time period, the maximum number of requests allowed within the period, and other key parameters; Support setting annotation default parameters; It supports custom annotations on each interface. For interfaces with different performance and access volume, different access times in different cycles can be set to ensure the specificity and scalability of interface access.

3. The method according to claim 2, characterized in that A custom aspect is designed for the aspect-oriented programming framework. The task of this aspect is to intercept and monitor methods marked with custom annotations to ensure that the number of interface requests within a specific time period does not exceed the set threshold. In the aspect, a pre-notification will be implemented as a key strategy. The pre-notification will be triggered before the target method is actually executed. Through the pre-notification, the request count within the current time period is checked, and based on this, it is determined whether the request is allowed to continue executing.

4. The method according to claim 3, characterized in that The pre-notification logic ensures that the current limiting strategy can be accurately executed before the interface is called. When it is detected that the number of requests exceeds the threshold, measures can be taken to ensure the stability and security of the system. Aspect design adjusts the current limiting strategy according to different business scenarios and performance requirements by configuring different time periods and thresholds for the number of access requests allowed.

5. The method according to claim 1, characterized in that Storage and detection request times Choose Redis or in-memory data structures as backend storage; each interface and corresponding time period is mapped to a unique key, with time information embedded in the key to ensure time control; when a request is received, the number of requests in the current time period will be retrieved through this key; At the same time, Redis's atomic operations are used to ensure the correct increment of the number of requests to avoid data inconsistency problems caused by concurrent access.

6. The method according to claim 5, characterized in that Through Redis cluster or sentinel configuration, high availability and failover are achieved to ensure continuous and stable operation of the system. In addition, monitoring and alarm mechanisms are implemented to track changes in the number of interface requests in a timely manner and take corresponding actions when necessary. The statistical commands and other monitoring tools provided by Redis can assist in collecting the required data.

7. The method according to claim 1, characterized in that When the number of requests exceeds the limit, the request is rejected directly and a status code is returned to inform the client that the request is too frequent. The client handles the request accordingly based on the status code. Another way to process is to put the request in a queue and wait for processing; use a message queue to implement queuing and asynchronous processing of requests; According to the actual needs and performance requirements of the system, select a suitable message queue system and set the queue length and processing speed; Dynamically adjust according to the actual load of the system; Real-time monitoring of message queues; When an indicator exceeds the preset threshold, an alarm notification is sent in time to promptly discover and solve the problem; for messages that fail to be processed, a retry mechanism needs to be set up; For messages that cannot be processed after multiple retries, failure processing is required. When the system load is too high or the message queue processing speed cannot keep up with the request speed, a degradation strategy is used to reduce system pressure.

8. The method according to claim 1, characterized in that After each successful request, the number of requests for the corresponding interface within the time period is updated. Redis is used as the storage. The interface name and the start timestamp of the time period are used as the name of the Redis key. This is achieved by increasing the count on the key corresponding to the interface in Redis. Use scheduled tasks or Redis's key expiration mechanism: If you use scheduled tasks, set a timer to regularly check and reset expired keys; if you use Redis's key expiration mechanism, set an expiration time for each key. When a key expires, Redis will automatically delete the key, thereby resetting the number of requests; at the same time, use Redis's TTL command to query the remaining lifetime of the key for logical processing.

9. The method according to claim 8, characterized in that When the system starts or before a certain time period begins, preload the initial count data of the interface into Redis to reduce the delay of the first request; use the sliding window algorithm or token bucket algorithm to implement current limiting; At the same time, logging and monitoring are added to record all successful requests, rejected requests, and any operations related to current limiting and expiration processing; Or monitor Redis performance indicators, interface request quantity, and rejection rate indicators in real time.

10. The method according to claim 9, characterized in that When the Redis load is too high or the storage space is insufficient, more Redis instances are automatically added to share the load; this is achieved by using the automatic scaling function of the Redis cluster or cloud service.

Images