Einführung
Ein ungültiger Bestellauftrag schlägt jedes Mal fehl, wenn der Worker ihn verarbeitet. Du begrenzt seine Versuche, hältst ihn zur Untersuchung in einer separaten Warteschlange vor und bestätigst, dass gesunde Bestellungen weiterhin abgeschlossen werden.
Schließe zuerst Sichtbarkeitszeitlimit und erneute Zustellung behandeln und dessen angeleitete Voraussetzungen ab. Diese unabhängige VM stellt einen Worker und eine leere Bestelltabelle bereit; Warteschlangen, Nachrichten und die Verbraucherverbindung sind deine Aufgabe.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 2.1: Begrenzte Nachrichtenverarbeitung und Isolation fehlgeschlagener Aufgaben.
- Developer – Associate (DVA-C02) · Aufgabe 1.1: Begrenzte Nachrichtenverarbeitung und Isolation fehlgeschlagener Aufgaben.
- DevOps Engineer – Professional (DOP-C02) · Aufgabe 5.1: Grundlagenübung: Begrenzte Nachrichtenverarbeitung und Isolation fehlgeschlagener Aufgaben.
- Solutions Architect – Professional (SAP-C02) · Aufgabe 2.4: Grundlagenübung: Begrenzte Nachrichtenverarbeitung und Isolation fehlgeschlagener Aufgaben.
Eine Quellwarteschlange mit einer Dead-Letter-Queue verbinden
Erstelle in diesem Schritt zwei leere Standardwarteschlangen und konfiguriere eine begrenzte Weiterleitung auf der Quellwarteschlange.
Eine Dead-Letter-Queue (DLQ) bewahrt Aufträge auf, die das Empfangslimit einer Quellwarteschlange überschreiten. Verwende AWS View neben Terminal, um beide Warteschlangen, tatsächliche Versuche und gespeicherte Bestellungen zu vergleichen; erhalte die Referenzdaten.
cd /home/labex/project
Erstelle das Ziel für fehlgeschlagene Aufträge und speichere seine Warteschlangenadresse:
DEAD_URL=$(aws sqs create-queue --queue-name labex-q03-dead --query QueueUrl --output text)
Die Weiterleitungsrichtlinie (Redrive Policy) referenziert die ARN des Ziels, seine Ressourcenkennung im Dienst, statt seiner Warteschlangen-URL. Wähle diese ARN aus:
DEAD_ARN=$(aws sqs get-queue-attributes --queue-url "$DEAD_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
Schreibe eine kleine JSON-Richtlinie. Die Shell setzt deine Ziel-ARN für $DEAD_ARN ein; maxReceiveCount erlaubt zwei Zustellversuche, bevor ein weiterer Empfang die Nachricht in die DLQ verschiebt.
cat > redrive-policy.json <<EOF
{
"deadLetterTargetArn": "$DEAD_ARN",
"maxReceiveCount": 2
}
EOF
SQS-Warteschlangenattribute stellen die Weiterleitungsrichtlinie als JSON-Zeichenfolge innerhalb eines weiteren JSON-Dokuments dar. --rawfile liest die Richtliniendatei als diese Zeichenfolge; > schreibt die Attributdatei.
jq -n --rawfile policy redrive-policy.json '{VisibilityTimeout:"30",RedrivePolicy:$policy}' > queue-attributes.json
Erstelle die Quellwarteschlange mit diesen Attributen:
QUEUE_URL=$(aws sqs create-queue --queue-name labex-q03-jobs --attributes file://queue-attributes.json --query QueueUrl --output text)
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names QueueArn VisibilityTimeout RedrivePolicy
Erwarte das Sichtbarkeitszeitlimit 30, eine Richtlinie mit dem Ziel labex-q03-dead und das Empfangslimit 2. Speichere die Quell-ARN für die Verbraucherverbindung:
QUEUE_ARN=$(aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
AWS View zeigt beide leeren Warteschlangen, keine Worker-Ausführung und keine Bestellung. Eine Weiterleitungsrichtlinie verarbeitet selbst keine Nachrichten; der Empfang muss durch einen Verbraucher erfolgen.
Den Verbraucher verbinden und gesunde Verarbeitung nachweisen
Verbinde in diesem Schritt eine Lambda-Ereignisquellenzuordnung und prüfe die tatsächliche Verarbeitung eines gültigen Auftrags.
Die Zuordnung fragt die Warteschlange ab und ruft den Worker auf; erfolgreiche Verarbeitung ermöglicht ihr, die Nachricht zu bestätigen.
Eine Ereignisquellenzuordnung (Event-Source Mapping) verbindet die Quellwarteschlange mit einem Lambda-Verbraucher. Sie fragt Nachrichten ab, übergibt sie als SQS-Records-Ereignis und löscht erfolgreich bearbeitete Nachrichten. Die bereitgestellte Ausführungsrolle hat nur Empfangs- und Löschberechtigungen für die Quellwarteschlange, Schreibberechtigungen für die Bestelltabelle und Logging-Berechtigungen. Der Worker weist Mengen außerhalb von 1–10 zurück. Sein Code und seine Berechtigungen sind vorbereitet; deine Aufgabe ist die Warteschlangenverbindung und Fehlerisolierung.
Erstelle eine Zuordnung mit Batchgröße eins, damit jeder Versuch einen untersuchbaren Auftrag enthält:
MAPPING_ID=$(aws lambda create-event-source-mapping --function-name labex-q03-worker --event-source-arn "$QUEUE_ARN" --batch-size 1 --enabled --query UUID --output text)
Lies die Verbindung aus:
aws lambda get-event-source-mapping --uuid "$MAPPING_ID" --query '{Source:EventSourceArn,Function:FunctionArn,Batch:BatchSize,State:State}'
Erwarte die Quell-ARN für labex-q03-jobs, die Funktion labex-q03-worker, die Batchgröße 1 und den Zustand Enabled. Die Existenz der Zuordnung ist ein Konfigurationsbeleg; eine tatsächlich gespeicherte Bestellung wird die Verarbeitung belegen.
Sende einen gesunden Auftrag:
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"good-order","quantity":2}'
Beobachte AWS View, bis der Worker ein Ergebnis zurückgibt und die Bestelltabelle good-order zeigt. Die Verarbeitung ist asynchron; lasse dem Verbraucher ein kurzes Zeitintervall, statt diese Nachricht manuell zu empfangen. Lies dann die Bestellung:
aws dynamodb get-item --table-name labex-q03-orders --key '{"id":{"S":"good-order"}}' --consistent-read --query Item
Erwarte die Menge 2 und den Gesamtbetrag 600. Prüfe beide Warteschlangen:
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
aws sqs get-queue-attributes --queue-url "$DEAD_URL" --attribute-names ApproximateNumberOfMessages
Beide Warteschlangen sollten leer sein: Der Worker hat den geschäftlichen Schreibvorgang abgeschlossen, und der Verbraucher hat den erfolgreichen Auftrag bestätigt. Eine gesunde Nachricht gehört nicht in die DLQ.
Begrenzte Wiederholungen und Fehlerisolierung beobachten
Sende in diesem Schritt einen ungültigen Auftrag und beobachte tatsächliche fehlgeschlagene Verarbeitungsversuche, bevor die Weiterleitung durch den Dienst ihn in die DLQ verschiebt.
Mit dem Empfangslimit von zwei in diesem Lab verschiebt ein späterer Empfang den fehlgeschlagenen Auftrag in die DLQ, statt den Worker ein drittes Mal aufzurufen.
Eine Poison Message schlägt aufgrund ihrer Daten oder Verarbeitungslogik wiederholt fehl. Sende eine fiktive ungültige Menge von null:
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"poison-order","quantity":0}'
AWS View zeigt den fehlgeschlagenen Versuch des Workers. Die Nachricht bleibt in Bearbeitung, bis ihre Sichtbarkeitsfrist abläuft; dann kann der Verbraucher sie erneut empfangen. Beobachte die Versuche und Warteschlangenzähler, bis die DLQ einen verfügbaren Auftrag enthält. Bei diesem Fenster von 30 Sekunden und zwei Versuchen solltest du ungefähr eine Minute plus Verarbeitungszeit einplanen. Empfange oder lösche den Auftrag nicht manuell, während der Verbraucher läuft; dies würde Empfangsanzahl und Experiment verändern.
Die beiden fehlgeschlagenen Versuche haben dieselbe Nachrichten-ID und die Empfangsanzahlen 1 und 2. Für poison-order erscheint keine gespeicherte Bestellung. Nach Erreichen des Empfangslimits verschiebt ein nachfolgender Empfang direkt beim Dienst die Nachricht aus der Quellwarteschlange, statt die Funktion ein drittes Mal aufzurufen.
Bestätige den Warteschlangenzustand über die CLI:
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
aws sqs get-queue-attributes --queue-url "$DEAD_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Erwarte null verfügbare und null in Bearbeitung befindliche Aufträge in der Quelle sowie einen verfügbaren Auftrag in der DLQ. AWS View zeigt dessen ursprünglichen Inhalt. Untersuche die tatsächlichen Worker-Logs auf die ungültige Menge und den Fehler:
aws logs filter-log-events --log-group-name /aws/lambda/labex-q03-worker --query 'events[].message'
Lies alle Bestellelemente:
aws dynamodb scan --table-name labex-q03-orders --query Items
Nur good-order/2/600 bleibt erhalten. Der Fehler wurde isoliert, ohne seine Nachricht zu verwerfen oder eine ungültige Bestellung zu schreiben. Die Verschiebung in eine DLQ ist weder eine Reparatur noch ein erfolgreiches Geschäftsergebnis; Wiederherstellung und Duplikatschutz von Aufträgen folgen in späteren Einheiten und der Projekt-Challenge.
Die Verbindung und eigene Ressourcen entfernen
Stoppe in diesem Schritt deine Verbraucherverbindung, bevor du Warteschlangen und Ergebnisse löschst.
Entferne zuerst die Ereignisquellenzuordnung:
aws lambda delete-event-source-mapping --uuid "$MAPPING_ID" --query UUID --output text
Lösche beide temporären Warteschlangen. Dadurch wird auch der fiktive Poison-Auftrag verworfen, der in der DLQ aufbewahrt wird:
aws sqs delete-queue --queue-url "$QUEUE_URL"
aws sqs delete-queue --queue-url "$DEAD_URL"
Entferne die gesunde Bestellung und die Ausführungslogs dieses Labs:
aws dynamodb delete-item --table-name labex-q03-orders --key '{"id":{"S":"good-order"}}'
aws logs delete-log-group --log-group-name /aws/lambda/labex-q03-worker
Prüfe mit erfolgreichen API-Antworten das Fehlen eigener Ressourcen und den Erhalt der Referenz:
aws lambda list-event-source-mappings --function-name labex-q03-worker --query EventSourceMappings
aws sqs list-queues
aws dynamodb scan --table-name labex-q03-orders --query Items
aws dynamodb scan --table-name labex-q03-reference --query Items
Zuordnungs- und Bestelllisten sind leer, es bleiben keine Warteschlangen-URLs übrig, und das Referenzelement enthält weiterhin keep unchanged. Der bereitgestellte Worker und die Tabellenstrukturen bleiben erhalten. AWS View zeigt denselben Ressourcenzustand. Ein Authentifizierungs- oder Netzwerkfehler kann eine Löschung nicht belegen.
Entferne die gewöhnlichen lokalen Richtliniendateien:
rm -f redrive-policy.json queue-attributes.json
Führe die Bereinigungsprüfung aus, bevor du die Umgebung beendest.
Zusammenfassung
Du hast eine SQS-Quellwarteschlange mit einem begrenzten Empfangslimit an eine DLQ angeschlossen, einen Lambda-Verbraucher angebunden und eine gesunde gespeicherte Bestellung geprüft. Du hast beobachtet, wie ein ungültiger Auftrag zweimal fehlschlug und ohne geschäftlichen Schreibvorgang in die DLQ verschoben wurde. Anschließend hast du deine Zuordnung, Warteschlangen, dein Ergebnis und deine Logs entfernt und dabei die bereitgestellten Ressourcen erhalten.
