Délai de visibilité Amazon SQS

Lorsque vous recevez un message 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 empêche les autres consommateurs de traiter le même message pendant que vous y travaillez. Amazon SQS propose deux options pour supprimer les messages après leur traitement :

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

• Suppression automatique — Pris en charge dans certains cas AWS SDKs, les messages sont automatiquement supprimés en cas de traitement réussi, ce qui simplifie les flux de travail.

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 délai de traitement prolongé. Cela garantit que d'autres consommateurs ne reçoivent pas le même message pendant son traitement, évitant ainsi le double travail et préservant l'efficacité du système.

Mettez en œuvre des mécanismes de nouvelle tentative : prolongez le délai de visibilité par programmation pour les tâches qui ne sont pas terminées dans le délai initial. Si une tâche ne s'exécute pas dans le délai de visibilité initial, vous pouvez prolonger ce délai par programmation. Cela permet à votre système de réessayer de traiter le message sans qu'il ne soit visible pour les autres utilisateurs, ce qui améliore la tolérance aux pannes et la fiabilité. Associez-le à Dead-Letter Queues (DLQs) 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 délais de traitement attendus pour les différents composants. Cela permet de maintenir la cohérence et d'éviter les conditions de course 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 monopoliser inutilement les ressources. Cela conduit à une meilleure performance globale du système et à une meilleure rentabilité.

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

Le délai d'expiration de visibilité commence dès qu'un message vous est délivré. 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 imparti, le message redevient visible dans la file d'attente et peut être récupéré par un autre consommateur. 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 les messages individuels sans modifier les paramètres généraux de la file d'attente. Utilisez cette ChangeMessageVisibilityaction pour prolonger ou raccourcir le délai d'expiration par programmation selon les besoins.

Messages et quotas en vol

Dans Amazon SQS, les messages en cours de 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 cours de vol, en fonction du trafic des files 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 en cours de vol ne sont pas supprimés. Pour les files d'attente FIFO, les limites dépendent des groupes de messages actifs.

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

• Lorsque vous utilisez un long sondage : si vous utilisez un long sondage, Amazon SQS ne renvoie pas d'erreur lorsque la limite de messages en cours de 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. Surveillez avec CloudWatch — Réglez des alarmes en cas de nombre élevé 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 clients supplémentaires pour équilibrer la charge de travail et éviter les embouteillages.

4. Demander une augmentation du quota : envoyez une demande au AWS Support si des limites plus élevées sont requises.

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

Dans les files d'attente standard et FIFO (premier entré, premier sorti), 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 at-least-once diffusion d'Amazon SQS, il n'existe aucune garantie absolue qu'un message ne sera pas diffusé plus d'une fois pendant la période d'expiration de visibilité.

• Files d'attente standard — Le délai de visibilité dans les files d'attente standard empêche plusieurs clients de traiter le même message en même temps. Cependant, en raison du modèle de at-least-once diffusion, Amazon SQS ne garantit pas qu'un message ne sera pas diffusé plus d'une fois pendant le délai de visibilité imparti.

• Files d'attente FIFO — Pour les files d'attente FIFO, les messages ayant le même ID 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 transfert, les messages suivants de ce groupe ne sont pas disponibles tant que le message en cours de vol n'est pas supprimé ou que le délai de visibilité n'expire pas. Cependant, cela ne « verrouille » pas le groupe indéfiniment : chaque message est traité en séquence, et ce n'est que lorsque chaque message est supprimé ou redevient visible que le message suivant de ce groupe sera mis à la disposition des consommateurs. Cette approche garantit un traitement ordonné au sein du groupe sans empêcher inutilement le groupe de délivrer 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 pour une autre tentative de traitement. Cela garantit que les messages ne sont pas perdus même en cas d'échec du traitement initial. Toutefois, le fait de définir un délai de visibilité trop élevé 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 prévu pour un traitement rapide des messages.

Modification et fin du délai de visibilité

Vous pouvez modifier ou mettre fin au délai de visibilité à l'aide de l'ChangeMessageVisibilityaction suivante :

• Modification du délai d'expiration — Ajustez le délai de visibilité de manière dynamique à l'aide de. ChangeMessageVisibility Cela vous permet de prolonger ou de réduire les délais d'attente pour répondre aux 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 de visibilité en réglant le délai VisibilityTimeout à 0 seconde pendant la durée de l'action. ChangeMessageVisibility Cela met immédiatement le message à la disposition des autres consommateurs pour qu'ils puissent le traiter.

Bonnes pratiques

Suivez les bonnes pratiques suivantes pour gérer les délais de visibilité dans Amazon SQS, notamment en définissant, en ajustant et en prolongeant les délais, ainsi que pour gérer les messages non traités à l'aide de files d'attente de lettres mortes (). DLQs

• Réglage et ajustement du délai d'attente. Commencez par définir le délai de visibilité pour qu'il corresponde à la durée maximale dont votre application a généralement besoin pour traiter et supprimer un message. Si vous n'êtes pas sûr du délai de traitement exact, commencez par un délai plus court (par exemple, 2 minutes) et prolongez-le si nécessaire. Mettez en œuvre 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 traités et d'éviter une visibilité prématurée.

• Prolongation du délai d'attente et gestion de la limite de 12 heures. Si votre délai de traitement varie ou peut dépasser le délai 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. La prolongation du délai d'attente ne rétablit pas cette limite de 12 heures. Si votre traitement prend 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 à plusieurs tentatives de traitement, configurez une file d'attente de lettres mortes (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, empêchant ainsi leur circulation répétée dans la file d'attente principale.