Comment configurer la limitation de courant Nginx

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 ?

• Les demandes de fuite de seau qui fuit se font à une vitesse uniforme. Comment 10r/s est-il une vitesse constante ? Une requête est divulguée toutes les 100 ms.
• Dans cette configuration, le bucket est vide et toutes les demandes qui ne peuvent pas être divulguées en temps réel seront rejetées.

  
  Donc si 10 demandes arrivent en même temps, une seule demande pourra être exécutée, et les autres seront rejetées.

Ce n'est pas très convivial. Dans la plupart des scénarios commerciaux, nous espérons que ces 10 demandes pourront être exécutées.

burst

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.

De cette façon, le seau qui fuit limite non seulement le débit, mais joue également le rôle d'écrêtage des pics et de remplissage des vallées.

Dans une telle configuration, si 10 requêtes arrivent en même temps, elles seront exécutées en séquence, une toutes les 100 ms.

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.

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;
  }
}

delay=4 démarre le retard à partir de la 5ème requête dans le bucket

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.

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!