Simple Message Queue (anciennement MNS) applique une politique de limitation aux requêtes dépassant le seuil défini afin d'éviter une pression excessive sur les ressources sous-jacentes. Comprendre cette politique vous aide à planifier raisonnablement la fréquence d'envoi et de réception des messages, et à prendre les mesures appropriées en cas de déclenchement de la limitation.
Comportement de limitation
Lorsque le trafic approche ou atteint le seuil de limitation, le serveur ajuste automatiquement ce seuil de manière élastique en fonction de l'utilisation des ressources en temps réel. Dans la plupart des scénarios, cela permet de prendre en charge un nombre plus élevé de requêtes concurrentes sans que les utilisateurs ne s'en aperçoivent. Si une limitation temporaire est déclenchée (par exemple, en raison de pics de trafic soudains ou de goulots d'étranglement au niveau des ressources du cluster), le système rétablit la capacité de traitement du trafic et augmente simultanément le seuil de limitation une fois la mise à l'échelle automatique terminée.
En cas de déclenchement de la limitation, le système active un mécanisme de contre-pression. Les requêtes dépassant le seuil sont brièvement mises en attente sur le serveur, puis renvoient une erreur 429 (TooManyRequests). Le serveur ajuste dynamiquement la durée de mise en attente en fonction de la charge en temps réel, généralement entre 10 et 500 millisecondes, avec un maximum de 5 secondes. Cela empêche la surcharge du système, qui pourrait affecter les performances globales et la stabilité.
Code d'erreur
Lorsque la politique de limitation est déclenchée, le serveur Simple Message Queue (anciennement MNS) renvoie les informations d'erreur suivantes.
|**Code d'état HTTPS**
|
**Code d'erreur**
|
**Message d'erreur**
| | --- | --- | --- | |
429
|
TooManyRequests
|
The request is denied by cluster flow limiter for too many requests.
|
Seuils de limitation
Politique de limitation en cas de consommation anormale dans le mode de consommation de file d'attente
Dans le modèle standard de consommation de file d'attente, après qu'un client a traité un message avec succès, il doit envoyer une requête au serveur pour supprimer ce message. Si un client présente de manière répétée le comportement non standard consistant à « recevoir des messages sans envoyer de requêtes de suppression », le système signale cette anomalie comme une consommation anormale et déclenche un mécanisme de limitation pour garantir la stabilité du système. Une fois la limitation appliquée, le taux de réception de nouveaux messages par le client est considérablement réduit.
La limitation est déclenchée lorsque l'une des conditions suivantes est remplie :
Durée : la consommation anormale persiste pendant plus de 30 minutes.
Nombre de messages : le nombre cumulatif de messages reçus mais non supprimés atteint 5 000.
Débit du trafic : le taux instantané de messages reçus mais non supprimés dépasse 1 000 TPS.
Politique de limitation pour les requêtes à fort trafic
Le seuil de limitation par défaut par compte Alibaba Cloud et par région est de 20 000 TPS. Si votre trafic dépasse 20 000 TPS, connectez-vous à la console Quota Center pour demander une augmentation du nombre maximal de TPS par région. Pour obtenir la procédure détaillée, consultez Soumettre une demande d'augmentation de quota.
Règles de comptage des requêtes :
Chaque appel d'API compte comme une requête.
Calcul des TPS dans les scénarios d'envoi par lot : lorsque vous appelez l'opération BatchSendMessage sur une file d'attente, les TPS de BatchSendMessage = nombre réel de requêtes BatchSendMessage par seconde × nombre de messages par requête. Par exemple, si BatchSendMessage est appelé 100 fois par seconde et que chaque appel contient 10 messages, les TPS consommés par une seule file d'attente = 100 × 10 = 1 000.
Calcul des TPS dans les scénarios de consommation par lot : lorsque vous appelez l'opération BatchReceiveMessage sur une file d'attente, les TPS de BatchReceiveMessage = nombre réel de requêtes BatchReceiveMessage par seconde (indépendamment du nombre de messages par lot). Par exemple, si BatchReceiveMessage est appelé 100 fois par seconde et que chaque appel contient 10 messages, les TPS consommés par une seule file d'attente = 100.
Éviter l'impact de la limitation
Pour éviter l'impact de la politique de limitation sur votre activité, concentrez-vous sur les deux aspects suivants :
Planifiez soigneusement le trafic et communiquez les pics de trafic à l'avance : si vous prévoyez une croissance importante du trafic et que le nombre de TPS dépasse la valeur maximale que vous pouvez demander dans la console Quota Center, soumettez un ticket pour contacter l'assistance technique afin de réserver davantage de ressources et éviter le déclenchement de la limitation.
Surveillance et alertes : nous vous recommandons d'intégrer Simple Message Queue (anciennement MNS) en configurant une règle d'alerte. Consultez l'utilisation des TPS en temps réel de chaque file d'attente ou topic dans la console CloudMonitor (CloudMonitor console > Cloud Service Monitoring > Message Service MNS) pour détecter quand le seuil de limitation est approché.