Gardez les tâches disponibles lorsque les consommateurs sont lents ou échouent, avertissez les équipes en aval et protégez les résultats métier contre les livraisons répétées. Apprenez SQS et SNS à travers un petit processus de traitement de commandes.
Cinq laboratoires guidés couvrent la consommation, la visibilité, les files de lettres mortes, la diffusion SNS et la protection contre les doublons. Le défi autonome répare un incident dans lequel les tâches échouées n’atteignent jamais la file de récupération.
Ce que vous apprendrez
- Envoyer, recevoir, traiter et acquitter des tâches SQS
- Observer les fenêtres de visibilité, les nouvelles livraisons et les identifiants de réception actuels
- Isoler les tâches échouées dans une file de lettres mortes
- Diffuser les notifications SNS vers des abonnements SQS filtrés
- Utiliser des écritures conditionnelles DynamoDB pour protéger une opération métier répétée
- Réparer l’acheminement des tâches échouées pendant que les tâches saines continuent
- Vérifier les résultats stockés et supprimer uniquement les ressources qui vous appartiennent
À qui s’adresse ce cours
Ce cours s’adresse aux apprenants prêts à étendre une application sans serveur avec des tâches asynchrones et la gestion des échecs.
Prérequis : Commencez par l’accès Lambda–DynamoDB (FN03) et ses prérequis. Q01 → Q02 → Q03 enseignent traitement et isolation des échecs. Q04 est une branche SNS avec politiques de ressources IAM ; Q05 demande écritures conditionnelles DynamoDB (D04) et mises à jour Lambda (FN02). Le défi suit Q03 ; PS02 utilise aussi Q05.
Environnement d’apprentissage : Toutes les activités se déroulent dans un environnement Linux LabEx fourni, accessible dans le navigateur. Utilisez Terminal pour les commandes AWS CLI et AWS View, à côté de Terminal, pour examiner le même état des ressources et des applications. Les outils et la connexion sont prêts ; vous n’avez besoin ni d’un compte AWS personnel ni de clés d’accès. Chaque laboratoire commence indépendamment dans une nouvelle VM. AWS View affiche les files, les corps des messages, les tentatives, les journaux, les enveloppes SNS et les commandes stockées. L’observation en lecture seule ne reçoit ni n’acquitte les messages.
Questions fréquentes
Une file configurée prouve-t-elle que les tâches sont traitées ?
Non. Vérifiez le traitement réel, les résultats stockés, les messages sources acquittés et les tâches échouées conservées. Les traitements et données de référence fournis vous permettent de vous concentrer sur ces résultats avec des tâches fictives.
Pourquoi un message possède-t-il un nouvel identifiant de réception ?
Un identifiant de réception appartient à une livraison. Lorsque la visibilité expire, une autre tentative peut avoir lieu avec un nouvel identifiant. Utilisez celui de la livraison que vous souhaitez acquitter.
La protection contre les doublons signifie-t-elle une livraison exactement une fois ?
Non. Les files standard peuvent livrer plusieurs fois. Une écriture conditionnelle sur un élément protège l’effet métier enseigné, mais les opérations de file et les écritures en base restent distinctes ; il ne s’agit ni d’une transaction atomique ni d’une garantie de traitement exactement une fois de bout en bout.
Quel est le périmètre des exemples de messagerie ?
Les files standard avec un consommateur traitant un message à la fois, la réacheminement vers une file de lettres mortes, la diffusion SNS vers SQS dans le même compte et les filtres d’attributs de message. L’ordre FIFO, les lots arbitraires, le débit en production, les politiques entre comptes et les garanties complètes de nouvelles tentatives des services dépassent le cadre du cours.
Quel projet suit ce cours ?
Recover Poison Messages Without Duplicating Orders dans le cours de projet Serverless. Le défi demande Q03 et ses prérequis ; le projet aussi Q05. Vérifiez le fonctionnement avant le nettoyage.
