global-throttle: Contrôle de flux à usage général avec support de stockage partagé
Installation
Si vous n'avez pas configuré l'abonnement au dépôt RPM, inscrivez-vous. Ensuite, vous pouvez procéder avec les étapes suivantes.
CentOS/RHEL 7 ou Amazon Linux 2
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install lua-resty-global-throttle
CentOS/RHEL 8+, Fedora Linux, Amazon Linux 2023
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install lua5.1-resty-global-throttle
Pour utiliser cette bibliothèque Lua avec NGINX, assurez-vous que nginx-module-lua est installé.
Ce document décrit lua-resty-global-throttle v0.2.0 publié le 30 décembre 2020.
Utilisation
Une implémentation de limitation de débit générique et distribuée pour Openresty. Elle peut être utilisée pour limiter toute action, qu'il s'agisse d'une requête ou d'un appel de fonction. Actuellement, seule la limitation de débit approximative par fenêtre glissante est implémentée.
Tout d'abord, requérez le module :
local global_throttle = require "resty.global_throttle"
Après cela, vous pouvez créer une instance de throttle comme suit, où 100 est la limite qui sera appliquée par fenêtre de 2 secondes. Le troisième paramètre indique au throttler quel fournisseur de stockage il doit utiliser pour stocker ses statistiques internes.
local memc_host = os.getenv("MEMCACHED_HOST")
local memc_port = os.getenv("MEMCACHED_PORT")
...
local my_throttle, err = global_throttle.new(namespace, 10, 2, {
provider = "memcached",
host = memc_host,
port = memc_port,
connect_timeout = 15,
max_idle_timeout = 10000,
pool_size = 100,
})
Enfin, vous appelez ce qui suit chaque fois avant ce que vous êtes en train de limiter :
local estimated_final_count, desired_delay, err = my_throttle:process("identifiant de ce que vous êtes en train de limiter")
Lorsque desired_delay existe, cela signifie que la limite est dépassée et que le client doit être limité pendant desired_delay secondes.
Pour une compréhension plus complète de la façon d'utiliser cette bibliothèque, référez-vous au répertoire examples.
Considérations de production
- Assurez-vous de configurer correctement la taille du pool de connexions. En gros, si votre stockage (c'est-à-dire memcached) peut gérer
nconnexions simultanées et que votre NGINX amworkers, alors la taille du pool de connexions doit être configurée commen/m. C'est parce que la taille du pool configurée est par worker NGINX. Par exemple, si votre stockage gère généralement 1000 requêtes simultanées et que vous avez 10 workers NGINX, alors la taille du pool de connexions doit être de 100. De même, si vous avezpinstances NGINX différentes, alors la taille du pool de connexions doit êtren/m/p. - Faites attention lorsque vous prenez des décisions de mise en cache basées sur
desired_delay, parfois il est trop petit pour que votre cache puisse l'interpréter comme 0 et mettre en cache indéfiniment. De plus, mettre en cache pendant très peu de temps n'apporte probablement aucun avantage.
Contributions et développement
La bibliothèque est conçue pour être extensible. Actuellement, seul l'algorithme de fenêtre glissante approximatif est implémenté dans lib/resty/global_throttle/sliding_window.lua. Il peut être utilisé comme point de référence pour implémenter d'autres algorithmes.
Les fournisseurs de stockage sont implémentés dans lib/resty/global_throttle/store/.
Références
- Article de blog de Cloudflare sur la fenêtre glissante approximative : https://blog.cloudflare.com/counting-things-a-lot-of-different-things/
GitHub
Vous pouvez trouver des conseils de configuration supplémentaires et de la documentation pour ce module dans le dépôt GitHub pour nginx-module-global-throttle.