In the recent actual development process, it was found that some service resources accessed 503 Service Temporarily Unavailable. After searching, it was confirmed that after the speed limit was imposed on nginx, the speed limit was too low, and the number of accesses exceeded the number of visits and directly refused access and returned a 503 error.
nginx can use ngx_http_limit_req to limit server resource requests.
This module uses
the
Leaky Bucket algorithm, which has two processing methods Traffic Shaping and Traffic Policing
After the bucket is full of water, two common treatment methods are:
1. Temporarily block the downward flow of the water above, wait for a part of the water in the bucket to leak, and then release the water above.
2. Discard the overflowing water directly.
Taking water as the abstraction of data packets in network communication, the effect of method 1 is called Traffic Shaping, and the effect of method 2 is called Traffic Policing
. It can be seen that the core concept of Traffic Shaping is "waiting", Traffic Policing The core idea of is "discard". They are two common flow rate control methods
Example of configuration for using this module in nginx
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
location /search/ {
limit_req zone=one burst=5 nodelay;
}
The first configuration
The first parameter: $binary_remote_addr indicates that the remote_addr logo is used to limit the limit. The purpose of "binary_" is to abbreviate the memory footprint and limit the ip address of the same client.
The second parameter: zone=one:10m indicates that a size of 10M is generated , the memory area named one, which is used to store the frequency of access information.
The third parameter: rate=1r/s indicates that the access frequency of clients with the same identity is allowed. The limit here is 1 time per second. m
Second stage configuration
The first parameter: zone=one sets which configuration zone to use for the limit, corresponding to the name in limit_req_zone above
The second parameter: burst=5, this configuration means to set a buffer with a size of 5. When a large number of requests come, requests that exceed the access frequency limit can be placed in this buffer first
The third parameter: nodelay, if set, if the access frequency is exceeded and the buffer is full, 503 will be returned directly. If not set, all requests will be queued
The following example is more intuitive.
Case 1:
Setting conditions: rate qps=1, peak burst=5, delay request, i.e. no nodelay parameter
Effect: Strictly follow the leaky bucket rate qps=1 to process requests per second. Since burst=5, when the number of requests received in one second is between 1 and 5, the unprocessed requests will be temporarily suspended , which is equivalent to storing in the leaky bucket, a total of 5 can be stored; currently one is processed in 1 second, and the rest will be delayed.
If the number of requests exceeds the burst limit, 503 will be returned directly; as long as the client controls the concurrency within the peak burst, limit_req_error_log will not be triggered
Case 2:
Setting conditions: rate qps=1, peak burst=5, do not delay the request, that is, there is a nodelay parameter
Effect: After adding nodelay, the leaky bucket controls the average qps = leaky bucket rate for a period of time, but allows the instantaneous peak qps to be greater than the leaky bucket qps. The peak is the highest qps=brust + qps - 1
For example, at the beginning, if 5 requests come at once, although qps=1, but because of burst=5, the instantaneous peak can reach qps=5, and these 5 requests can be processed and returned at the same time; The leaky bucket rate qps=1 is set, so in the next 5 seconds, no other requests can be accepted