Einführung
Ein Worker empfängt einen Bestellauftrag, stoppt aber vor dessen Bestätigung. Du beobachtest, wie derselbe Auftrag zurückkehrt, gibst seiner nächsten Zustellung mehr Verarbeitungszeit und prüfst die tatsächliche Bestellung vor der Bestätigung.
Schließe zuerst Aufträge mit SQS senden und verarbeiten ab. Diese unabhängige VM stellt ihren eigenen Worker, Tabellen und Referenzdaten bereit; frühere Warteschlangen, Nachrichten und Empfangskennungen werden nicht wiederverwendet.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 2.1: SQS-Sichtbarkeitstimeouts, erneute Zustellung und Empfangskennungen.
- Developer – Associate (DVA-C02) · Aufgabe 1.1: SQS-Sichtbarkeitstimeouts, erneute Zustellung und Empfangskennungen.
- DevOps Engineer – Professional (DOP-C02) · Aufgabe 5.1: Grundlagenübung: SQS-Sichtbarkeitstimeouts, erneute Zustellung und Empfangskennungen.
- Solutions Architect – Professional (SAP-C02) · Aufgabe 2.4: Grundlagenübung: SQS-Sichtbarkeitstimeouts, erneute Zustellung und Empfangskennungen.
Einen Auftrag für die erneute Zustellung vorbereiten
Erstelle in diesem Schritt eine Warteschlange mit einem kurzen standardmäßigen Sichtbarkeitszeitlimit und sende einen Auftrag, ohne ihn zu verarbeiten.
Verwende AWS View neben Terminal, um aktuelle Warteschlangen, Worker-Ergebnisse und gespeicherte Bestellungen zu vergleichen. Erhalte die unbeteiligten Referenzdaten.
Arbeite im vorbereiteten Projektverzeichnis:
cd /home/labex/project
Erstelle eine Standardwarteschlange. Ihr standardmäßiges Sichtbarkeitszeitlimit beträgt 30 Sekunden und wird verwendet, wenn eine Empfangsanfrage keinen abweichenden Wert angibt. $(...) speichert die ausgewählte Warteschlangenadresse für spätere Befehle.
QUEUE_URL=$(aws sqs create-queue --queue-name labex-q02-jobs --attributes VisibilityTimeout=30 --query QueueUrl --output text)
Sende einen JSON-Auftrag:
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"redelivery-order","quantity":3}'
Lies das standardmäßige Zeitlimit und die Zähler:
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names VisibilityTimeout ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Erwarte das Zeitlimit 30, eine verfügbare Nachricht und null in Bearbeitung befindliche Nachrichten. In AWS View hat der Auftrag die Empfangsanzahl null, die bereitgestellte Lambda-Funktion hat keine Ausführung, und es gibt keine gespeicherte Bestellung. Das Senden nimmt den Auftrag in die Warteschlange auf; es verarbeitet ihn nicht.
Den Ablauf und eine zweite Zustellung beobachten
Empfange in diesem Schritt einen Auftrag, lasse ihn unbestätigt und beobachte eine zweite Zustellung, nachdem seine Sichtbarkeitsfrist abgelaufen ist.
Nach Ablauf der Sichtbarkeitsfrist kann dieselbe Nachricht mit einer neuen Empfangskennung erneut zugestellt werden.
Der folgende Befehlsblock ist ein zeitlich abgestimmtes Experiment. Lies ihn vor der Ausführung. Der erste Empfang setzt die Sichtbarkeitsfrist abweichend auf 10 Sekunden; der unmittelbar folgende zweite Empfang sollte nichts finden, während dieser Auftrag verborgen ist. sleep 12 wartet, bis die Frist verstrichen ist. Der letzte Empfang gibt dem zurückkehrenden Auftrag ein Fenster von 120 Sekunden, damit du ihn untersuchen kannst, ohne gegen das kurze Zeitlimit anzulaufen. Jedes > speichert eine JSON-Antwort in einer anderen Datei.
aws sqs receive-message --queue-url "$QUEUE_URL" --max-number-of-messages 1 --visibility-timeout 10 --message-system-attribute-names ApproximateReceiveCount --output json > first-delivery.json
aws sqs receive-message --queue-url "$QUEUE_URL" --max-number-of-messages 1 --wait-time-seconds 0 --output json > while-hidden.json
sleep 12
aws sqs receive-message --queue-url "$QUEUE_URL" --max-number-of-messages 1 --visibility-timeout 120 --message-system-attribute-names ApproximateReceiveCount --output json > second-delivery.json
Der leere Empfang verarbeitet oder löscht nichts. Zeige diese Antwort an:
cat while-hidden.json
Erwarte eine leere Antwort ohne Messages. jq -s liest die beiden gespeicherten Antworten zusammen: .[0] ist die erste Zustellung und .[1] die zweite. Vergleiche die Nachrichtenidentität und die Empfangskennung der Zustellung, ohne die Kennungen auszugeben:
jq -s '{
same_message: (.[0].Messages[0].MessageId == .[1].Messages[0].MessageId),
new_receipt: (.[0].Messages[0].ReceiptHandle != .[1].Messages[0].ReceiptHandle),
receive_count: .[1].Messages[0].Attributes.ApproximateReceiveCount
}' first-delivery.json second-delivery.json
Erwarte true für same_message und new_receipt sowie die Empfangsanzahl "2". Eine Nachrichten-ID bezeichnet die Nachricht in der Warteschlange über mehrere Versuche hinweg. Eine Empfangskennung bezeichnet einen Zustellversuch. Verwende daher für Änderungen der Sichtbarkeit und für die Löschung immer die neueste Kennung.
AWS View zeigt denselben Inhalt in Bearbeitung, zweimal empfangen, ohne dass bereits eine Bestellung existiert. Dies ist eine tatsächliche erneute Zustellung nach einem unbestätigten Versuch. Es war kein zweites Senden nötig. Standardwarteschlangen können auch aus anderen Gründen Duplikate zustellen; die Verwaltung der Sichtbarkeit ermöglicht keine Genau-einmal-Verarbeitung.
Dieses tatsächliche Beispiel zeigt die Empfangsanzahl zwei vor der Geschäftsverarbeitung. Nachrichtenkennungen unterscheiden sich zwischen Arbeitsbereichen.
Das Fenster verlängern und die Arbeit abschließen
Verlängere in diesem Schritt das Verarbeitungsfenster der aktuellen Zustellung, führe den bereitgestellten Worker vollständig aus und bestätige erst nach Prüfung der gespeicherten Daten.
Wähle die neueste Empfangskennung aus der zweiten Antwort aus. jq -r schreibt eine einfache Zeichenfolge, die sich als Befehlsargument eignet.
RECEIPT_HANDLE=$(jq -r '.Messages[0].ReceiptHandle' second-delivery.json)
Ändere die Sichtbarkeitsfrist für genau diese Zustellung auf 300 Sekunden:
aws sqs change-message-visibility --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE" --visibility-timeout 300
Dieses neue Intervall beginnt, wenn die Änderung erfolgreich ist. Es lässt die standardmäßige Einstellung von 30 Sekunden für die Warteschlange unverändert und bestätigt den Auftrag nicht. Wenn das Untersuchungsfenster von 120 Sekunden bereits abgelaufen ist, empfange den Auftrag erneut in second-delivery.json und wähle vor der Änderung der Sichtbarkeit seine neueste Kennung aus. Zusätzliche Versuche erhöhen die Empfangsanzahl; verwende das zeitlich abgestimmte Experiment erneut in einem neuen Arbeitsbereich, wenn du dessen genaue Beobachtung zweier Zustellungen wiederholen möchtest.
Wandle den empfangenen Inhalt von JSON-Text in ein Auftragsobjekt um:
jq '.Messages[0].Body | fromjson' second-delivery.json > job.json
Führe die bereitgestellte Lambda-Funktion aus und untersuche dann ihr Ergebnis:
aws lambda invoke --function-name labex-q02-worker --payload fileb://job.json worker-response.json
cat worker-response.json
Erwarte processed: true, die Menge 3 und einen Gesamtbetrag von 850 Cent. Lies das dauerhaft gespeicherte Element unabhängig aus:
aws dynamodb get-item --table-name labex-q02-orders --key '{"id":{"S":"redelivery-order"}}' --consistent-read --query Item
Lösche erst nach Bestätigung des tatsächlich gespeicherten Ergebnisses mit der aktuellen Empfangskennung:
aws sqs delete-message --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE"
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names VisibilityTimeout ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Erwarte das standardmäßige Zeitlimit 30, null verfügbare und null in Bearbeitung befindliche Nachrichten. AWS View zeigt eine leere Warteschlange, tatsächliche Worker-Eingabe und tatsächliches Ergebnis sowie die Bestellung redelivery-order/3/850. Die Verlängerung der Sichtbarkeitsfrist verringerte die Wahrscheinlichkeit, dass ein anderer Worker den Auftrag empfängt, während dieser Versuch ihn bearbeitet. Sie machte die Geschäftsaktion nicht idempotent; spätere Einheiten vermitteln einen dauerhaften Schutz vor doppelten Auswirkungen.
Die Warteschlange und das eigene Ergebnis entfernen
Entferne in diesem Schritt deine Warteschlange, Bestellung und Ausführungslogs und erhalte dabei vorbereitete Ressourcen und Referenzdaten.
aws sqs delete-queue --queue-url "$QUEUE_URL"
aws dynamodb delete-item --table-name labex-q02-orders --key '{"id":{"S":"redelivery-order"}}'
aws logs delete-log-group --log-group-name /aws/lambda/labex-q02-worker
Verwende erfolgreiche Dienstabfragen, um das Fehlen eigener Ressourcen und die Verfügbarkeit der Referenz zu bestätigen:
aws sqs list-queues
aws dynamodb scan --table-name labex-q02-orders --query Items
aws dynamodb scan --table-name labex-q02-reference --query Items
Es bleiben keine Warteschlangen-URLs oder Bestellelemente übrig. Das Referenzelement enthält weiterhin keep unchanged. AWS View zeigt denselben Bereinigungszustand, und der bereitgestellte Worker bleibt verfügbar. Netzwerk- oder Authentifizierungsfehler können eine Löschung nicht belegen.
Entferne die lokalen Zustellungs- und Antwortdateien:
rm -f first-delivery.json while-hidden.json second-delivery.json job.json worker-response.json
Führe die Schrittprüfung aus, bevor du deine Umgebung beendest.
Zusammenfassung
Du hast beobachtet, wie ein unbestätigter SQS-Auftrag nach Ablauf seiner Sichtbarkeitsfrist wieder verfügbar wurde, dieselbe Nachricht mit einer neuen Empfangskennung und einer höheren Empfangsanzahl empfangen und die Verarbeitungszeit der aktuellen Zustellung verlängert. Du hast vor der Bestätigung eine tatsächlich gespeicherte Bestellung geprüft und deine Warteschlange, dein Ergebnis und deine Logs bereinigt, während die bereitgestellten Ressourcen erhalten blieben.
