View a markdown version of this page

Délai de visibilité Amazon SQS - Amazon Simple Queue Service

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Délai de visibilité Amazon SQS

Lorsque vous recevez un message provenant d'une file d'attente Amazon SQS, il reste dans la file d'attente mais devient temporairement invisible pour les autres consommateurs. Cette invisibilité est contrôlée par le délai de visibilité, qui garantit que les autres consommateurs ne peuvent pas traiter le même message pendant que vous travaillez dessus. Amazon SQS propose deux options pour supprimer des messages après leur traitement :

  • Suppression manuelle : vous supprimez explicitement les messages à l'aide de DeleteMessage cette action.

  • Suppression automatique  : pris en charge dans certains AWS SDK, les messages sont automatiquement supprimés une fois leur traitement réussi, ce qui simplifie les flux de travail.

Graphique chronologique affichant la façon dont les demandes sont traitées pendant le délai de visibilité

Cas d'utilisation du délai de visibilité

Gérez les tâches de longue durée  : utilisez le délai de visibilité pour gérer les tâches nécessitant des délais de traitement prolongés. Définissez un délai de visibilité approprié pour les messages nécessitant un temps de traitement prolongé. Cela garantit que les autres consommateurs ne reçoivent pas le même message pendant son traitement, évitant ainsi la duplication des tâches et préservant l'efficacité du système.

Implémentez des mécanismes de nouvelle tentative  : prolongez le délai de visibilité par programmation pour les tâches qui ne s'achèvent pas dans le délai initial. Si une tâche ne s'exécute pas dans le délai de visibilité initial, vous pouvez prolonger le délai par programmation. Cela permet à votre système de réessayer de traiter le message sans qu'il soit visible pour les autres consommateurs, ce qui améliore la tolérance aux pannes et la fiabilité. Associez-le à des Dead-Letter files d'attente (DLQ) pour gérer les défaillances persistantes.

Coordonner les systèmes distribués  : utilisez le délai de visibilité SQS pour coordonner les tâches entre les systèmes distribués. Définissez des délais de visibilité qui correspondent aux temps de traitement prévus pour les différents composants. Cela permet de maintenir la cohérence et d'éviter les situations de concurrence dans les architectures distribuées complexes.

Optimisation de l'utilisation des ressources  : ajustez les délais de visibilité SQS pour optimiser l'utilisation des ressources dans votre application. En définissant des délais d'expiration appropriés, vous pouvez vous assurer que les messages sont traités efficacement sans épuiser inutilement les ressources. Cela conduit à une meilleure performance globale du système et à une meilleure rentabilité.

Réglage et réglage du délai de visibilité

Le délai de visibilité commence dès qu'un message vous est envoyé. Au cours de cette période, vous êtes censé traiter et supprimer le message. Si vous ne le supprimez pas avant l'expiration du délai, le message redevient visible dans la file d'attente et peut être récupéré par un autre utilisateur. Le délai de visibilité par défaut pour une file d'attente est de 30 secondes, mais vous pouvez l'ajuster en fonction du temps dont votre application a besoin pour traiter et supprimer un message. Vous pouvez également définir un délai de visibilité spécifique pour des messages individuels sans modifier les paramètres généraux de la file d'attente. Utilisez cette ChangeMessageVisibility action pour prolonger ou raccourcir le délai d'attente par programmation, selon les besoins.

Messages et quotas en vol

Dans Amazon SQS, les messages en vol sont des messages qui ont été reçus par un consommateur mais qui n'ont pas encore été supprimés. Pour les files d'attente standard, la limite est d'environ 120 000 messages en vol, en fonction du trafic en file d'attente et de l'arriéré de messages. Si vous atteignez cette limite, Amazon SQS renvoie un OverLimit message d'erreur indiquant qu'aucun message supplémentaire ne peut être reçu tant que certains messages de bord ne sont pas supprimés. Pour les files d'attente FIFO, les limites dépendent des groupes de messages actifs.

  • Lors de l'utilisation de l'interrogation courte  : si cette limite est atteinte lors de l'utilisation de l'interrogation courte, Amazon SQS renvoie un message OverLimit d'erreur indiquant qu'aucun message supplémentaire ne peut être reçu tant que certains messages de bord ne sont pas supprimés.

  • En cas d'interrogation longue  : si vous utilisez une interrogation longue, Amazon SQS ne renvoie pas d'erreur lorsque la limite de messages en vol est atteinte. Au lieu de cela, il ne renverra aucun nouveau message tant que le nombre de messages en vol ne sera pas inférieur à la limite.

Pour gérer efficacement les messages en vol :

  1. Suppression rapide — Supprimez les messages (manuellement ou automatiquement) après leur traitement afin de réduire le nombre de messages en vol.

  2. Surveiller avec CloudWatch — Réglez des alarmes en cas de nombre élevé de passagers en vol afin d'éviter d'atteindre la limite.

  3. Répartissez la charge  : si vous traitez un volume élevé de messages, utilisez des files d'attente ou des consommateurs supplémentaires pour équilibrer la charge et éviter les goulots d'étranglement.

  4. Demander une augmentation de quota — Soumettez une demande au AWS support si des limites plus élevées sont requises.

Comprendre le délai de visibilité dans les files d'attente standard et FIFO

Dans les files d'attente standard et FIFO (First-In-First-Out), le délai de visibilité permet d'empêcher plusieurs consommateurs de traiter le même message simultanément. Cependant, en raison du modèle de diffusion au moins une fois d'Amazon SQS, il n'existe aucune garantie absolue qu'un message ne sera pas envoyé plus d'une fois pendant la période de visibilité.

  • Files d'attente standard — Le délai de visibilité dans les files d'attente standard empêche plusieurs consommateurs de traiter le même message en même temps. Cependant, en raison du modèle de diffusion au moins une fois, Amazon SQS ne garantit pas qu'un message ne sera pas envoyé plus d'une fois pendant la période de visibilité.

  • Files d'attente FIFO — Pour les files d'attente FIFO, les messages ayant le même identifiant de groupe de messages sont traités dans un ordre strict. Lorsqu'un message avec un identifiant de groupe de messages est en cours de vol, les messages suivants de ce groupe ne sont disponibles que lorsque le message en vol est supprimé ou que le délai de visibilité expire. Toutefois, cela ne « verrouille » pas le groupe indéfiniment : chaque message est traité dans l'ordre, et ce n'est que lorsque chaque message est supprimé ou redevient visible que le message suivant de ce groupe sera disponible pour les consommateurs. Cette approche garantit un traitement ordonné au sein du groupe sans empêcher inutilement le groupe de transmettre des messages.

Gestion des défaillances

Si vous ne traitez pas et ne supprimez pas un message avant l'expiration du délai de visibilité (en raison d'erreurs d'application, de pannes ou de problèmes de connectivité), le message redevient visible dans la file d'attente. Il peut ensuite être récupéré par le même consommateur ou par un autre consommateur pour une nouvelle tentative de traitement. Cela garantit que les messages ne sont pas perdus même en cas d'échec du traitement initial. Cependant, un réglage trop élevé du délai de visibilité peut retarder la réapparition des messages non traités, ce qui peut ralentir les nouvelles tentatives. Il est essentiel de définir un délai de visibilité approprié en fonction du temps de traitement attendu pour une gestion des messages en temps opportun.

Modification et fin du délai de visibilité

Vous pouvez modifier le délai de visibilité ou y mettre fin en utilisant l'ChangeMessageVisibilityaction suivante :

  • Modifier le délai d'attente — Ajustez le délai de visibilité de manière dynamique à l'aide de. ChangeMessageVisibility Cela vous permet de prolonger ou de réduire les durées de temporisation en fonction des besoins de traitement.

  • Fin du délai d'attente — Si vous décidez de ne pas traiter un message reçu, mettez fin à son délai d'expiration de visibilité en le réglant sur 0 seconde VisibilityTimeout au cours de l'action. ChangeMessageVisibility Cela met immédiatement le message à la disposition des autres consommateurs pour qu'ils puissent le traiter.

Bonnes pratiques

Utilisez les bonnes pratiques suivantes pour gérer les délais de visibilité dans Amazon SQS, notamment en définissant, ajustant et prolongeant les délais d'expiration, ainsi que pour gérer les messages non traités à l'aide des Dead-Letter files d'attente (DLQ).

  • Régler et ajuster le délai d'attente. Commencez par définir le délai de visibilité pour qu'il corresponde au temps maximum dont votre application a généralement besoin pour traiter et supprimer un message. Si vous n'êtes pas sûr du temps de traitement exact, commencez par un délai plus court (par exemple, 2 minutes) et prolongez-le si nécessaire. Implémentez un mécanisme de pulsation pour prolonger périodiquement le délai de visibilité, en veillant à ce que le message reste invisible jusqu'à la fin du traitement. Cela permet de minimiser les délais de retraitement des messages non gérés et d'éviter une visibilité prématurée.

  • Prolonger le délai d'attente et gérer la limite de 12 heures. Si votre temps de traitement varie ou peut dépasser le délai d'expiration initialement défini, utilisez l'ChangeMessageVisibilityaction pour prolonger le délai de visibilité pendant le traitement du message. N'oubliez pas que le délai de visibilité est limité à 12 heures à compter de la première réception du message. L'allongement du délai d'attente ne réinitialise pas cette limite de 12 heures. Si votre traitement nécessite plus de temps que cette limite, envisagez d'utiliser AWS Step Functions ou de diviser la tâche en étapes plus petites.

  • Gestion des messages non traités. Pour gérer les messages qui échouent lors de plusieurs tentatives de traitement, configurez une Dead-Letter file d'attente (DLQ). Cela garantit que les messages qui ne peuvent pas être traités après plusieurs tentatives sont capturés séparément pour une analyse ou un traitement plus approfondis, ce qui les empêche de circuler à plusieurs reprises dans la file d'attente principale.