Comprenez les limitations de courant et les solutions courantes en dix minutes !

Récemment, j'ai reçu des commentaires d'interview de plusieurs internautes, et on leur a tous posé des questions liées aux limitations actuellesau cours de l'interview. Parlons des différentes solutions limitantes actuelles dans notre projet aujourd'hui.

Concept de base de la limitation de courant

Pour les scénarios généraux de limitation de courant, il comporte

deux dimensions

d'informations :

La limitation temporelle du courant est basée sur une certaine plage horaire ou un certain moment dans le temps , C'est ce que nous appelons souvent « fenêtre horaire », comme limiter la fenêtre horaire par minute et par seconde
Les ressources sont basées sur les limitations des ressources disponibles, comme la définition du nombre maximum de visites, ou du nombre maximum de connexions disponibles
En combinant les deux dimensions ci-dessus, la limitation actuelle consiste à limiter l'accès aux ressources dans une certaine fenêtre de temps, par exemple en fixant un maximum de 100 demandes d'accès par seconde. Mais dans un scénario réel, nous définissons non seulement une règle de limitation de courant, mais également plusieurs règles de limitation de courant pour fonctionner ensemble. Les principales règles de limitation de courant sont les suivantes :

Contrôle du QPS et du numéro de connexion

Pour (

connexions. Pour les données

et QPS) limitation de courant, nous pouvons définir une limitation de courant dans la dimension IP, ou nous pouvons définir une limitation de courant basée sur un seul serveur.

Images

Dans des environnements réels, des règles de limitation actuelles dans plusieurs dimensions sont généralement définies, comme définir la fréquence d'accès de la même IP à moins de 10 par seconde, le nombre de connexions à moins de 5, puis en fixant le QPS maximum de chaque machine à 1 000, le nombre maximum de connexions est maintenu à 200. De plus, nous pouvons traiter un groupe de serveurs ou les serveurs de l'ensemble de la salle informatique dans leur ensemble et définir des règles de limitation de courant de niveau supérieur. Toutes ces règles de limitation de courant fonctionneront ensemble pour le contrôle du trafic.

Taux de transmission

Tout le monde connaît le « taux de transmission », comme la vitesse de téléchargement des ressources. Certains sites Web ont une logique de limitation actuelle plus détaillée dans ce domaine. Par exemple, la vitesse de téléchargement pour les utilisateurs enregistrés ordinaires est de 100 000/s, et après l'achat d'un abonnement, elle est de 10 M/s. Derrière cela se cache la logique de limitation actuelle basée sur les groupes d'utilisateurs. ou des balises utilisateur.

Listes noires et blanches

Les listes noires et blanches sont un moyen très courant de limiter et de libérer le trafic dans les applications des grandes entreprises, et les listes noires et blanches changent souvent de manière dynamique. Par exemple, si une adresse IP a été visitée trop fréquemment au cours d'une période donnée et est identifiée par le système comme un utilisateur de robot ou une attaque de trafic, l'adresse IP sera ajoutée à la liste noire, limitant ainsi son accès aux ressources du système. ce que nous appelons communément le « blocage IP ».

Les programmes d'exploration que nous voyons habituellement, tels que l'exploration de photos de belles femmes sur Zhihu ou l'exploration d'informations de partage de temps d'actions sur les systèmes de courtage, ces programmes d'exploration doivent implémenter la fonction de changement d'adresse IP pour éviter d'être ajoutés à la liste noire.

Parfois, nous constatons également que le réseau de l'entreprise ne peut pas accéder aux grands sites Web publics tels que 12306. C'est également parce que les adresses IP sortantes de certaines entreprises sont la même adresse. Par conséquent, lorsque le nombre de visites est trop élevé, cette adresse IP sera utilisée. être utilisé par l’autre partie identifiée par le système puis ajoutée à la liste noire. Les étudiants qui utilisent le haut débit à domicile doivent savoir que la plupart des opérateurs de réseau attribuent aux utilisateurs différents segments IP sortants ou modifient dynamiquement l'adresse IP de l'utilisateur de temps en temps.

La liste blanche est plus facile à comprendre. Elle équivaut à avoir une médaille d'or décernée par la famille royale. Vous pouvez librement parcourir les différentes règles de limitation actuelles sans aucune entrave. Par exemple, certaines sociétés de commerce électronique ajouteront les comptes de très gros vendeurs à la liste blanche, car ces vendeurs disposent souvent de leurs propres systèmes d'exploitation et de maintenance et doivent s'interfacer avec le système informatique de l'entreprise pour effectuer un grand nombre de lancements de produits, de réapprovisionnements. , etc. De plus, recherchez le backend du compte public Programming Technology Circle et répondez « Java » pour obtenir un coffret cadeau surprise.

Environnement distribué

Distribué est différent du scénario de limitation de courant sur une seule machine. Il considère tous les serveurs de l'ensemble de l'environnement distribué dans son ensemble. Par exemple, pour la limitation du courant IP, nous limitons une IP à un maximum de 10 visites par seconde. Quelle que soit la machine sur laquelle tombe la requête de cette IP, tant qu'elle accède au nœud de service dans le cluster, elle sera soumise à. limitation de courant. Contraint par des règles.

Nous ferions mieux de sauvegarder les informations de limitation de courant dans un composant « centralisé » afin qu'il puisse obtenir l'état d'accès de toutes les machines du cluster. Actuellement, il existe deux solutions de limitation de courant courantes :

• Limitation de courant de la couche passerelle. applique les règles de limitation actuelles à l'entrée de tout le trafic
• La limitation actuelle du middleware stocke les informations de limitation actuelles dans un middleware dans un environnement distribué (tel que le cache Redis), et chaque composant peut y accéder à partir d'ici. Obtenez les statistiques de trafic à l'adresse moment actuel pour décider s'il faut refuser le service ou autoriser le trafic
• sentinel, un composant conçu sur mesure par l'écosystème springcloud pour les microservices pour la limitation de courant distribué, la dégradation des disjoncteurs et d'autres composants

Algorithmes couramment utilisés pour la limitation de courant schémas

Algorithme de compartiment de jetons

Seau de jetons L'algorithme de compartiment de jetons est actuellement l'algorithme de limitation de courant le plus largement utilisé. Comme son nom l'indique, il a les deux rôles clés suivants :

.

• Le jeton ne sera traité qu'après l'obtention du jeton. Les autres demandes sont soit mises en file d'attente, soit rejetées directement.
• Toutes les demandes obtiennent des jetons de ce compartiment.
• Génération de jetons

Ce processus implique le générateur de jetons et le compartiment de jetons. Nous avons mentionné plus tôt que le compartiment de jetons est un emplacement pour les jetons. Puisqu'il s'agit d'un seau, il doit y avoir une capacité, ce qui signifie. que le nombre de jetons que le compartiment de jetons peut contenir est une valeur fixe.

Pour le générateur de jetons, il ajoutera des jetons au bucket selon un rythme prédéterminé. Par exemple, nous pouvons le configurer pour émettre des jetons à raison de 100 requêtes par seconde, soit 50 par minute. Notez que la vitesse d'émission ici est uniforme, ce qui signifie que ces 50 jetons ne sont pas émis en une seule fois au début de chaque fenêtre horaire, mais seront émis à une vitesse uniforme au cours de cette fenêtre horaire.

Le distributeur de jetons est un robinet. Si le seau contenant l'eau en dessous est plein, alors l'eau (le jeton) s'écoulera naturellement vers l'extérieur. Il en va de même pendant le processus d'émission de jetons. La capacité du compartiment de jetons est limitée. Si les jetons de la capacité nominale sont actuellement remplis, les nouveaux jetons seront supprimés.

• Acquisition de jeton

Après l'arrivée de chaque demande d'accès, un jeton doit être obtenu pour exécuter la logique suivante. Si le nombre de tokens est faible et qu'il y a de nombreuses demandes d'accès, certaines requêtes ne pourront naturellement pas obtenir de tokens. A ce moment, nous pouvons mettre en place une « file d'attente tampon » pour stocker temporairement ces tokens excédentaires.

La file d'attente tampon est en fait une option facultative, et tous les programmes qui appliquent l'algorithme du compartiment à jetons n'implémenteront pas des files d'attente. Lorsqu'il existe une file d'attente de cache, les demandes qui n'ont pas encore obtenu de jeton seront mises en file d'attente dans cette file d'attente jusqu'à ce qu'un nouveau jeton soit généré, puis une demande est extraite de la tête de la file d'attente pour correspondre au jeton.

Lorsque la file d'attente est pleine, ces demandes d'accès seront rejetées. Dans des applications pratiques, nous pouvons également ajouter une série d'effets spéciaux à cette file d'attente, comme définir le temps de survie des requêtes dans la file d'attente, ou transformer la file d'attente en PriorityQueue, en triant selon une certaine priorité au lieu de premier entré, premier sorti. .

Leaky Bucket Algorithm

Leaky Bucket est un autre bucket. L'algorithme de limitation actuel est lié au bucket. Alors, quelle est la différence entre le bucket qui fuit et le bucket à jetons

La première moitié de l'algorithme du bucket qui fuit est similaire au jeton. Cependant, les objets de l'opération sont différents. Le compartiment de jetons place les jetons dans le compartiment, tandis que le compartiment qui fuit met le paquet de demande d'accès dans le compartiment. De même, si le compartiment est plein, les paquets entrants seront rejetés.

La seconde moitié de l'algorithme du bucket qui fuit est distinctive. Elle fera toujours sortir les paquets de données du bucket à un débit constant. Par exemple, si je configure un compartiment qui fuit pour stocker 100 paquets de données, et que la vitesse de sortie est de un par seconde, quelle que soit la vitesse à laquelle les paquets de données circulent dans le compartiment, et quel que soit le nombre de paquets de données contenus dans le compartiment. , le seau qui fuit peut garantir que ces paquets de données sont toujours traités à une vitesse constante d'une seconde. De plus, recherchez le backend de l'architecte backend du compte public et répondez « architecture propre » pour obtenir un coffret cadeau surprise.

• La différence entre le bucket qui fuit et le bucket à jetons

Ce n'est pas difficile à voir en fonction de leurs caractéristiques respectives. Les deux algorithmes ont un taux "constant" et un taux "indéterminé". Le compartiment de jetons crée des jetons à un rythme constant, mais le taux auquel les demandes d'accès obtiennent des jetons est "non fixé". Quoi qu'il en soit, autant de jetons qu'il y en a, ils seront émis, et si les jetons ont disparu, ils attendront simplement. Le compartiment qui fuit traite les demandes à un rythme « constant », mais le rythme auquel ces demandes affluent dans le compartiment est « variable ».

À partir de ces deux caractéristiques, les caractéristiques naturelles du bucket qui fuit déterminent qu'il n'aura pas de trafic en rafale Même si 1 000 requêtes par seconde arrivent, son taux d'accès à la sortie du service en arrière-plan sera toujours constant. Le compartiment de jetons est différent. Sa fonctionnalité peut « pré-stocker » une certaine quantité de jetons. Par conséquent, tous les jetons peuvent être consommés en peu de temps en cas de trafic soudain. Son efficacité de traitement du trafic en rafale sera supérieure à celle d'une fuite. seau, mais il est guidé La pression sur le système backend augmentera également en conséquence.

Fenêtre coulissante

Par exemple, nous avons 5 utilisateurs visitant chaque seconde et 10 utilisateurs visitant dans la 5ème seconde, alors le nombre de visites dans la fenêtre temporelle de 0 à 5 secondes est de 15. Si notre interface fixe la limite supérieure d'accès dans la fenêtre de temps à 20, alors lorsque le temps atteint la sixième seconde, le décompte total dans cette fenêtre de temps devient 10, car la grille de 1 seconde a quitté la fenêtre de temps, donc dans Le nombre Le nombre de visites pouvant être reçues dans la sixième seconde est de 20-10=10.

La fenêtre glissante est en fait un algorithme de calcul. Elle a une particularité : lorsque la durée de la fenêtre temporelle est plus longue, l'effet de limitation du courant sera plus fluide. Par exemple, si la fenêtre horaire actuelle n'est que de deux secondes et que toutes les demandes d'accès sont concentrées dans la première seconde, lorsque le temps recule d'une seconde, le décompte de la fenêtre actuelle changera considérablement. L'extension de la fenêtre temporelle peut réduire la probabilité. de cela

Solutions de limitation de courant couramment utilisées

Limitation de courant de vérification de légalité

Tels que le code de vérification, la liste noire IP, etc. Ces moyens peuvent empêcher efficacement les attaques malveillantes et la collecte de robots

Limitation de courant Guawa

; Dans le domaine de la limitation de courant, Guava propose [RateLimiter为首的几个限流支持类，但是作用范围仅限于“当前”这台服务器，也就是说Guawa的限流是单机的限流，跨了机器或者jvm进程就无能为力了比如说，目前我有2台服务器[Server 1，Server 2] sous son module multi-thread. Les deux serveurs ont déployé un service de connexion si je souhaite contrôler le trafic de ces deux machines, par exemple, le nombre total de visites des deux. les machines sont contrôlées dans les 20 par seconde. Si vous utilisez Guava, vous ne pouvez contrôler indépendamment que le nombre de visites de chaque machine

Bien que Guava ne soit pas une solution pour les systèmes distribués, en tant que composant de limitation de courant simple et léger côté client, il est très approprié pour expliquer l'algorithme de limitation de courant

Limitation de courant de la couche passerelle

Passerelle de service, comme l'ensemble du système distribué. Le premier niveau du lien gère toutes les demandes des utilisateurs, donc limiter le trafic au niveau de la passerelle est un bon point de départ. Le chemin de haut en bas est le suivant :

1. Le trafic utilisateur est transféré de la couche passerelle vers le service
.
2. Le service en arrière-plan accepte le trafic et appelle le cache pour obtenir des données
3. S'il n'y a pas de données dans le cache, accédez à la base de données

Le trafic diminue couche par couche de haut en bas, et le plus grand et le plus dense le trafic est collecté au niveau de la couche passerelle. Demandes d'accès des utilisateurs, suivies par les services d'arrière-plan.

Après avoir passé la logique de vérification du service en arrière-plan, certaines requêtes erronées sont vidées et les requêtes restantes tombent dans le cache. S'il n'y a pas de données dans le cache, la base de données au bas de l'entonnoir sera demandée, donc. le nombre de requêtes au niveau de la base de données est le plus faible (par rapport à Pour d'autres composants, la base de données est souvent celle avec la pire capacité de concurrence. Même si le MySQL d'Alibaba a subi de nombreuses modifications, la concurrence sur une seule machine n'est pas comparable à composants tels que Redis et Kafka.)

La couche de passerelle principale actuelle est Nginx, représentée par un logiciel, et des composants de couche de passerelle tels que Gateway et Zuul dans Spring Cloud

Limitation actuelle de Nginx

Dans l'architecture du système, le proxy de Nginx et le transfert de routage sont très importants en tant que fonction de couche de passerelle, en raison de la légèreté inhérente et de l'excellente conception de Nginx, il est devenu le premier choix de nombreuses entreprises. Compte tenu du niveau de passerelle, Nginx peut être utilisé comme la passerelle la plus frontale pour résister à la plupart. du trafic réseau, donc Nginx est utilisé pour la limitation de courant est également un bon choix. Dans Nginx, les configurations de politiques couramment utilisées liées à la limitation de courant sont également fournies

Nginx propose deux méthodes de limitation de courant : l'une consiste à contrôler le débit et l'autre. l'autre consiste à contrôler le nombre de connexions simultanées.

Contrôler le débit

Nous devons utiliser limit_req_zone pour limiter le nombre de requêtes par unité de temps, c'est-à-dire la limite de débit,

Parce que les statistiques de limitation actuelles de Nginx sont basées sur des millisecondes, la vitesse que nous définissons est de 2r/s , convertissez-le Autrement dit, une seule adresse IP n'est autorisée à transmettre qu'une seule requête dans un délai de 500 millisecondes, et la deuxième requête n'est autorisée à transmettre qu'à partir de 501 ms.

• Version optimisée du contrôle de débit

Bien que le contrôle de débit ci-dessus soit très précis, il est trop strict dans un environnement de production. Dans des situations réelles, nous devrions contrôler le nombre total d'accès dans une unité IP. le temps total, plutôt que comme ci-dessus, il est précis en millisecondes. Nous pouvons utiliser le mot-clé burst pour activer ce paramètre

.

burst=4signifie chaque IP Autoriser à 4 requêtes en rafaleburst=4意思是每个IP最多允许4个突发请求

控制并发数

利用 limit_conn_zone 和 limit_conn 两个指令即可控制并发数

其中 limit_conn perip 10 表示限制单个 IP 同时最多能持有 10 个连接；limit_conn perserver 100

Contrôlez le nombre de concurrence

Utilisez limit_conn_zone et limit_conn code > Deux instructions peuvent contrôler le nombre de concurrence<p data-tool="mdnice编辑器" style="padding-top: 8px;padding-bottom: 8px;line-height: 26px;"><strong>Parmi elles<code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;background-color : rgba(27, 31, 35, 0.05);famille de polices : " operator mono consolas monaco menlo monospace de mot break-all rgb> limit_conn perip 10 signifie limiter une seule adresse IP pour contenir jusqu'à 10 connexions en même temps ; limit_conn perserver 100 signifie que le serveur peut gérer un total de 100 connexions simultanées en même temps.

Remarque : Cette connexion n'est comptabilisée qu'après le traitement de l'en-tête de la requête par le backend.

Limitation actuelle du middleware

Pour un environnement distribué, ce n'est rien de plus qu'un emplacement central semblable à un nœud pour stocker les données actuellement limitées. Par exemple, si je souhaite contrôler le taux d'accès de l'interface à 100 requêtes par seconde, je dois alors enregistrer le nombre de requêtes reçues dans les 1 actuels quelque part et autoriser l'accès à tous les nœuds de l'environnement de cluster. Alors, quelle technologie pouvons-nous utiliser pour stocker ces données temporaires ?

Ensuite, tout le monde a dû penser qu'il devait s'agir de Redis. Grâce à la fonction de délai d'expiration de Redis, nous pouvons facilement définir la durée de la limite actuelle (comme 10 requêtes par seconde ou 10 requêtes toutes les 10 secondes). Dans le même temps, Redis possède également une compétence particulière : la programmation de scripts. Nous pouvons écrire la logique de limitation actuelle dans un script et l'implanter dans Redis, ce qui sépare complètement la responsabilité de limitation actuelle de la couche de service. caractéristiques de concurrence puissantes et hautes L'architecture de cluster disponible peut également bien prendre en charge un accès actuellement limité à d'énormes clusters (

reids + lua

). 🎜🎜🎜Composants limitant le courant🎜🎜🎜En plus des méthodes présentées ci-dessus, il existe actuellement des composants open source qui fournissent des fonctions similaires, comme Sentinel, qui est un bon choix. Sentinel est un composant open source produit par Alibaba et inclus dans la bibliothèque de composants Spring Cloud Alibaba. Sentinel fournit un riche ensemble d'API pour la limitation de courant et une console de gestion visuelle, qui peuvent facilement nous aider à gérer la limitation de courant.

Considérez la conception de limitation de courant du point de vue architectural

Dans les projets réels, une seule méthode de limitation de courant sera utilisée. Plusieurs méthodes sont souvent utilisées conjointement les unes avec les autres pour donner à la stratégie de limitation de courant un sentiment de hiérarchie et atteindre l'objectif. utilisation maximale des ressources. Dans ce processus, la conception de la stratégie de limitation de courant peut également faire référence au modèle d'entonnoir mentionné précédemment, qui est large en haut et serré en bas. La conception du schéma de limitation de courant pour différentes parties de l'entonnoir doit prêter attention. la haute disponibilité des composants actuels.

Prenons comme exemple le projet auquel j'ai participé. Par exemple, nous avons développé une interface pour la page de détails du produit. Grâce au détournement mobile Taobao, la demande d'accès côté application passera d'abord par la passerelle mtop d'Alibaba. , notre limitation actuelle sera relativement lâche. Une fois que la demande atteint le service de la page de détails du produit backend via la passerelle, une série de composants middleware + limitation de courant sont utilisés pour effectuer un contrôle de limitation de courant plus détaillé sur le service

Spécifique. moyens d'implémenter la limitation de courant

1) Tomcat utilise maxThreads pour implémenter la limitation de courant.

2) limit_req_zoneet burst to mettre en œuvre une limitation de débit. limit_req_zone和 burst来实现速率限流。

3）Nginx的limit_conn_zone和 limit_conn两个指令控制并发连接的总数。

4）时间窗口算法借助 Redis的有序集合可以实现。

5）漏桶算法可以使用Redis-Cell来实现。

6）令牌算法可以解决Google的guava包来实现。

需要注意的是借助Redis实现的限流方案可用于分布式系统，而guava实现的限流只能应用于单机环境。如果你觉得服务器端限流麻烦，可以在不改任何代码的情况下直接使用容器限流（Nginx或Tomcat），但前提是能满足项目中的业务需求。

Tomcat限流

Tomcat 8.5 版本的最大线程数在 conf/server.xml

3) limit_conn_zoneetlimit_connLes deux instructions contrôlent le nombre total de connexions simultanées .

4) L'algorithme de fenêtre temporelle peut être implémenté à l'aide de la collection ordonnée de Redis. 🎜🎜5) L'algorithme du bucket qui fuit peut être implémenté à l'aide de Redis-Cell. 🎜🎜6) L'algorithme de jeton peut être implémenté en résolvant le package guava de Google. 🎜

Il convient de noter que le schéma de limitation actuel implémenté avec Redis peut être Les systèmes distribués utilisés et la limitation de courant mise en œuvre par Guava ne peuvent être appliqués qu'à un environnement autonome. Si vous trouvez la limitation de courant côté serveur problématique, vous pouvez directement utiliser la limitation de courant du conteneur (Nginx ou Tomcat) sans modifier aucun code, mais uniquement si elle peut répondre aux besoins métier du projet. 🎜

Limite actuelle de Tomcat h4 >🎜Le nombre maximum de threads dans la version Tomcat 8.5 est conf / Dans la configuration server.xml, maxThreads est le nombre maximum de threads de Tomcat Lorsque la concurrence des requêtes est supérieure à cette valeur (maxThreads), les requêtes seront mises en file d'attente pour exécution, complétant ainsi l'objectif du courant. limitant. 🎜🎜Remarque :🎜

La valeur de maxThreads peut être augmentée de manière appropriée. Tomcat est par défaut de 150 (Tomcat version 8.5), mais cette valeur n'est pas plus grande, mieux elle dépend de la configuration spécifique du serveur. Il convient de noter que chaque thread démarré consomme 1 Mo. L'espace mémoire JVM est utilisé comme pile de threads, et plus il y a de threads, plus la charge du GC sera lourde.

Enfin, il convient de noter que le système d'exploitation a certaines restrictions sur le nombre de threads dans un processus. Le nombre de threads dans chaque processus de Windows ne peut pas dépasser 2000, et le nombre de threads dans chaque processus de. Linux n'est pas autorisé à dépasser 1000.

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!