Utilisation de l'ID de déduplication du message Amazon SQS

L'ID de déduplication de messages est le jeton utilisé pour la déduplication des messages envoyés. Si un message avec un ID de déduplication de message particulier est correctement envoyé, tous les messages envoyés avec le même ID de déduplication de message sont correctement acceptés, mais ne sont pas remis pendant l'intervalle de déduplication de 5 minutes.

Note

Amazon SQS continue de suivre l'ID de déduplication du message même après la réception et la suppression du message.

Fourniture de l'ID de déduplication du message

Le producteur doit fournir des valeurs d'ID de déduplication du message pour chaque message dans les scénarios suivants :

• Messages envoyés avec des corps identiques qu'Amazon SQS doit traiter comme uniques.

• Messages envoyés avec un contenu identique, mais des attributs différents qu'Amazon SQS doit traiter comme uniques.

• Messages envoyés avec un contenu différent (par exemple, le nombre de tentatives inclus dans le corps du message) qu'Amazon SQS doit traiter comme des doublons.

Activation de la déduplication pour un système producteur/consommateur unique

Si vous avez un seul producteur et un seul consommateur, et que les messages sont uniques parce qu'un ID de message spécifique à l'application est inclus dans le corps du message, suivez ces bonnes pratiques :

• Activez la déduplication basée sur le contenu pour la file d'attente (chacun de vos messages a un corps unique). Le producteur peut ignorer l'ID de déduplication du message.

• Lorsque la déduplication basée sur le contenu est activée pour une file d'attente Amazon SQS FIFO et qu'un message est envoyé avec un ID de déduplication, l'ID de déduplication remplace l'ID de déduplication basé sur le contenu SendMessage généré.

• Même si le consommateur n'est pas tenu de fournir un ID de tentative de demande de réception pour chaque demande, il vaut mieux le faire, car cela permet aux séquences échec-réessayer de s'exécuter plus rapidement.

• Vous pouvez réessayer d'envoyer ou de recevoir des demandes, car elles n'interfèrent pas avec l'ordre des messages dans les files d'attente FIFO.

Conception de scénarios de récupération après une panne

Le processus de déduplication dans les files d'attente FIFO est prioritaire. Lors de la conception de l'application, assurez-vous que le producteur et le consommateur peuvent récupérer en cas de panne du client ou du réseau.

• Le producteur doit connaître l'intervalle de déduplication de la file d'attente. Amazon SQS a un intervalle de déduplication de 5 minutes. De nouvelles tentatives de demandes de SendMessage après expiration du délai de déduplication peuvent introduire des messages en double dans la file d'attente. Par exemple, un appareil mobile dans une voiture envoie des messages dont l'ordre est important. Si la voiture perd la connectivité cellulaire pendant un certain temps avant de recevoir une confirmation, une nouvelle tentative de la demande après la récupération de la connectivité cellulaire peut créer un doublon.

• Le consommateur doit disposer d'un délai de visibilité réduisant le risque de ne pas pouvoir traiter des messages avant l'expiration de ce délai. Vous pouvez étendre le délai de visibilité pendant que les messages sont en cours de traitement en appelant l'action ChangeMessageVisibility. Toutefois, si le délai de visibilité expire, un autre consommateur peut immédiatement commencer à traiter les messages, un message étant alors traité plusieurs fois. Pour éviter ce scénario, configurez une file d'attente de lettres mortes.

Utilisation des délais de visibilité

Pour des performances optimales, définissez le délai de visibilité pour qu'il soit supérieur au délai de lecture du AWS SDK. Cela s'applique à l'utilisation de l'action d'API ReceiveMessage avec l'attente active de courte durée ou l'attente active de longue durée.