Method for limiting interface access times through custom annotationTechnical Field
The invention relates to the field of software engineering, in particular to a method for limiting the access times of an interface through custom annotations.
Background
With the vigorous development of information technology and the internet industry, particularly the popularization of the internet and the mobile internet, data interaction is becoming more frequent, and the interface is used as a bridge for data interaction, so that the performance and the stability of the interface are crucial to the operation of the whole system. However, in practical applications, the interfaces are frequently accessed, which results in the performance degradation of the system, so how to limit the access times of the interfaces, and improve the stability and performance of the system becomes a current urgent problem to be solved.
Currently, some technical solutions have been proposed and implemented for limiting the number of access times of an interface. However, these schemes often have poor flexibility and poor expansibility, and cannot adapt to requirements under different service scenarios, for example, some schemes set access times limitation in a hard coding manner, and once a numerical value needs to be adjusted, the code needs to be modified and redeployed, and some schemes provide a dynamic adjustment function, but often require complex configuration and management of a system, and increase use difficulty and cost.
Disclosure of Invention
In order to solve the technical problems, the invention provides a method for limiting the access times of an interface through custom annotations.
The technical scheme of the invention is as follows:
A method for limiting the number of interface accesses by custom annotation comprises
The dynamic limit of the access times of the interfaces is realized through the custom annotation, and the access times in different periods are limited for different interfaces according to the difference of the interface performance and the data, so as to control the request times of the server.
1) Custom annotations, common logic is extracted.
2) Time period and access times are limited by Redis.
3) Each interface can define time period and access times limitation, and expansibility is enhanced.
By means of the self-defining annotation, one-time coding is realized, the code reusability is improved, the use is simpler, the internal implementation is not needed to be considered, and only the annotation is required to be declared.
The access times and the access time are stored and updated through a distributed cache system such as Redis, and the atomicity during counting updating is ensured through a distributed lock, so that the code is more robust, a distributed environment can be supported, and better durability and expandability are realized.
The number of times limit and time period can be customized by each interface when the annotation is declared, and besides the default number of times limit and time period are provided in the tangent plane, the customization in each interface is supported, so that the flexibility of the annotation is improved.
Further, the method comprises the steps of,
Defining custom annotations
Firstly defining a custom annotation which is used for identifying an interface method needing to carry out current limiting, allowing a plurality of attributes to be set, and setting key parameters such as a time period, the maximum allowable request times in the period and the like;
Supporting setting annotation default parameters;
the user-defined annotation on each interface is supported, different access times in different periods can be set for interfaces with different performances and different access amounts, and the particularity and expandability of the interface access are ensured.
The method for the section programming framework is characterized in that a customized section is designed for the section programming framework, the section is used for intercepting and monitoring the method marked with the custom annotation, the fact that the number of requests of an interface in a specific time period does not exceed a set threshold value is ensured to be in the section, a pre-notification is realized as a key strategy, the pre-notification is triggered before the target method is actually executed, the request count in the current time period is checked through the pre-notification, and whether the continuous execution of the request is allowed or not is judged according to the request count.
Still further, the method comprises the steps of,
The preposed notification logic ensures that the current limiting strategy can be accurately executed before the interface is called, and measures can be taken to ensure the stability and the safety of the system when the request times are detected to exceed the threshold value;
the section design adjusts the current limiting strategy according to different service scenes and performance requirements by configuring different time periods and access request times threshold values.
Further, the method comprises the steps of,
Selecting a data structure in Redis or a memory as a back end for storage, mapping each interface and a corresponding time period into a unique key, embedding time information in the key to ensure time control, and searching the request times in the current time period through the key when receiving a request;
Meanwhile, the correct increment of the request times is ensured by utilizing the atomic operation of Redis, and the problem of inconsistent data caused by concurrent access is avoided.
In addition, a monitoring and alarming mechanism is implemented so as to track the change of the interface request times in time and take corresponding actions when needed. Statistical commands and other monitoring tools provided by Redis may assist in collecting the required data.
Still further, the method comprises the steps of,
When the number of requests exceeds the limit, the request is directly refused, a status code is returned to inform the client that the request is too frequent, the client performs corresponding processing according to the status code,
Another way of handling is to put the request in a queue for waiting to be handled, and to use the message queue to implement queuing and asynchronous handling of the request.
Selecting a proper message queue system according to the actual demand and performance requirement of the system, and setting the length of the queue and the processing speed;
The method comprises the steps of dynamically adjusting according to the actual load condition of a system, monitoring a message queue in real time, sending an alarm notification in time when a certain index exceeds a preset threshold value so as to discover and solve problems in time, and setting a retry mechanism for processing a message with failure;
For the message which can not be processed after multiple retries, failure processing is needed, and when the system load is too high or the processing speed of the message queue is not kept up with the request speed, a degradation strategy is adopted to relieve the system pressure.
Still further, the method comprises the steps of,
And updating the request times of the corresponding interface in the time period after each request success, using Redis as storage, using the interface name and the starting time stamp of the time period as the name of a Redis key, and increasing the count on the key corresponding to the interface in the Redis.
A key expiration mechanism of a timing task or a Redis is used, wherein if the timing task is used, a timer is set, expired keys are checked and reset periodically, if the key expiration mechanism of the Redis is used, an expiration time is set for each key, when the key is expired, the Redis automatically deletes the key, thereby realizing the reset of the request times, and meanwhile, the TTL command of the Redis is used for inquiring the residual survival time of the key so as to carry out logic processing.
Pre-loading initial count data of an interface into Redis when the system is started or before a certain time period is started so as to reduce delay when the system is requested for the first time;
The log is added and monitored simultaneously, and all successful requests, rejected requests and any operations related to the current limiting and expiration processing are recorded into the log, or the performance index, the number of interface requests and the rejection rate index of the Redis are monitored in real time.
When the Redis is too high in load or insufficient in storage space, more Redis instances are automatically added to share the load, and the method is realized by using an automatic telescoping function of a Redis cluster or cloud service.
The invention not only has high flexibility and expandability, but also can dynamically adjust according to the actual service demand. Through the custom annotation, a developer can easily realize the accurate control of the access times of the interface, and the requirements under different scenes are met. Meanwhile, the method can effectively lighten the burden of the system, improve the overall operation efficiency and provide powerful support for the digital transformation of enterprises.
The invention has the beneficial effects that
The use of custom annotations to implement the flow-limiting mechanism of interface access times is an elegant and efficient system design strategy, which not only can significantly promote the stability and expandability of the system, but also can ensure high availability and user experience of services. By combining AOP programming technology and distributed cache system, a precisely controlled and flexibly configured current limiting framework can be realized.
In particular, custom annotations act as declarative interfaces to the flow-limiting rules, enabling developers to embed flow-limiting requirements into the interfacing methods in an intuitive and readable manner. The AOP framework is responsible for dynamically intercepting and handling these annotations at runtime, performing the throttling operation through the slice logic.
In the current limiting implementation, the efficient storage and expiration mechanism of the distributed cache system (such as Redis) is fully utilized to record and track the number of accesses per interface. The design not only ensures the real-time performance and accuracy of the current-limiting state, but also can realize the sharing and synchronization of the states in a multi-instance environment, thereby ensuring the consistency and reliability of the current-limiting mechanism.
In addition, the current limiting framework provides flexible configuration options, and allows developers to adjust current limiting rules and parameters according to actual requirements. Whether adjusting the number of times of throttling, the time period, or selecting other throttling algorithms, may be accomplished by modifying the annotation attributes or configuration files without modifying the business code.
In general, interface current limiting mechanism realized by custom annotation and AOP technology not only improves the robustness and performance of the system, but also reduces the development cost and maintenance difficulty. The method is a high-grade and high-level system design scheme and is suitable for various high-concurrency and high-performance Web application scenes.
Drawings
Fig. 1 is a schematic of the workflow of the present invention.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments, and all other embodiments obtained by those skilled in the art without making any inventive effort based on the embodiments of the present invention are within the scope of protection of the present invention.
The invention provides a method for realizing dynamic limit of interface access times through user-defined annotation, which is used for frequently meeting the condition of a large number of request accesses to a system interface under a large number of high concurrency scenes such as limited time rush purchase service of some e-commerce websites and hot news access service of social media, and meanwhile, the experience of user access and the high availability of the system are considered, so that the system is ensured not to be down and can continuously and stably operate, the experience of the user is improved, and the situation that data cannot be refreshed due to clamping or display cannot occur frequently is also ensured. Therefore, in order to balance the two, developers need to accurately and efficiently solve the core problem of interface call frequency control in the distributed system. By the method for dynamically limiting the access times of the interface through the custom annotation, a developer can customize a flexible current limiting strategy for the interface according to complex service scenes and changeable requirements, and limit the access times in different periods according to the difference of interface performance and data, so as to control the request times of the server and ensure the robustness and high availability of system call. The specific scheme is as follows:
1. defining custom annotations
First, a custom annotation is defined, named @ RATELIMIT. The annotation is used to identify the interface method that requires throttling and allows for setting a number of attributes, such as time period, maximum number of allowed requests, etc. The developer can finely set key parameters such as time period, maximum allowable request times in the period and the like. These parameters are all based on actual service requirements, providing powerful support for the formulation of flow limiting strategies.
And supports setting of annotation default parameters. For example, the developer may set the default parameters to a time period of 1 minute for a maximum number of requests of 1000. Therefore, the interface can only access one thousand times in one minute by only adding the annotation on the interface, the default parameter setting avoids marking time period for each interface, and the repeated work of parameters such as request times is allowed.
And meanwhile, the user-defined annotation on each interface is supported, different access times in different periods can be set for interfaces with different performances and different access amounts, and the particularity and expandability of the interface access are ensured. In this way, the annotation can clearly convey the flow-limiting requirements of the interface and improve the readability of the interface.
2. Realizing section (AOP)
Next, a custom facet will be designed using a Spring AOP or AspectJ or other facet-oriented programming (AOP) framework, the main task of which is to intercept and monitor those methods that mark the @ RATELIMIT annotation. Ensuring that the number of requests of the interface does not exceed a set threshold within a particular time period
In the cut plane, a pre-notification (before notification) is implemented as a key policy. The pre-notification will be triggered before the target method actually executes, which provides an excellent opportunity to execute the throttling logic. By means of the pre-notification, the request count in the current time period can be accurately checked and it is determined whether to allow continued execution of the request accordingly.
The design of the pre-notification logic is intended to ensure that the throttling policy can be accurately enforced prior to interface invocation, which is critical to preventing malicious requests and application overloads. When the number of requests is detected to exceed the threshold, a series of actions may be taken, such as refusing service, redirecting to a standby resource, or requiring the user to try again later, etc., to ensure the stability and security of the system.
In addition, the section design also considers flexibility and configurability, and by configuring different time periods and access request permission times thresholds, the current limiting strategy can be adjusted according to different service scenes and performance requirements. This flexibility enables the current limiting mechanism to accommodate changing application requirements, providing more comprehensive and sophisticated interface control.
Therefore, by utilizing Spring AOP or AspectJ and other AOP frameworks and combining a pre-notification mechanism, an efficient, flexible and reliable tangent plane can be constructed.
3. Storing and detecting request times
In order to efficiently store and check the number of requests per interface, the data structure in Redis or memory may be carefully selected as the back-end store. Redis, which is a distributed cache system, is an ideal choice for handling large-scale concurrent requests by virtue of its excellent extensibility and persistence. While in a scenario where high performance and fast response are required, the data structures in memory can also provide excellent performance, but may require attention to its memory consumption.
In particular implementations, a flexible and efficient storage mechanism will be built using the hash structure of Redis. Each interface and corresponding time period will be mapped to a unique key in which time information is embedded to ensure accurate time control. When a request is received, the number of requests in the current time period will be quickly retrieved by this key.
Meanwhile, the atomic operation of Redis is fully utilized to ensure the correct increment of the request times, and the problem of inconsistent data caused by concurrent access is avoided.
In terms of extensibility, the distributed nature of Redis can easily cope with highly concurrent challenges. High availability and failover can be achieved through Redis clusters or sentinel configurations, ensuring continuous and stable operation of the system. In addition, a strict monitoring and alerting mechanism will be implemented to track the changes in the number of interface requests in time and take corresponding action when needed. Statistical commands and other monitoring tools provided by Redis will help collect the required data, providing powerful support for decisions.
In summary, by carefully selecting the storage back end and utilizing the hash structure and atomic operation of Redis, and combining the aspects of expansibility, monitoring, alarming and the like, an efficient, reliable and flexible interface request number storage and inspection system is constructed, and strong interface current limiting management capability is provided for the application program.
4. Flexible and various overrun processing mode
When the number of requests exceeds the limit, the request can be directly refused, and the HTTP 429Too Many Requests status code is returned to inform the client that the request is too frequent. In this way, the client can perform corresponding processing, such as delaying retry or displaying prompt information, according to the status code. Just like obtaining a short message verification code, in order to limit that each user can only receive one short message in five minutes, prompt information is given to the user, and the verification code can be continuously sent after five minutes, but the processing mode is only suitable for a scene that the user wants to obtain data or use functions in time. If a service scene such as downloading a large number of files simultaneously, the user can introduce another processing mode, namely a message queue without timely response.
Another way to do this is to put the request in a queue waiting to be processed. This approach may avoid directly rejecting the request, but may increase the response time of the system. Queuing and asynchronous processing of requests may be accomplished using message queues (e.g., rabbitMQ, kafka, etc.). Thus, peak clipping of the interface request can be realized, a large number of request times in the moment or short term can be reduced, and the request times can be put into a queue for slow processing.
Meanwhile, it should be noted that, firstly, an appropriate message queue is selected, and an appropriate message queue system is selected according to the actual requirement and performance requirement of the system, because different message queue systems have different characteristics and application scenes, and the selection needs to be performed according to the actual situation. In order to avoid that the system resources are exhausted or the processing speed is too slow due to too long message queues, the waiting time of users is too long, and reasonable queue length and processing speed are required to be set.
Dynamic adjustment is also required according to the actual load condition of the system. The message queue is monitored in real time, and indexes such as queue length, processing speed, error rate and the like are included. When a certain index exceeds a preset threshold, an alarm notification is sent timely so as to discover and solve the problem timely. For messages that fail to be processed for various reasons, a retry mechanism needs to be set.
For the message which cannot be processed yet after multiple retries, failure processing, such as logging, sending alarm notification, etc., is needed. Some downgrade strategies may be considered to relieve system stress when system load is excessive or message queue processing speed does not keep pace with request speeds. For example, some non-core functions may be turned off, some users' requests may be restricted, etc.
In summary, by combining two strategies of directly rejecting and returning the HTTP 429 status code and using the message queue to perform request queuing and asynchronous processing, the most suitable processing mode can be selected according to the actual requirement and performance requirement of the system. Meanwhile, stability and user experience of the system can be ensured through optimizing measures and monitoring an alarm mechanism.
5. Accurate control of automatic expiration
After each request is successful, the number of requests of the corresponding interface in the time period needs to be updated. Using Redis as a store, the name of the Redis key is taken as the interface name and the start timestamp of the time period. By incrementing a count on the key corresponding to the interface in Redis. Due to the single-threaded model of Redis, no concurrency problem occurs when multiple requests update the same key at the same time.
To implement expiration processing, a key expiration mechanism for timed tasks or Redis may be used. If a timed task is used, a timer may be set to periodically check and reset the expired keys. If a key expiration mechanism of Redis is used, an expiration time can be set for each key, and when the key expires, redis automatically deletes the key, thereby realizing the reset of the request times. Meanwhile, the TTL command of the Redis may also be used to query the remaining lifetime of the key for logic processing if necessary.
The initial count data for some of the common interfaces may also be preloaded into the Redis at system start-up or before a certain period of time begins to reduce the delay in the first request. In addition to simple counting and expiration mechanisms, the use of sliding window algorithms to achieve more accurate current limiting may also be considered. The sliding window algorithm may dynamically adjust the current limit threshold based on the number of requests within the time window. Yet another common throttling algorithm is the token bucket algorithm. It allows the system to generate tokens at a constant rate and put them into a bucket. Each request requires the consumption of a token to be processed. When there are no tokens in the bucket, the request will be denied.
It is also necessary to log and monitor all successful requests, rejected requests, and any actions related to throttling and expiration processing should be logged in detail. Monitoring tools (such as Prometheus, grafana and the like) can also be used for monitoring key indexes such as performance indexes, interface request quantity, rejection rate and the like of Redis in real time.
When the Redis is too high in load or insufficient in storage space, more Redis instances should be automatically added to share the load. This may be achieved by using the Redis cluster or the auto-scaling functionality of the cloud service. When the system is under severe stress, it should be able to gracefully degrade some of the non-core functions to ensure the stability and availability of the core functions.
In summary, the invention realizes the dynamic limit of the access times of the interface through the custom annotation and the AOP technology. The scheme has high flexibility, expandability and high availability, can effectively control the calling frequency of the interface, and protects the system from malicious attack and overload.
The method allows the developer to easily set access times restrictions within a specific time period by adding custom annotations on the interface method. When the interface is called, the system automatically checks the access times limit set in the annotation and carries out corresponding processing according to the actual situation. Once the access times exceeds a set value, the system automatically refuses subsequent requests, thereby effectively avoiding the influence of excessive access on the system performance.
The foregoing description is only illustrative of the preferred embodiments of the present invention, and is not intended to limit the 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.