Halte Aufträge verfügbar, wenn Verbraucher langsam sind oder ausfallen, benachrichtige nachgelagerte Teams und schütze Geschäftsergebnisse vor wiederholter Zustellung. Lerne SQS und SNS anhand eines kleinen Bestellverarbeitungsablaufs.
Fünf angeleitete Labs behandeln Verarbeitung, Sichtbarkeit, Dead-Letter-Queues, SNS-Verteilung und Duplikatschutz. Die eigenständige Aufgabe repariert einen Vorfall, bei dem fehlgeschlagene Aufträge nie die Wiederherstellungswarteschlange erreichen.
Was du lernen wirst
- SQS-Aufträge senden, empfangen, verarbeiten und bestätigen
- Sichtbarkeitsfenster, erneute Zustellung und aktuelle Empfangskennungen beobachten
- Fehlgeschlagene Aufträge in einer Dead-Letter-Queue isolieren
- SNS-Benachrichtigungen an gefilterte SQS-Abonnements verteilen
- Bedingte DynamoDB-Schreibvorgänge nutzen, um eine wiederholte Geschäftsoperation zu schützen
- Die Weiterleitung fehlgeschlagener Aufträge reparieren, während fehlerfreie Arbeit weiterläuft
- Gespeicherte Ergebnisse prüfen und ausschließlich eigene Ressourcen entfernen
Für wen dieser Kurs geeignet ist
Dieser Kurs richtet sich an Lernende, die eine serverlose Anwendung um asynchrone Arbeit und Fehlerbehandlung erweitern möchten.
Voraussetzungen: Beginne mit Lambda–DynamoDB-Zugriff (FN03) und dessen Voraussetzungen. Q01 → Q02 → Q03 lehren Verarbeitung und Fehlerisolierung. Q04 ist ein separater SNS-Zweig mit IAM-Ressourcenrichtlinien; Q05 benötigt bedingte DynamoDB-Schreibvorgänge (D04) und Lambda-Codeupdates (FN02). Die Service-Challenge folgt Q03; PS02 nutzt auch Q05.
Lernumgebung: Alle Aktivitäten finden in einer bereitgestellten Linux-Umgebung von LabEx im Browser statt. Verwende Terminal für AWS-CLI-Befehle und AWS View neben Terminal, um denselben Ressourcen- und Anwendungszustand zu prüfen. Werkzeuge und Verbindung sind vorbereitet; du benötigst weder ein persönliches AWS-Konto noch Zugriffsschlüssel. Jedes Lab beginnt unabhängig in einer neuen VM. AWS View zeigt Warteschlangen, Nachrichteninhalte, Versuche, Logs, SNS-Umschläge und gespeicherte Bestellungen. Reine Beobachtung empfängt oder bestätigt keine Nachrichten.
Häufig gestellte Fragen
Beweist eine konfigurierte Warteschlange, dass Aufträge verarbeitet werden?
Nein. Prüfe tatsächliche Verarbeitung, gespeicherte Ergebnisse, bestätigte Quellnachrichten und erhaltene fehlgeschlagene Aufträge. Bereitgestellte Prozessoren und Referenzdaten ermöglichen dir, dich mit fiktiven Aufträgen auf diese Ergebnisse zu konzentrieren.
Warum hat eine Nachricht eine neue Empfangskennung?
Eine Empfangskennung gehört zu einer Zustellung. Wenn die Sichtbarkeit abläuft, kann ein weiterer Versuch mit einer aktuellen Kennung erfolgen. Verwende die Kennung der Zustellung, die du bestätigen möchtest.
Bedeutet Duplikatschutz eine Genau-einmal-Zustellung?
Nein. Standardwarteschlangen können mehrfach zustellen. Ein bedingter Schreibvorgang für ein einzelnes Element schützt den vermittelten Geschäftseffekt. Warteschlangenoperationen und Datenbankschreibvorgänge sind jedoch getrennt; dies ist weder eine atomare Transaktion noch eine durchgängige Genau-einmal-Garantie.
Welchen Umfang haben die Nachrichtenbeispiele?
Standardwarteschlangen mit einem Verbraucher für jeweils eine Nachricht, Dead-Letter-Weiterleitung, SNS-zu-SQS-Verteilung im selben Konto und Nachrichtenattributfilter. FIFO-Reihenfolge, beliebige Batches, Produktionsdurchsatz, kontoübergreifende Richtliniengestaltung und vollständige Wiederholungszusagen der Dienste liegen außerhalb des Umfangs.
Welches Projekt folgt auf diesen Kurs?
Recover Poison Messages Without Duplicating Orders im Serverless-Projektkurs. Die Service-Challenge benötigt Q03 und dessen Voraussetzungen; das Projekt auch Q05. Funktion vor Cleanup prüfen.
