Seau vide
Nous commençons par la configuration de limitation de courant la plus simple :
limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s; server { location /login/ { limit_req zone=ip_limit; proxy_pass http://login_upstream; } }
$binary_remote_addr pour la limitation de courant IP du client
zone=ip_limit:10m Le nom de la règle de limitation actuelle est ip_limit, ce qui est autorisé ; 10 Mo d'espace mémoire pour enregistrer l'état limite actuel correspondant à l'IP ; limite La vitesse de streaming est de 10 requêtes par seconde Si 10 requêtes arrivent sur un nginx inactif en même temps, seront-elles toutes exécutées ?
Donc si 10 demandes arrivent en même temps, une seule demande pourra être exécutée, et les autres seront rejetées.
Changeons la configuration pour résoudre le problème de la section précédente
limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s; server { location /login/ { limit_req zone=ip_limit burst=12; proxy_pass http://login_upstream; } }
burst=12 La taille du seau qui fuit est fixée à 12
C'est logiquement appelé seau qui fuit, et il est implémenté sous forme de file d'attente fifo, mettant temporairement en cache les requêtes qui ne peuvent pas être exécutées. La vitesse de fuite est toujours de 100 ms par requête, mais les requêtes qui arrivent simultanément et ne peuvent pas être exécutées temporairement peuvent d'abord être mises en cache. Ce n'est que lorsque la file d'attente est pleine que les nouvelles demandes seront refusées.
Bien qu'il ait été exécuté, le délai a été considérablement augmenté en raison de la file d'attente d'exécution, ce qui est encore inacceptable dans de nombreux scénarios.
nodelay
Continuez à modifier la configuration pour résoudre le problème d'augmentation du délai causé par un délai trop long
limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s; server { location /login/ { limit_req zone=ip_limit burst=12 nodelay; proxy_pass http://login_upstream; } }
nodelay Avancez l'heure de début de l'exécution de la requête. Dans le passé, elle était retardée jusqu'à ce qu'elle s'échappe. Le bucket. Désormais, il n'y a plus de délai. Dès qu'il est placé dans le bucket, il sera exécuté immédiatement ou la demande ne sera pas retardée en raison de la limitation de courant.
Parce que les requêtes s'échappent du bucket à une vitesse constante et que l'espace du bucket est fixe, au final, en moyenne, 5 requêtes sont exécutées par seconde, et l'objectif de limitation de courant est toujours atteint.
Mais cela présente aussi des inconvénients. La limite actuelle est limitée, mais la limite n'est pas si uniforme. En prenant la configuration ci-dessus comme exemple, si 12 requêtes arrivent en même temps, alors ces 12 requêtes peuvent être exécutées immédiatement, et les requêtes suivantes ne peuvent être saisies dans le compartiment qu'à une vitesse constante, et une requête sera exécutée toutes les 100 ms. S'il n'y a aucune requête pendant un certain temps et que le compartiment est vide, 12 requêtes simultanées peuvent être exécutées en même temps.
Dans la plupart des cas, cette limitation de courant inégale n'est pas un gros problème. Cependant, nginx fournit également un paramètre pour contrôler l'exécution simultanée, qui est le nombre de requêtes nodelay. Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;
server {
location /login/ {
limit_req zone=ip_limit burst=12 delay=4;
proxy_pass http://login_upstream;
}
}
De cette façon, en contrôlant la valeur du paramètre delay, le nombre de requêtes pouvant être exécutées simultanément peut être ajusté pour effectuer les requêtes même et consommer certaines ressources. Encore faut-il contrôler cette quantité dans le service.